Tender Document 2 MARINE-EO PCP CHALLENGE · 2018-06-29 · Pre-Commercial Procurement (PCP) Tender Document 2 – MARINE-EO PCP CHALLENGE Deadline to submit an offer: 9th April 2018

Pre-Commercial Procurement (PCP)

Tender Document 2 – MARINE-EO

PCP CHALLENGE

Deadline to submit an offer: 9th April 2018 at 12 p.m (CET)

Document Dissemination Level:

P

CΟ

This document was prepared by DGPM with the valuable contribution of all partners.

Public

Confidential, only for members of the Consortium (including the Commission Services)

☒

☐

This project has received funding from the European Union’s Horizon 2020

Research and innovation programme under grant agreement No 730098

Copyright Marine-EO Consortium. All rights reserved. 2

This Request for Tenders, designated as Tender Document 2, should be read in conjunction with other

documents related to this Pre-Commercial Procurement (PCP), listed hereunder:

Tender Document 1: PCP MARINE-EO Request for Tender;

Tender Document 3: Forms;

Tender Document 4: Framework Agreement;

Tender Document 5: Specific Contract Phase 1;

Tender Document 6: Annexes.

All documents are available on the MARINE-EO website as well as on the “Annexes Section” inside the

MARINE-EO Procurement Area.







Table of Contents 1 THEMATIC AREA 1 – MARINE ENVIRONEMENT MONITORING ........................................................ 10

1.1 GENERIC REQUIREMENTS ............................................................................................................... 10

1.1.1 OPERATIONAL REQUIREMENTS .............................................................................................. 10

1.1.1.1 OPERATIONAL NEED ........................................................................................................... 11

1.1.1.2 OPERATIONAL AREAS .......................................................................................................... 12

1.1.2 FUNCTIONAL REQUIREMENTS ................................................................................................ 12

1.1.2.1 GENERIC .............................................................................................................................. 12

1.1.2.2 USER REQUEST .................................................................................................................... 13

1.1.2.3 HMI (HUMAN MACHNE INTERFACE/INTERACTION) – PLATFORM ...................................... 13

1.1.2.4 PERFORMANCE & MONITOR .............................................................................................. 14

1.1.2.5 SERVICE CATALOGUE .......................................................................................................... 14

1.1.2.6 SERVICE DISSEMINATION .................................................................................................... 15

1.1.2.7 DATA DICTIONARY .............................................................................................................. 17

1.1.3 NON-FUNCTIONAL REQUIREMENTS ....................................................................................... 18

1.1.3.1 SW & HW ............................................................................................................................ 18

1.1.3.2 AVAILABILITY AND RELIABILITY ........................................................................................... 18

1.1.3.3 QUALITY CONTROL ............................................................................................................. 19

1.1.3.4 MAINTENANCE ................................................................................................................... 19

1.1.3.5 VERIFICATION ..................................................................................................................... 20

1.1.3.6 TRAINING ............................................................................................................................ 20

1.1.4 SPACE DATA COMPONENT ..................................................................................................... 20

1.1.4.1 SATELLITE IMAGERY PROVISION AND THE CSCDA MECHANISM......................................... 20

1.1.4.2 ACCESS TO SATELLITE DATA ................................................................................................ 21

1.1.4.3 QUOTA AVAILABLE FOR PROTOTYPING, TESTING AND OPERATIONAL DEMONSTRATION . 22

1.1.5 SOLUTION READINESS ASSESSMENT ...................................................................................... 22

1.2 DOWNSTREAMING SERVICES’ SPECIFIC REQUIREMENTS ............................................................... 23

1.2.1 SATOCEAN-UCS-1: MARINE ENVIRONMENTAL STATUS IN HOT SPOTS (AOIS E.G. GULFS,

MPAS ETC.) ............................................................................................................................................. 23

1.2.1.1 RELEVANT PROJECTS ........................................................................................................... 24

1.2.1.2 PROBLEM STATEMENT........................................................................................................ 24

1.2.1.3 NARRATIVE DESCRIPTION ................................................................................................... 24


1.2.1.5 USER & DATA REQUIREMENTS FOR MARINE ENVIRONMENTAL STATUS IN HOT SPOTS

(AOIS E.G. GULFS, MPAS ETC.) ............................................................................................................ 25




1.2.2 SATOCEAN-UCS-2: FISH FARMS: DETECTION OF FISH FARMS THREATS ................................. 27

1.2.2.1 RELEVANT PROJECTS ........................................................................................................... 27




1.2.2.5 USER & DATA REQUIREMENTS FOR FISH FARM: DETECTION OF FISH FARMS THREATS ..... 28

1.2.3 SATOCEAN-UCS-3: DETECTION OF VESSELS AND ICEBERGS IN ARCTIC AREAS ....................... 30

1.2.3.1 RELEVANT PROJECT ............................................................................................................ 30




1.2.3.5 USER & DATA REQUIREMENTS FOR DETECTION OF VESSELS AND ICEBERGS IN ARCTIC

AREAS 33

2 THEMATIC AREA 2 – SECURITY ...................................................................................................... 35

2.1 KEYWORDS ..................................................................................................................................... 36

2.2 OPERATIONAL CONCEPT DESCRIPTION .......................................................................................... 36

2.2.1 OPERATIONAL SCENARIOS ...................................................................................................... 38

2.2.1.1 SERVICE 1 – OPERATIONAL AREAS FOR UNUSUAL/IRREGULAR ACTIVITY MONITORING

AROUND A CRITICAL INFRASTRUCTURE ............................................................................................. 39

2.2.1.2 SERVICE 2 - OPERATIONAL AREAS FOR ENHANCED CHANGE DETECTION .......................... 40

2.2.2 OPERATIONAL TARGETS.......................................................................................................... 41

2.2.3 OPERATIONAL CAPABILITIES REQUIREMENTS ........................................................................ 41

2.2.4 REQUIREMENTS FOR OPERATIONAL CAPABILITIES VALIDATION ............................................ 43

2.3 FUNCTIONAL REQUIREMENTS ........................................................................................................ 45

2.3.1 USER REQUEST (UR) GENERAL REQUIREMENTS ..................................................................... 45

2.3.2 GUI – GEOPORTAL GENERAL REQUIREMENTS ........................................................................ 46

2.3.3 ARCHIVED IMAGERY SEARCH AND NEW ACQUISITION PLANNING TOOL ............................... 48

2.3.4 PRODUCT CATALOGUE GENERAL REQUIREMENTS ................................................................. 49

2.3.5 PRODUCT DISSEMINATION GENERAL REQUIREMENTS........................................................... 50

2.3.5.1 IMAGERY ............................................................................................................................. 50

2.3.5.2 TYPES AND FORMATS ......................................................................................................... 51

2.3.5.3 CARTOGRAPHIC SPECIFICATIONS ........................................................................................ 52

2.3.6 DATA DICTIONARY .................................................................................................................. 53

2.4 DOWNSTREAMING SERVICE SPECIFIC FUNCTIONAL REQUIREMENTS ............................................ 53




2.4.1 SERVICE 1: UNUSUAL/IRREGULAR ACTIVITY MONITORING AROUND A CRITICAL

INFRASTRUCTURE ................................................................................................................................... 56

2.4.1.1 INDICATIVE DATA SOURCES ................................................................................................ 59

2.4.1.2 POTENTIAL OUTPUT INFORMATION LAYERS ...................................................................... 59

2.4.1.3 POTENTIAL USERS ............................................................................................................... 60

2.4.1.4 MARITIME MONITORING MODE (MANDATORY) ................................................................ 60

2.4.1.5 LAND MONITORING MODE (OPTIONAL) ............................................................................. 64

2.4.2 SERVICE 2: ENHANCED CHANGE DETECTION .......................................................................... 67

2.4.2.1 MODE 1 - REGIONAL CHANGE DETECTION (SENTINEL-BASED CHANGE DETECTION) ......... 70

2.4.2.2 MODE 2 – TARGETED CHANGE DETECTION ........................................................................ 71

2.4.2.3 MODE 3 – ACTION MODE ................................................................................................... 72

2.4.2.4 INDICATIVE DATA SOURCES ................................................................................................ 73

2.4.2.5 POTENTIAL OUTPUT INFORMATION LAYERS ...................................................................... 73

2.5 NON-FUNCTIONAL REQUIREMENTS ............................................................................................... 74

2.5.1 SW & HW ................................................................................................................................ 74

2.5.2 AVAILABILITY AND RELIABILITY ............................................................................................... 74

2.5.3 QUALITY CONTROL ................................................................................................................. 75

2.5.4 MAINTENANCE ....................................................................................................................... 75

2.5.5 VERIFICATION ......................................................................................................................... 76

2.5.6 TRAINING ................................................................................................................................ 76

2.6 SPACE DATA COMPONENT ............................................................................................................. 77

2.6.1 SATELLITE IMAGERY PROVISION AND THE CSCDA MECHANISM ............................................ 77

2.6.2 ACCESS TO SATELLITE DATA .................................................................................................... 78

2.6.3 QUOTA AVAILABLE FOR PROTOTYPING, TESTING AND OPERATIONAL DEMONSTRATION ..... 78

2.7 SOLUTION READINESS ASSESSMENT .............................................................................................. 79

3 REFERENCE ARCHITECTURE REQUIREMENTS .................................................................................. 81

3.1 Envisaged Architecture ................................................................................................................... 81

3.2 Overview of the envisaged architecture ......................................................................................... 81

3.2.1 Platform Tool .......................................................................................................................... 82

3.2.2 Product/Service exploitation .................................................................................................. 83

3.2.3 Data Manager ......................................................................................................................... 83

3.2.4 Web portal & Desktop App ..................................................................................................... 83

3.2.5 Web Services .......................................................................................................................... 83

3.2.6 Cloud Middleware - OpenStack Cloud .................................................................................... 84

3.2.7 Data Storage ........................................................................................................................... 84




3.2.8 Downstream Services ............................................................................................................. 85

3.2.8.1 Operating Services .............................................................................................................. 86

3.2.8.2 Supporting Services ............................................................................................................ 88

3.3 Architecture requirements ............................................................................................................. 93

3.3.1 Functional Requirements ........................................................................................................ 93

3.3.2 Non-Functional Requirements ................................................................................................ 94

4 GENERAL REQUIREMENTS (THEMATIC AREAS 1 AND 2) .................................................................. 95

4.1 CONTRACT MANAGEMENT REQUIREMENTS .................................................................................. 95

4.1.1 CONTRACT MANAGEMENT PLAN (MILESTONES, DELIVERABLES, WORK BREAKDOWN

STRUCTURE, ETC.)................................................................................................................................... 95

4.1.2 CONTRACT MONITORING (SCHEDULE, PAYMENTS, INTERMEDIATE RESULTS, ETC.) .............. 96

4.1.3 CONTRACT IMPLEMENTATION (WORK TEAM COMPOSITION, ACCREDITED EXPERIENCE,

SUBCONTRACTING, ETC.) ....................................................................................................................... 96

4.1.3.1 PCP PHASE 1: SERVICE DESIGN (5 MONTHS)....................................................................... 97

4.1.3.2 PCP PHASE 2: PROTOTYPING (9 MONTHS).......................................................................... 98

4.1.3.3 PCP PHASE 3: DEVELOPMENT, VERIFICATION AND OPERATIONAL VALIDATION (13

MONTHS) ............................................................................................................................................ 99

4.1.4 EXPLOITATION PLAN ............................................................................................................. 100

5 ANNEXES .................................................................................................................................... 101

5.1 PDR DOCUMENTATION PER LOT .................................................................................................. 101

5.2 CDR DOCUMENTATION PER LOT .................................................................................................. 102

5.3 FAT DOCUMENTATION PER LOT ................................................................................................... 103

5.4 PHASE 3 DOCUMENTATION CONTENTS ....................................................................................... 104




Table of Figures Figure 1: Design system of SATOCEAN Services ............................................................................................. 10

Figure 2: Preliminary conceptual design schema. .......................................................................................... 37

Figure 3: Service 1 - Unusual/Irregular activity monitoring around a Critical Infrastructure operational Areas

....................................................................................................................................................................... 39

Figure 4: Enhanced Change Detection Operational Areas. Source: Frontex FRAN and JORA data as of 5 May

2017 ............................................................................................................................................................... 40

Figure 5: Service operational workflow model ............................................................................................... 54

Figure 6: Workflow description example ........................................................................................................ 55

Figure 7: Example of the thresholding approach with three proposed distance rings around a critical

infrastructure. Contains modified Copernicus Sentinel-2 data (2017) ........................................................... 59

Figure 8: Operational View (OV) 3, operational node connectivity overview. Maritime Monitoring mode ... 61

Figure 9: OV 3 operational node connectivity overview. Land Monitoring mode .......................................... 65

Figure 10: OV 3 operational node connectivity overview. Regional Change Detection - Enhanced Change

Detection ........................................................................................................................................................ 71

Figure 11: OV 3 operational node connectivity overview Targeted Change Detection Mode ........................ 72

Figure 12: OV 3 operational node connectivity overview. Action Mode - Enhanced Change Detection ........ 73

Figure 13 High Level Architecture of MARINE-EO .......................................................................................... 82

Figure 14 SATOCEAN-UCS-1: MARINE environmental status in hot spots (AOIs e.g. Gulfs, MPAs etc.) service

operational activities ...................................................................................................................................... 86

Figure 15 SATOCEAN-UCS-2: Fish Farms: Detection of Fish farms threats ..................................................... 86

Figure 16 SATOCEAN-UCS-3: Detection of vessels and icebergs in Arctic areas ............................................. 87

Table of Tables Table 1 Operational Areas of selected SATOCEAN Services ........................................................................... 12

Table 2: Types and formats of service dissemination ..................................................................................... 16

Table 3: Cartographic specifications ............................................................................................................... 17

Table 4: Data dictionary element ................................................................................................................... 18

Table 5: User Scenario on the environmental status ...................................................................................... 25

Table 6: User Scenario on fish farm threats detection ................................................................................... 28

Table 7 User Scenario on Detection of vessels and icebergs in Arctic areas................................................... 32

Table 8: Definitions applicable for each data dictionary element .................................................................. 53

Table 9: Possible request states ..................................................................................................................... 88







1 THEMATIC AREA 1 – MARINE ENVIRONEMENT MONITORING

1.1 GENERIC REQUIREMENTS

The aim of this section is to describe the operational technical requirements for the definition and

implementation of added-value downstreaming services for the SATOCEAN service: MARINE environment

monitoring. It anticipates to overcome the complexity of collecting - processing the EO data and

contributing to the user uptake through the use of EO data and related services (e.g. CMEMS).

1.1.1 OPERATIONAL REQUIREMENTS

As a reference point, hereunder, Figure 1 provides a simplified design schema of services implementation.

Basically, it provides the generic view of what will have to be developed by the Contractors and more

precisely this includes all three tiers starting from the lowest logical level (Database) and moving up to the

Application level (User Interface).

Figure 1: Design system of SATOCEAN Services

End-User

Request Response

User Interface

Thematic Area 1 – Marine Environment

Database

DB-1DB-...

DB-X

Service Catalogue

FS1 FS4……………

Data Ordering Datawarehouse Data Access

Contractor

Data Connectors

DIAS

CMEMS

CollGS

Insitu

OThers




A single point of access (common platform) is needed where all End-Users (PAs)1 will be able to register and

use the services, having also the capability (functionality) to request on demand services and/or more

accurate information. Thus, the End-User shall:

1. Be registered to the platform and to the relevant/interest services. Then, he/she will be able to

view and retrieve all the available information.

2. Be capable to request the application of an additional area of interest (see section 3.2.8.2.5 ). The

system will create a “ticket” to this request and inform the user about the respond time that the

request can be analyzed and processed. Then the service provider (Administration) shall examine

the request and revert back to the End-User about the availability of the service. When available,

relevant cost will also be provided.

3. Be able to request the availability of very high resolution data (Data Acquisition Request) to the

Copernicus DWH (Data WareHouse). The Service provider shall analyze the request and identify

whether the request is feasible or not. Again, in case the request is feasible, a relevant timeframe

and cost will be provided to the End-User.

To this end, the End-User shall be able to i) interpret, ii) analyze the product (Data and/or Service) iii) use it

and iv) evaluate both data and the request.

1.1.1.1 OPERATIONAL NEED

The operational validation of the MARINE-EO services will be carried out under common evaluation criteria.

The operational validation is to be carried out solely by the MARINE-EO partners, as they are the End-Users

of the solutions and they are in the position to measure how the different services contribute to improve

their operational tasks. Thus, the following operational needs have been detected:

OP 1. The Contractor shall design, implement and maintain a Data Catalogue that will store images and

data received primarily from open sources such as Sentinels, CMEMS, NOAA and other sources

supported by the dedicated missions Copernicus DWH.

OP 2. The Contractor shall design, implement and maintain a Service Catalogue that provides the selected

three (3) of the following main services:

Ocean biotic and abiotic parameters, climatological information and historical statistics –

SATOCEAN-UCS-1: MARINE environmental status in hot spots (AOIs e.g. Gulfs, MPAs etc.)

Fish farm monitoring – SATOCEAN-UCS-2: Fish Farms: Detection of Fish farms threats

Arctic based services – SATOCEAN-UCS-3: Detection of vessels and icebergs in Arctic areas

OP 3. The Service Provider shall be able to receive orders from end-users (User Requests) through its web

interface (Supporting service).

OP 4. The Service Provider shall allow the Administrator to perform feasibility analysis as a response of End-

User requests.

1DGPM , GUCI (in addition relevant authorities will be invited to attend as observers), HCMR, FRCT [3 Public Authorities (FRCT, Regional Directorate of Maritime Affairs [DRAM] and Regional Fisheries Inspection [IRP]) and 1 Maritime Authorities (Portuguese Navy)], NCA.




The feasibility analysis shall be based in the constraints included in user requirements and shall

provide those data providers fulfilling the criteria set by the user.

The feasibility analysis shall be able to provide information about conflicts of the feasible scenes

proposed to the user with other requests already on-going.

The Administrator shall be able to check the possible overlapping with in-place requests.

The Administrator shall be able to introduce a cost mechanism.

The Administrator shall be able to confirm the validation status.

The decision to resolve conflicts shall be left to the Administrator.

1.1.1.2 OPERATIONAL AREAS

All services shall be operational and can be validated in several areas. Specifically, the following table

provides the countries that each service has to be tested and validated. For more information please see

Section 1.2 where indicative areas/regions/seas are defined.

Table 1 Operational Areas of selected SATOCEAN Services

1.1.2 FUNCTIONAL REQUIREMENTS

1.1.2.1 GENERIC

FUN 1. All feature services shall be built on common standards and service-oriented architecture (SOA).

FUN 2. All feature services shall be prepared to interact with other data sources and external systems

Standard interfaces (e.g. CMEMS, NOAA, DIAS and Sentinel CGS - Collaborative Ground Segment).

FUN 3. The web interface shall support the following browsers: Internet Explorer 9, 10 and 11, Edge,

Firefox, and Google Chrome (Latest version available), supporting also mobile versions (enabling

relevant libraries for Android and iOS).

FUN 4. The analysis and design shall be done using the UML (Unified Modeling Language) tools and

methods (e.g. Activity, Sequence diagrams).

FUN 5. The analysis, design and implementation of the new developed software shall be Object Oriented.

FUN 6. The selected data interchange mechanism between each Service and the external entities shall

guarantee: Asynchronous, FIFO queue, some security mechanism must be deployed to guarantee

confidentiality, identity and data coherence, No data loss, Message or file based, The system will




define some backup and versioning mechanism, to keep a copy of every interchanged message for

a period of time.

FUN 7. All the interfaces shall be XML based.

FUN 8. Each Service shall validate all input against agreed XML schemas.

FUN 9. Each Service shall use the external interfaces adequately secured and shall allow mainly FTP and

HTTP protocols. Any deviation of this requirement shall be justified.

1.1.2.2 USER REQUEST

FUN 10. The platform shall allow users to manage their request (creation, modification and cancellation).

FUN 11. The platform shall have a friendly user interface that will be followed with a user manual guide

assisting all types of users.

FUN 12. Each additional request shall be associated with a state. The states supported will depend on the

kind of request but the list will contain at least:

Defined: The order is created by the user but it has not been validated by the Administrator.

Validated: The order has been technically validated.

Approved: The Administrator has approved the request.

Received: The data from service providers has been received.

Rejected: The provider has not accepted the request.

Cancelled: The user has cancelled the order.

Discarded: The Administrator hasn’t approved the order.

Concluded: The time period for the product to be available for the user has finalized and the product has been successfully removed from the exchange area.

Error: If any error is detected during the process.

Any other status terminology can be proposed by the Contractor.

FUN 13. The System shall allow the supervision of the status of user request with at least the following

characteristics:

Time ranges.

Priority types.

Requests types.

FUN 14. Feasibility analysis shall be shared with the user through the system HMI, based on a specific data

model agreed during the solution design phase.

FUN 15. Modifications of user requirements and the feasibility analysis before running the Service shall be

possible.

1.1.2.3 HMI (HUMAN MACHNE INTERFACE/INTERACTION) – PLATFORM

FUN 16. All the interaction with users will be done through the dedicated web Platform HMI.

FUN 17. A unique HMI interface shall be used to configure, manage, supervise and control user requests,

Products and the Data and Service Catalogue and the dissemination channels.




FUN 18. The web Platform shall provide the ability to define user roles and privileges and to link these to

individual geo-portal users or groups (e.g. access to different services).

FUN 19. The contractor shall propose and develop an advanced solution with user-friendly interfaces that

can ensure stable and guaranteed performance with independent number of elements managed

by the system and the number of orders triggered by users.

FUN 20. Platform’s HMI shall allow to display, navigate, zoom in/out, set scale, pan or overlay spatial data

sets or layers, transparency control, print and display legend information and any relevant content

of metadata and any other advanced functionality that can further assist End-Users.

FUN 21. User shall be able to select, view and overlay as much as possible data layers (using standard data

services).

FUN 22. The web Platform must be capable of passing a query to the Network Services (Adhering INSPIRE

Directive) and to gather the query responses and transfer these at client level.

FUN 23. Files stored (both raw data and services/products) in the Service Catalogue shall be available

through the system HMI.

FUN 24. All the generated services shall be displayed in an advanced web interface with cartography and

image manipulation tools (e.g. drag, pan, zoom). OpenGL and HTML5 are the preferred

technologies.

FUN 25. All the different types of information and derived services shall be displayed as independent data

sources. Thus, all types of information can be displayed as layers in a map.

FUN 26. All the documentation and HMI will be at least in English.

FUN 27. The interface shall provide a set of basic maps (GIS based). Among others, the following are

relevant: Nautical charts, Ice Charts, protected areas, Corridor lanes, Bathymetry information,

Static elements such as buoys, Harbour location, Weather forecast.

FUN 28. The Platform shall support a range of different basemaps such as Bing Satellite Maps, Google

Maps, Ovi Satellite Map, etc.

1.1.2.4 PERFORMANCE & MONITOR

FUN 29. The platform shall trace all requests indicating through log files: relevant rates of successfully

addressed requests, average time responding to new request, number of registered users, number

of unique visits, number and volume of satellite images provided, number and volume of other

data (in-situ, products), number of services provided in total.

1.1.2.5 SERVICE CATALOGUE

FUN 30. All the images and products/services shall be stored in a Service Catalogue by providing a metadata

table structure compatible with open-source web services, like OData (Open Data Protocol),

OpenSearch (Solr) and CSW (Catalogue Services for Web).

FUN 31. Each dataset and/or product shall be stored for a configurable time interval.




FUN 32. Service Catalogue shall allow the definition of personalized filters and queries through system HMI

to restrict the result subsets.

FUN 33. It shall be possible to request the download of any product from the Service Catalogue through the

main HMI of the service.

FUN 34. The Service Catalogue shall be designed for robustness over slow or unstable network connections.

FUN 35. The Service Catalogue shall support recursive and parallel downloading.

FUN 36. The Downloading mechanism shall be designed to be non-interactive in the sense that once

started, it does not require user interaction.

FUN 37. The Downloading mechanism shall be designed to support download through proxies.

FUN 38. The Downloading mechanism shall be designed to support HTTP/HTTPS connections when

available.

FUN 39. The Downloading mechanism shall be designed to support IPv6.

FUN 40. The Downloading mechanism shall be designed to support SSL/TLS.

FUN 41. The Downloading mechanism shall be designed to optimize downloading of files larger than 2Gbs.

FUN 42. The Downloading mechanism shall include a Bandwidth Control through throttled mechanisms.

FUN 43. The Downloading mechanism shall be designed to allow parallel downloading to speed up the

downloading process.

FUN 44. All layers (vector, raster, imagery) must be available for publication (apart from data that are

having restrictions).

FUN 45. All visualization files must be made available via both i) HTTP: Uploaded via HTTP through the HMI

Portal (once available) and ii) FTP: Available as Layer files (.lyr) and/or ArcMap Map Document

(.mxd) file via FTP.

1.1.2.6 SERVICE DISSEMINATION

FUN 46. The delivery channels of downstream services will be preferably sFTP, OGC Web Services (e.g. WFS,

WMS, CSW) or POST / REST services based on HTTP requests.

FUN 47. Each Service Provider shall implement the querying, transformation and routing of the output

results in order to provide these results to the users.

FUN 48. The solution shall include a Quality Evaluator with access to the Service Catalogue in order to

validate those products designated by the administrator.

FUN 49. It shall be possible to disseminate raw data (e.g. in-situ, satellite data) to the End-Users. The

implementation of a web service for this task will be held in favourable consideration.




FUN 50. Service dissemination shall manage the notifications to be sent to users when requested

services/products are available into the reserved physical space (notification by email of the

availability of the products associated to their URs, server and period of availability).

FUN 51. The text of the email shall be configurable.

FUN 52. All the products must indicate that the services/products are provided under EC funds and

Copernicus data.

FUN 53. For those services/products/data that are provided under ESA-User License the corresponding

Copernicus Copyrights clauses will be highlighted.

FUN 54. Derived reports produced by the downstreaming services shall indicate:

all types of data and sources,

methodologies and workflows,

all statements must be referenced with the corresponding source of information.

1.1.2.6.1 TYPES AND FORMAT OF SERVICE DISSEMINATION

Table 2 indicates the types and formats as minimum requirements of exposing all types of Geo-Information

that will be produced at PCP Phase 2.

Table 2: Types and formats of service dissemination

Output type Formats Characteristics

Geo-referenced

Map

Geospatial TIFF, JPEG 2000,

Geospatial Adobe Portable Format

(GeoPDF file)

A1 or A3 format Resolution 300 dpi (unless otherwise specified)

Layer Group File

• Vector data: .gdb, .shp, .kml, .kmz,

Directly ingested into corporate DB

• Raster data: .gdb, .jp2, .tiff, .tif

• Imagery up to the processing level

requested: .jp2, .tiff, .tif

• Visualization: .mxd, .lyr

If orthorectification is requested, then rectified,

referenced and radiometrically calibrated

imagery are required

Layer Group

Mapping

Services

Depending on the data type and purpose:

WFS or WFS-T, WMS, WMTS or WCS,

KML service

One or several services could be required to be

published via appropriate GIS servers

Report Adobe Portable Format (PDF file)

Microsoft Word compatible file

Optionally provided by the service in case the

complexity of the results require it

Printable Map

Series

Geospatial Adobe Portable Format (GeoPDF

file) A1 or A3 format Resolution 300 dpi (unless otherwise specified)

1.1.2.6.2 CARTOGRAPHIC SPECIFICATIONS

The following table indicates the Specifications for all cartographic products/services that will be exposed

under all downstream services.




Table 3: Cartographic specifications

Specification Description

Grids

Both Geographic Lat/Lon (ticks) and UTM Grid (lines) must be present in the map. Colour must be clear but not enough to interfere with features. Labeling of the grids must be:

DDMMSS.

Meters, with a different size applied to meaningful and meaningless numbers.

Grid sizes must adapt to the scale of the cartographic output.

Orientation Maps must be oriented to True North

Projection UTM (appropriate zone) on WGS84. Only in exceptionally small scales a different projection

should be used. In this case the ad-hoc projection will be specified during the activation.

Scale Bar Must have round numbers

Map Insets Map insets are recommended when areas of particular interest need to be highlighted.

Legend Must group feature thematically. Must fit with contents of the map unless it is a part of a map

series (where common legends are accepted).

Title A title must be included in the map.

Output Code The output code must be present in the map and used to name the file (both MXD and any

other required format).

1.1.2.7 DATA DICTIONARY

Data Dictionary is the categorization of geographical features into a catalogue of classes. Geographical

databases are built according to a Data Dictionary. Each geographical feature with a spatial representation

associated to it must belong to a certain category and will have attributes which can have values.

During the elaboration of the technical offer, the tenderers must provide a suggested data dictionary based

on the Multinational Geospatial Co-production Program (MGCP) TRD V4.0 extraction guidance with the

requirements listed below.

FUN 55. The data dictionary must include all layers suggested to provide each service.

FUN 56. It should be flexible enough to include modifications (adding categories, attributes or possible

values) to include ad-hoc layers.

FUN 57. Each layer and category should include a clear description in order to unambiguously identify and

define it.

FUN 58. The data dictionary must reduce the number of categories, attributes and values to the minimum

possible in order to ease handling and editing

The proposed data dictionary will be considered as a valuable input during the design phase (PCP phase 1)

in order to define the final database to be used during operations. However, it will be subject to updates in

order to tailor it to the user needs as expressed during the PCP Phase 2. The following definitions are

applicable:




Table 4: Data dictionary element

Data dictionary

Element Definition

Category Aggregation of thematically differentiated classes (e.g. transportation – road)

Spatial representation Area, point, line

Attribute Describes characteristics of a feature (e.g. Road Surface Type)

Value

An attribute will have one type of value only. Values can be of three different types:

Coded: limited list of possible text values

Actual: numeric value representing the real value of the attribute

Free Text

1.1.3 NON-FUNCTIONAL REQUIREMENTS

1.1.3.1 SW & HW

The tenderer should include in the detailed technical proposal a preliminary description of the Software

and Hardware architecture proposed for each Service explaining in detail the expected performances of

each Service and the proposed workflows from data collection planning, data acquisition, data preparation

including data pre-processing and value-added processing algorithms, product interpretation and report

production and dissemination.

NFUN 1. The Solution’s architecture should integrate flexible, reliable and scalable systems.

NFUN 2. All services shall be fully scalable (high cohesion - loosely coupling modular architecture).

NFUN 3. All interfaces shall follow modular and preferably based on open systems, ensuring the

expandability of the system (e.g. adding new feature services, making easily changes and

adjustments).

NFUN 4. The system shall be as dynamic as possible serving future needs (posing any issues in any system

modification/extension) such as expandability and maintainability.

NFUN 5. All components of the Service should be, if possible, reusable, meaning the feature to be used

(replicated) in different scenarios/services without changing or minimizing them if necessary.

1.1.3.2 AVAILABILITY AND RELIABILITY

The Services to be developed under the SATOCEAN Thematic Area shall support European Union policies

(e.g. Water Framework Directive – WFD and Marine Strategy Framework Directive - MSFD) by providing

information in response to Europe’s Environmental challenges. Due to the characteristics of the service the

Contractor shall describe the high availability, reliability and maintainability measures for retrieving

planned data sets by detailing the service levels.

NFUN 6. All services shall be highly available (24 x7), allowing most of its operational capabilities even with

the failure of one or more of its subsystems.




NFUN 7. The Services shall be able to continue operating despite receiving and processing invalid or wrong

data. Thus all services shall inform the End-User in case of any relevant occasions.

NFUN 8. The Services will provide high computing availability, having a continuous, uninterrupted, fault

tolerant Solution.

NFUN 9. The Availability shall be ≥ 99% where:

Agreed Service Time (AST)−downtime Availability (%) = x 100

AST NFUN 10. The Services support schedule will be developed to allow a continuous operation of at least two

months for each individual Service. The Contractor is responsible for ensuring sufficient

maintenance time before deployments.

NFUN 11. The solution shall be fully interoperable and shall be able to manage and coordinate the

interaction among the different services.

NFUN 12. The solution shall be fully scalable so that it can easily be adapted to new integration needs or

changes in performance, reliability and data volume requirements.

NFUN 13. The solution shall assure the proper scalability for a period of 5 years.

1.1.3.3 QUALITY CONTROL

During the elaboration of the technical offer, the candidate Contractor must provide a document (Quality

Control Plan) on how the quality control of data will be internally handled during the operation of the

services (Phase 3 and onwards). The contractor must abide to quality control measures. The Contractor

must perform data quality control procedures based on ISO 19157 that it has been adapted for the INSPIRE

implementation (please refer to “JRC Technical Reports on Data Quality in INSPIRE: Balancing Legal

Obligations with Technical Aspects”2 which presents the most commonly used data quality elements).

Further to this and in order to ensure high quality standards, the Contractor shall include additional data

quality measures or even commits to reach higher data quality thresholds.

NFUN 14. The contractor shall use as minimum ISO 19157standards for data quality and most the

commonly used data quality elements that are followed for INSPIRE Implementation.

1.1.3.4 MAINTENANCE

NFUN 15. The System shall provide audit mechanisms, registers and metrics that permit monitoring it.

NFUN 16. The Contractor shall inform all End-Users about downtimes of the services at least a week in

advance.

NFUN 17. The maintainability described as a measure of how quickly and effectively a service, component

or CI can be restored to normal working conditions after a failure shall be:

Maintainability (MTRS in hours) 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑠𝑒𝑟𝑣𝑖𝑐𝑒 𝑏𝑟𝑒𝑎𝑘𝑠

2 http://inspire.ec.europa.eu/documents/INSPIRE_/JRC83209_Online_Data_quality_in_INSPIRE.pdf

http://inspire.ec.europa.eu/documents/INSPIRE_/JRC83209_Online_Data_quality_in_INSPIRE.pdf





1.1.3.5 VERIFICATION

The main objective of the verification phase (PCP Phase 2) is to confirm that the services have been built in

the right configuration and with the expected technical performance level. The verification shall be

performed by measuring a set of quantitative indicators (MoPs - Measures of Performance) following the

procedures that will be agreed among the End-Users (PAs) and the contractor.

These MoPs, will be identified by the end-users (PAs) and could be adjusted following contractor’s technical

suggestions. MoPs will concern both the technical performance of each Service individually and of the

technical implementation of the SATOCEAN Platform as a whole.

The Contractor shall deliver all the appropriate tools (e.g. test environment, tools, procedures) that are

needed for the service and system verification.

1.1.3.6 TRAINING

NFUN 18. The Contractor shall train End-Users about the exploitation of the solution. This includes the

generation of the training material and the execution of the training sessions, without additional

costs for the Contracting Authority. Thus, a course of a minimum length of 48h for at least 6

persons with User role will have to be provided. Training courses will take place in PCP phase 3 of

the project.

It will be a ‘plus’ for the evaluation criteria of the proposal if the Contractor provides more courses. The

Contractor shall pay for all costs derived from the journey of End-Users (if needed) to attend the courses

and/or the web platform that will host the training sessions.

1.1.4 SPACE DATA COMPONENT

The European Space Agency (ESA) has been entrusted by the European Commission with the responsibility

of coordinating access to satellite data, including the Copernicus Contributing Missions (CCMs). ESA is

responsible for the management and implementation of the Copernicus Space Component Data Access

system3. Therefore, the contractors shall use and leverage on the Copernicus space infrastructure that it is

available (Sentinel Core ground segment4, Sentinel CollGS5, Contributing Missions6 etc.).

1.1.4.1 SATELLITE IMAGERY PROVISION AND THE CSCDA MECHANISM

The service provision will rely on the provision of Earth Observation (EO) imagery via the Copernicus Space

Component Data Access system (CSCDA) and upcoming Copernicus Data and Information Access Services

(DIAS)7. This will cover Sentinel data but also Very High Resolution (VHR) optical data and Synthetic

Aperture Radar (SAR) imagery.

To cover the need of very High Resolution (VHR) optical data and Synthetic Aperture Radar (SAR) imagery,

MARINE-EO will be supported with a dedicated DWH data quota to be used for Activations. The

characteristics of the imagery available for the Copernicus services are defined in the Copernicus Space

3 https://spacedata.copernicus.eu

4 http://www.esa.int/Our_Activities/Observing_the_Earth/Copernicus/Core_Ground_Segment 5 https://sentinels.copernicus.eu/web/sentinel/missions/collaborative/national-points-of-contact 6 http://www.esa.int/Our_Activities/Observing_the_Earth/Copernicus/Contributing_Missions_overview 7 http://copernicus.eu/news/upcoming-copernicus-data-and-information-access-services-dias

https://spacedata.copernicus.eu/


http://copernicus.eu/news/upcoming-copernicus-data-and-information-access-services-dias




Component Data Access Portfolio (DAP): Data Warehouse 2014 – 2020. It is the responsibility of the

Contractor to review the latest DAP version available. The Contractor shall be aware of the process of EO

data ordering as well as the parameters and conditions applicable to the Copernicus Contributing Missions,

as for example the delivery timeliness. Information about the Sentinel dedicated missions is available at the

Sentinel Online website.

Satellite data will be made available to the Contractor free of charge at the second and third phases of the

MARINE-EO PCP under the CSCDA mechanism procuring licensing for space data. After signing the

Framework Contract, the Contractor will be asked to sign the ESA-User license for the use of Copernicus

Contributing Missions data - Data Warehouse phase 2 (2014-2020)8 . Acceptance of this license is necessary

if data other than Sentinel and ESA data are to be downloaded. The Contractor will accept the licensing

terms and conditions applicable to the use of Copernicus Contributing Missions. It has to be highlighted

that access to the DWH mechanism will be provided through Marine-EO and all data will be used only

within the scope of the project and not for any other purpose either by the contractors or by the project’s

beneficiaries.

During the PCP phase 2 and 3, all the necessary technical and administrative arrangements will be

established for the appropriate use of the satellite imagery during the execution of the Framework

Contract.

The use of imagery from non-satellite but airborne sensors such as Unmanned Aerial Vehicle (UAV) and

aircrafts is not foreseen but can be proposed if it is a feasible solution by the Contractors.

The Contracting Authority may provide other imagery sources if the licensing conditions are equivalent or

better than those of the CSCDA mechanism and such alternative images: (i) are free of charge and do not

involve any additional cost, (ii) they do not create any additional administrative burden, and (iv) they are

properly credited in the Results. A part of this imagery could relate to open and free satellite imagery such

as Landsat, Modis or any other sensor.

1.1.4.2 ACCESS TO SATELLITE DATA

SAT 1. The Contractor will be responsible for ordering the imagery to ESA via the CSCDA mechanism and

will be the unique interface with ESA for the provision of the Service.

SAT 2. All the Activations must be acknowledged and approved by the End-User.

SAT 3. The identification, selection and ordering of the imagery will be performed by the Contractor. This

might require 24x7 services to deal with possible changes in the satellite acquisition planning,

cancellations and re-tasking of imagery.

SAT 4. For each activation the contractor must inform the End-User of the quota available and the expected

quota consumption.

8 https://spacedata.copernicus.eu/documents/12833/14545/DAP_Release_v2.2 (Contractor must use the latest version available at the Copernicus website)

https://spacedata.copernicus.eu/documents/12833/14545/DAP_Release_v2.2




SAT 5. The Contractor shall download the imagery, perform a Quality Control (QC) and report to the

EndUser the results of the QC and any incidences found so that MARINE-EO can take the

appropriate actions if necessary.

SAT 6. The Contractor must ensure the capacity for fast download, storage and process such EO imagery.

1.1.4.3 QUOTA AVAILABLE FOR PROTOTYPING, TESTING AND OPERATIONAL DEMONSTRATION

The proposed implementation roadmap for MARINE-EO consists of the implementation of consecutive

phases which include the set of activities necessary to achieve the goals of the Project and mitigate possible

future risk including the DWH quota management. The exact quota of available to test SATOCEAN services

shall be defined during the implementation of PCP Phase as there are a number of “Order Options” that

need to be specified such as Satellite Tasking, Data Delivery timeliness, Processing options, Cloud

Coverage Classes.

SAT 7. Potential costs in Satellite image acquisition arising for (e.g. unforeseen, additional testing) shall not

be possible to cover through this contract.

SAT 8. All acquisition requests through the DWH shall be previously validated by the End-Users of the

MARINE-EO Consortium. The End-User must be informed of: i) Estimated quota consumption, ii)

Quota Available, iii) Purpose, iv) AOI, iv) Dataset Used.

1.1.5 SOLUTION READINESS ASSESSMENT

A continuous readiness assessment of each Service delivered will be carried out in order to know the

maturity of the services that will be provided for real operations, as well as to evaluate and monitor the

progress of the development effort through the project lifecycle. Thereby, the contractor shall take into

account the following requirements:

SRL 1. PCP projects cover a specific part of the innovation cycle; therefore, the Solution’s TRL at the

beginning of the contract should be preferably 4 or 6. The contractor shall demonstrate the

evolution of this TRL level throughout the project lifecycle, aiming at the end of PCP phase 3 to reach

TRL 7-8.

SRL 2. The Contractor shall commit to provide, if it is required by the MARINE-EO Consortium, the

supporting information that properly justifies the Technology Readiness Level (TRL) that initially

claimed for the Solution. Definitions of the TRLs, description and required supporting information

are included in the "DoD TRA Deskbook (2009)".

SRL 3. The contractor shall commit to actively cooperate with the MARINE-EO Consortium in order to

execute, during the MARINE-EO project lifecycle, the following assessment points:

A post-CDR during the development phase after the Critical Design Review (Phase 2).

A post-V&V assessment after the execution of all Verification and Validation activities performed

during testing and operation phases (Phase 3).

SRL 4. The contractor shall engage in the assessment activities, mainly:




To become acquainted with the System Readiness Level (SRL) model that will be applied by the

MARINE-EO Consortium. SRL is a concept which offers an approximate measure of system/Solution

maturity as an aggregated measure of technology and integration readiness across elements and

interfaces, based on Technology Readiness Levels (TRL) and Integration Readiness Levels (IRLs).

To examine with the MARINE-EO Consortium the Solution's physical architecture which are

candidate items for a SRL assessment and to identify the Critical Technology Elements (CTEs)9,

classified as either primarily hardware or software. This will define the granularity level of the

network diagram for the Solution, which will lay the basis for the readiness assessment activities.

To answer timely and thoroughly to the TRL/IRL questionnaires designed by the MARINE-EO

Consortium, as many times as required, in order to get TRL/IRL evaluations as well as to compute

an assessment of overall Solution status via SRLs. The SRL scale is calculated by using a normalized

matrix of pair-wise comparisons of TRLs and IRLs that reflects the actual architecture of the

Solution.

To review and take part in the analysis of outcomes and elaboration of document status

(reports/roll-up charts) after each assessment point.

To provide supporting information, if required, which justifies the TRLs and IRLs obtained for each

Solution in each assessment point.

1.2 DOWNSTREAMING SERVICES’ SPECIFIC REQUIREMENTS

This section presents specific requirements derived after the analysis of feedback received from PAs,

bilateral discussions that took place with PAs, domain experts and current available solutions developed

under other framework contracts. For each qualified feature service the same methodology has been

followed. The methodology is articulated in logical steps including a short description of the scope and

relevant projects where similar solutions and/or services have been developed and/or currently are being

maintained. Then, a clear problem statement, a narrative description and operational areas are described.

All logical steps are formalized into functional and nonfunctional requirements.

1.2.1 SATOCEAN-UCS-1: MARINE ENVIRONMENTAL STATUS IN HOT SPOTS (AOIS E.G. GULFS, MPAS ETC.)

This feature service provides to the PAs ocean biotic and abiotic parameters by both satellite means (SAR,

visible thermal) and in situ data, together with long term analysis of the information that are both derived

from raw data or by products (developed based on raw data/information).

For the implementation of this feature service, the use of CMEMS services/products is of paramount

importance. The feature service shall allow processing of large amount of data and will use techniques like

data fusion of different sources with in-situ information sources. Furthermore, cross validation of data

between different types of data (e.g. ENVISAT, Sentinel, Radarsat) is needed.

9 The definition of a CTE is: “A technology element is “critical” if the system being acquired depends on this technology element to meet operational requirements (within acceptable cost and schedule limits) and if the technology element or its application is either new or novel or in an area that poses major technological risk during detailed design or demonstration” (DoD TRA Deskbook, 2009).




1.2.1.1 RELEVANT PROJECTS

Pilot service has been demonstrated i.e. it is part of ESA Sentinel Toolbox and an inter-connection with

CMEMS system is needed. Several EU projects aimed to this direction: Norsewind (FP7), ESA EOMD, MEECE

(FP7), DEVOTES (FP7), AQUAMAR (FP7), AZIMUTH (FP7), COBIOS (FP7), OSS2015 (FP7), C-TEP (ESA).

1.2.1.2 PROBLEM STATEMENT

Several problems have been identified for this feature service but they can be summarized/consolidated in

a broader common concept, concerning “the lack of a holistic approach”. In such approach all required data

from diverse sources (e.g. in-situ historical data from various national databases, long time series of buoy

measurements, in-situ data collected during multidisciplinary oceanographic cruises, in-situ experiments

for biological parameters) shall be combined in one single web application, serving needs of MARINE

authorities at typical operating conditions. In addition, several times within a year, MARINE authorities

need to visit different portals gathering, downloading, process the required information and then analyse

and correlate it with many others (e.g. in-situ, samples). Furthermore, this service will be connected with

the European Marine Strategy Framework Directive (MSFD 56/2008 EC) and the environmental status

assessment process. All Member States are currently in the process of MSFD implementation; they design

monitoring plans and suggest programs of measures to stakeholders. In this context, Marine-EO is a unique

opportunity to use innovative tools, such as EO for environmental status assessment. Actually this is a gap

that has been considered in several gap analyses by other EU projects, e.g. Devotes, EcApRHA, Action-Med

etc.

All the above will be integrated in MARINE-EO platform that will allow not only to show all types of data

services and other products (e.g. CMEMS) but also to apply some statistical analysis of the data and even

produce objectively analyzed interpolated parameter maps. In addition, under this service the development

of an alert functionality will be developed that will be based on long term data and the detection of

essential changes and/or extreme values.

1.2.1.3 NARRATIVE DESCRIPTION

The potential end-users of this feature service will be provided with information (a master file) related to

the status of the marine environment in a selected AoI on regular intervals (weekly). The end-user will have

access to a specific MARINE-EO platform, after subscription to the service “Marine environmental status in

hot spots”, and will be able to select which types of data/parameters to see/download, such as sea surface

temperature, salinity, chlorophyll-a, suspended matter, turbidity, transparency, currents, winds, water-

leaving radiances and primary production. Moreover, a tool to integrate satellite-derived chlorophyll-a

concentrations with environmental assessment thresholds will be developed in order to give scores and

thematic maps for environmental assessment. Finally, the detection of changes over time (trends,

anomalies, etc.) will be based on historical data.


The target areas will be of specific interest, for example, a coastal area that receives pollution pressures

(hot spot), etc. AoIs will include: Greece – Saronikos Gulf or any other relevant site with similar data

available in Spain - Golfo de Cádiz & Alboran Island; Portugal - MARINE Park of the Azores and selected

areas of the Natural Islands Parks of the Azores, Littoral Norte, Berlengas, Sintra-Cascais, RIA Formosa;and

Norway - Svalbard and Bjørnøya, Coral reef complexes (Røstrevet) that lie west of Lofoten Islands, and Ytre




Hvaler national park. Also the service shall be applied in Marine Protected Areas (MPAs) such as: Greece -

National MARINE Park of Zakynthos, Spain - Golfo de Cádiz & Alboran Island, Portugal - MARINE Park of the

Azores and selected areas of the Natural Islands Parks of the Azores, Littoral Norte, Berlengas, Sintra-

Cascais, RIA Formosa, and Norway - Svalbard and Bjørnøya, Coral reef complexes (Røstrevet) that lie west

of Lofoten Islands, Ytre Hvaler national park.

Table 5: User Scenario on the environmental status

Report on environmental status in hot spots areas

MARINE’s Authority agent shall be able to retrieve reports and parameters maps based on MARINE-EO web

platform in predefined AOIs.

End-User MARINE-EO feature

End-User will log and/or register into the system

The system either identifies or grants access to the

user.

The human-machine interface (HMI) has a content

based functionality for searching and accessing of

data.

End-User defines the quote type of data, resolution of

data, date, reliability of data/service based on

available in-situ measurements.

The platform returns the availability of data and

gives the option to the user to see more

information for each dataset, view it on a map,

and download the raw data for further analysis.

End-Users have the options to view more details for

each dataset, view them on a map, download or else

to change his/her search settings.

1.2.1.5 USER & DATA REQUIREMENTS FOR MARINE ENVIRONMENTAL STATUS IN HOT SPOTS (AOIS E.G. GULFS, MPAS ETC.)

This section converts all the above information into tangible and more precise necessities derived from a

combination of users’ feedback and state-of-the-art solutions that are currently being used in gathering

vital ocean parameters.

1.2.1.5.1 DATA REQUIREMENTS

Based on use of raw Sentinelsdata, CMEMS data and products/services and in-situ data:

1_DR_1. The Contractor shall extract important information (e.g. wind direction, wind speed, speed

wave direction and wavelength, chlorophyll-a concentration, suspended matter concentration

etc.)

1_DR_2. The Contractor shall offer long-term time series at the finest available spatial resolution (higher

than 1x1 Km).




1_DR_3. The Contractor shall use ship cruises data, if available by the Marine-EO end-users and/or other

sources, and fill in gaps (e.g. SST, Chlorophyll, SSH, ADT).

1_DR_4. Contractor shall design and implement a data model that will have to store many types of and

diverse data (raster and vector data) with different temporal, spatial resolution along with

error analysis information for each product.

1_DR_5. The Contractor shall deliver several parameters that are currently missing and/or not having

the appropriate resolution and accuracy from Med-CMEMS such as turbidity and primary

production, if available.

1_DR_6. The contractor shall propose a methodology to separate information layers for particulate

inorganic carbon (PIC), particulate organic carbon (POC), colored dissolved organic matter

(CDOM).

1_DR_7. The Contractor shall guarantee access to other climatological data from ECMWF, NOAA-NCEP

& satellite products from SeaWind (NOAA) that could contribute in enhancing spatial and

temporal resolution of datasets/parameters.

1.2.1.5.2 ACCURACY/RELIABILITY OF SERVICE

1_AR_1. The Contractor shall propose solutions to enhance both spatial (1x1km pixel size) and temporal

resolution of all ocean biotic and abiotic parameters (e.g. SST, Salinity, chlorophyll-a,

suspended matter, turbidity, transparency, reflectance and primary production).

1_AR_2. Very high resolution data shall be used on demand from contributing satellite missions (DWH),

in order to provide in higher resolution the predefined parameters (i.e. in smaller AoIs).

1_AR_3. The services shall be tested and validated in four different AOIs, covering all countries.

Proposed Areas are mentioned on Tender Document 1 – Request for Tender.

1_AR_4. MARINE-EO provider shall inform for each dataset/parameter the level of trust (reliability) and

performance in terms of availability of dataset.

1.2.1.5.3 SERVICE/FEATURE INTERFACES & FUNCTIONALITIES

1_IFR_1. The service shall be scalable and allow users to request applying the feature service in another

area of interest.

1_IFR_2. The Contractor shall ensure that the proposed solutions (based on Sentinel missions and

contributing missions) should be applied in areas such as Azores (North Atlantic), where the

CMEMS data and products do not provide the required resolution.

1_IFR_3. All data and products apart from the spatial, temporal and descriptive information must show

and contain error analysis information for each product.

1_IFR_4. The Contractor shall propose methodologies/models accommodating the scenarios. For

instance:

a. a methodology for gathering and exposing information (parameters and data that are

abovementioned) related to environmental status,

b. a methodology and a workflow that will illustrate the detected changes.




1_IFR_5. A content based search mechanism should be designed and proposed for semantic image

retrieval, storage and management of the extracted metadata both coming from data and

products.

1_IFR_6. MARINE-EO provider shall develop a more user friendly interface for non-gridded data

(currently provided via ftp) and provide a solution for the temporal extend of those files.

1_IFR_7. The Contractor will incorporate functionalities that are currently provided from NASA’s

Giovanni portal10 and Ocean color products11.

1_IFR_8. Contractor shall provide a new data extraction mechanism/interface based on a specified

temporal and spatial frame that will include both archival and processing services along with

all information.

1.2.2 SATOCEAN-UCS-2: FISH FARMS: DETECTION OF FISH FARMS THREATS

1.2.2.1 RELEVANT PROJECTS

There are some examples of applying dedicated solutions for fish farm monitoring such as SAFI project12

and AQUA-USERS13: AQUAculture USEr driven operational Remote Sensing information services.


Even though there is a lot of information related to ocean and sea parameters freely accessible by many

sources (e.g. CMEMS), there are quite few paradigms (e.g. mostly related to EC Research Funds) of applying

this critical information to a dedicated sector such as Fish Farming which is a fast-growing market14 and Fish

Farmers are not aware of the availability of such information.

This feature service is going to focus on specific Fish Farms identified by the end-users (e.g. AZA, fjord),

serving /addressing the detection of fish farms threats (e.g. harmful algae bloom) and the prediction of fish

farm threats based on environmental data coming from different sources (e.g. CMEMS, Sentinel, in-site).

Information of fish farm status and detection of threats can be provided as data services to law-

enforcement authorities that are interested (e.g. awareness and illegal activities in fish farm areas).


The feature service will be applied in selected aquaculture sites where previous massive fish-killing events

occurred with serious economic damages. During the period of MARINE-EO this service can be eventually

extended to a new aquaculture site if similar mass fish mortality rates are detected. The potential end-

users of this service shall be provided with information (a master file) related to chosen key parameters on

regular intervals (weekly). The end-users will have access to a specific MARINE-EO platform, after

subscription to the service “Detection of fish farm threats”, and will be able to select which types of

10 https://giovanni.sci.gsfc.nasa.gov/giovanni 11 http://oceancolor.gsfc.nasa.gov 12 http://www.safiservices.eu/en/SAFIPartners 13 http://www.aqua-users.eu/project 14 http://www.worldwatch.org/node/5444

https://giovanni.sci.gsfc.nasa.gov/giovanni/

http://oceancolor.gsfc.nasa.gov/

https://giovanni.sci.gsfc.nasa.gov/giovanni

http://oceancolor.gsfc.nasa.gov/

http://www.safiservices.eu/en/SAFIPartners

http://www.safiservices.eu/en/SAFIPartners

http://www.aqua-users.eu/project/




http://www.worldwatch.org/node/5444














data/parameters to see/download, such as sea surface temperature, salinity, chlorophyll-a, suspended

matter, turbidity, transparency and water-leaving radiance. A tool will be developed with the definition of

critical levels of satellite-derived chlorophyll a concentrations to give alert signals for potential fish farm

threats.


The target areas will be selected in aquaculture sites of central Greece, farming mostly seabream and

seabass and/or in any other European site with available data. In addition, the service shall be able to run in

both coastal and off-shore areas. The service shall indicate in a map the extent of all areas that the service

can be applied, giving also the functionality to End-Users for on demand requests in other areas.

Table 6: User Scenario on fish farm threats detection

Detection of fish farm threats

The feature service shall allow MARINE and law-enforcement authorities and/or farmers to monitor the fish farms’ environment based on long time series of historical data and extreme forecasts that can possibly destabilize the status.


End-User logs and/or registers into the main MARINE-EO’s platform

The system either identifies or grants access to the user.

The HMI provides an alert functionality that allows fish farmers and MARINE authorities to be informed for both extreme weather forecast and significant changes over the time

End-User among many areas selects the fish farms that need to be monitored and sets the relevant information e.g. weather extremes, Sea Surface Temperature, Chl-a, turbidity, wind, wave, current and anomalies in the coastal area or change detection such as sea grass beds, erosion or deposition on inter-tidal mud flats.

The system stores the information provided by the End-User and notifies/warns the End-Users about possible threats.

In case of an extreme forecast event or any substantial change a notification informs the End-User.

The user shall be able to log in to the system and see all the available information on a map and download all data and products.

1.2.2.5 USER & DATA REQUIREMENTS FOR FISH FARM: DETECTION OF FISH FARMS THREATS

The above scenario shall be integrated in the platform that will be self-sustained on operational activities

and lead to an increase of the efficiency and sustainability of fish farming activity by:




Incorporating satellite and geospatial data from various satellite missions (different modes of

Sentinel 1-2-3) and data repositories (e.g. CMEMS, C-TEP) for increasing the spatial and temporal

resolution,

Combining information on sea surface temperature, harmful algae blooms, fish diseases or

anomalies from information extracted by using systematically EO and in-situ measurements

through well adapted algorithms / modeling / automated workflow or machine learning

techniques.

Last but not least, this feature aims to be sustainable on an operational basis, following specific standards

that are applicable and transferable to the other areas of interest at regional level.


3_DR_1. The Contractor shall incorporate satellite and geospatial data from various satellite missions

(different modes of Sentinel 1-2-3) and data repositories (e.g. CMEMS, C-TEP) in order to

increase the spatial and temporal resolution.

3_DR_2. Contractor shall ensure the continuity of all-weather capability of C-band SAR data from

Sentinel-1.

3_DR_3. The Contractor periodically will have to use high-spatial resolution optical images from

Sentinel-2 & 3A for the environmental monitoring of fish farms (e.g. Ocean Land Colour

Instrument and Sea Land Surface Temperature Radiometer).

3_DR_4. The Contractor shall use the available CMEMS products, such as Bio-geochemistry analysis

and forecast for global and regional seas, and Geophysical parameters including sea surface

temperature and ocean currents which are important factors for fish farms.

3_DR_5. The Contractor shall propose the use of Contributing Missions data with an efficient and cost

effective use for the fish farm monitoring and to develop on demand request functionality of

very high resolution data (such as acquiring data when an important change - (threat) - near

fish farm is detected).


3_AR_1. The Contractor shall provide on a daily basis, horizontal maps indicating MARINE

pollution/threats together with all the available parameters (e.g. wind vector, currents, SST

and OceanColor data) either coming from in-situ measurements or from EO data with spatial

resolution below 1 km.

3_AR_2. The Contractor should leverage on methods applied in “Marine environmental status” feature

service, related to the enhancement of both spatial and temporal resolution.

3_AR_3. The Contractor shall propose a sustainable solution on an operational basis, following specific

standards that are applicable and transferable to the needs of several end users and pilot

areas at regional level.





3_IFR_1. The Contractor shall build upon CMEMS available products, such as Bio-geochemical data

and forecast for global and regional seas. Oceanographic parameters including sea surface

temperature and ocean currents.

3_IFR_2. Contractors shall take into considerations existing solutions and tools that are currently

available for fish farm monitoring, such as AQUASTREAM (or others) which is a disease

management tool based on a 3D numerical hydrodynamic model and provides critical

information for managing the risk of spreading diseases.

3_IFR_3. The Contractor shall provide easy online access to data services related to aquaculture

facilities (fish farms).

3_IFR_4. The Contractor shall validate the service in all four countries (Greece, Spain, Portugal, and

Norway).

3_IFR_5. The Contractor shall provide a service that will monitor water quality of fish farms and

provide an early warning functionality to the End-Users (fish farmers) about any threats,

either coming from pollution or from HABs, followed by corresponding (ocean colour) maps

that prove and illustrate the problem.

3_IFR_6. The Contractor, if possible, shall propose a solution leveraging on in-situ measurements (e.g.

multidisciplinary oceanographic cruises, inspections, data directly coming from fish farmers).

3_IFR_7. The Contractor shall provide a methodology of fusing in-situ, if available from end-users

and/or other sources, information with Earth Observation data, as well as long-term time

series of in-situ records, enhancing the scale and the resolution of the products in terms of

mapping scale and timeliness.

3_IFR_8. The Contractor should provide new methods for providing long term assessment of fish farms

activities.

3_IFR_9. The Contractor shall offer an interface that will provide in NRT (near real time) the status of

existing fish farms.

3_IFR_10. The Contractor shall offer an alerting mechanism for extreme weather forecasts and/or

changes based on long time series of historical data that include e.g. sea grass beds, coastal

erosion or deposition on inter-tidal mud flats.

1.2.3 SATOCEAN-UCS-3: DETECTION OF VESSELS AND ICEBERGS IN ARCTIC AREAS

1.2.3.1 RELEVANT PROJECT

There are few operational on-going vessel detection services in Arctic as well as Arctic monitoring services.

Some R&D for these services is POLARVIEW, ARKGIS Project, DOLPHIN KSAT and NEREIDS. KSAT has

delivered iceberg detection service to NOFO (Norwegian Clean Seas Association for Operating Companies)

to monitor activities in the Barents Sea. These are operational services today, however more research is

needed to better distinguish between vessels and icebergs. KSAT and FFI (Norwegian Defence Research




Establishment) have also an ongoing R&D project Satskip funded by NSC (Norwegian Space Centre) focusing

on improved methods for discriminating between ice and vessels.


This service is proposed to serve the needs of various bodies such as: the Norwegian authorities including

the “Norwegian Coastal Administration - NCA”; the “Search and Rescue – SAR”; the “Fisheries”; the

“Customs”; etc., as well as the ships navigator on board the ship, shipping industries (ship owners from all

countries with interest in the Arctic operations), the offshore industries, and the R&D institutions. It should

be assured that this service is replicable and thus can serve the needs for other MARINE authorities and

other areas. The service aims to provide a solution capable of enhancing the level of trust for Vessel and

Iceberg detection and providing reliable information on ice status and on forecast models near the AoI. The

information shall be accessible or shall be able to be sent digitally on demand to all types of users, including

the navigator on board the ship.

Ship’s navigators in the Arctic Sea need to operate in effective ways. Such requirement could mean

choosing optimum routes prior and during their voyage. Thus, compilation satellite images as well as other

types of information such as weather and wave height forecast are critical.

To achieve safety, security, and efficiency, and the reduction of emission to air, the service needs to provide

to the user on demand, a mean for communication and digital information sharing or information retrieval

of the processed data, taking into consideration the challenges of communication and broadband

limitations in the Arctic remote area.


The service of interest in this case is the detection (and tracking) of vessels (including mobile offshore units

and structures) and Icebergs (including all sizes and shapes).

All identified users are solely interested in vessel navigational safety, security, and operational

efficiency while conducting their activities in the Arctic Sea. Identifying and monitoring threats of

Icebergs to vessels and ocean structures is of great importance for better decision making to

ensure the safety, security and operation efficiency. Data for managing safety, security and

efficiency are expected to come from EO services provided by MARINE-EO & Copernicus, KSAT,

Sentinel, CMEMS data/services. Additional data sources could becommercial available satellites (for

example: RadarSat; TerraSAR-X; Cosmo Skymed), Aircraft photo as well as AIS-satellites services by

NCA and others, LRIT by EMSA. As far as possible, specific data takes shall be avoided and cost

minimized by using Sentinel data.

A satellite component (VDE-SAT) is being developed and tested (with the Norwegian NorSat-2

satellite), but the decision about allocating the satellite frequencies will not be taken before 2019.

VDE-SAT communications system will be possible for the competent authority on shore as well as

other parties to exchange digital information with the ship.

One of the major issues here stems from the reliability of the information that detects whether an

object is a vessel or an iceberg which is the most critical information for others stakeholder.

Another stems from the need to share the information to vessels in Arctic remote areas due to

communication and broadband coverage limitations. Thus, this service feature will:




o Combine images with positioning sources such as AIS, LRIT and VMS to increase the

reliability of the detection and to improve the usability of search and rescue, and other

types of emergency assistance or non-emergency assistance,

o Employ both advanced detection and discrimination of algorithms that contain false alarm

rate,

o Develop a more accurate model that will increase the reliability of the object recognition

and also improve the position of the object,

o Develop a stable and secure communication and broadband capacity and coverage to

deliver the product digitally to all types of users, and especially to Arctic vessel navigators

on demand and based on delivery mode.


NAVAREA XIX. As it is the responsibility area of Norway.

Table 7 User Scenario on Detection of vessels and icebergs in Arctic areas

Detection of vessels and icebergs in Arctic areas

Norwegian authorities, as well as other types of End-Users shall be able to receive, on demand, reliable digital information of the object type.


End-User logs and/or registers into the main MARINE-EO’s platform

The system either identifies or grants access to the user.

The HMI provides a functionality that allows the End-User to define an area of interest and be informed about vessel and/or iceberg detection, iceberg forecast, and the corresponding level of trust (high, medium, low)

End-User simply selects the AOI in NAVAREA XIX and chooses a delivery mode and time period for delivery.

Delivery mode: 1. Upon availability, the product is stored in the user profile, the end-user is then notified, and the user is able to download the product itself directly from the Marine-EO platform. 2. Upon availability, the product is stored in the user profile, the user is notified, and the system delivers the product digitally to the end-user, based on the time period of delivery set by the user. If the timeframe passes, and the system has not yet delivered the data, the data is stored in the user profile and the user is notified.

The system processes the request and informs the end user within 30 minutes if the specified AOI can be monitored. - If yes, the end user receives a successful message and the information is stored to the user’s profile. The response message shall include the time of the user request; the time of the record taken; and the time of the product delivery. - If no, the user is notified that information is not available. The user is notified to set the time period for the product delivery. When the information becomes available, the user is notified and action is taken based on delivery mode set by the user. In case of an emergency, a Copernicus Data Warehouse (DHW) quota will be requested. The response message shall include the time of the user request and the response time delivery.

End-User either can view or download the




Detection of vessels and icebergs in Arctic areas

information

1.2.3.5 USER & DATA REQUIREMENTS FOR DETECTION OF VESSELS AND ICEBERGS IN ARCTIC AREAS


4_DR_1. The Contractor shall base the service on data and products from CMEMS and more precisely

the Arctic Ocean-SAR Sea Ice Berg Concentration service, the Arctic Ocean–Sea Ice

Concentration Charts-Svalbard service, and the Arctic Ocean–Sea Ice Charts-Greenland service.

4_DR_2. The Contractor shall provide output from the Arctic Ocean Physics Analysis and Forecast

service using the operational TOPAZ4 system and the HYCOM model to provide 10 days

forecast of the 3D physical ocean, including sea ice.

4_DR_3. The vessels detection shall be followed by a timestamp (location, time), classification of

reporting or non-reporting, type of vessel and any other information that can be provided by

the AIS system (e.g. ship type and size, ship’s polar code, Speed, direction).

4_DR_4. The iceberg detection shall be accompanied with the status of the iceberg – forecast drift:

remote sensing methods for forecasting and routine monitoring of combined risk of waves and

ice, considering the marginal ice zone, ice forms, ice deformation, ice types, ice movement, ice

strength, ice classification, ice cycle, ice concentration color, ice distribution factors, ice drift

and routing.

4_DR_5. The Contractor shall make use of SAR and optical data (e.g. Sentinel-1, Modis, Sentinel-2).


4_AR_1. The Contractor shall provide Positioning (vessel/objects and icebergs) (lon, lat) accuracy

100m.

4_AR_2. The Contractor along with the type of object (vessels, offshore mobile drilling units, ocean

structure and/ or iceberg) shall provide also the reliability figure for the detection (high,

medium, low).


4_IFR_1. The Contractor shall propose a solution that it increases the accuracy based on the

combination of data (e.g. AIS, Satellite data).

4_IFR_2. The Contractor shall consider using TOPAZ4 system and the HYCOM model to provide 10 days

forecast of the 3D physical ocean, including sea ice.

4_IFR_3. The Contractor shall provide an innovative methodology that will inform the End-Users

whether an object is a vessel or an iceberg, the position of the object and the ice situation

close to the object.

4_IFR_4. The Contractor shall propose a methodology for automatic and more accurate object

recognition of vessels and icebergs together with the level of trust (see Accuracy/reliability of

Service).

4_IFR_5. The contractor shall be able to provide information on detected Vessel and icebergs 24x7.

Quality controlled analysis shall be delivered within 1 hour from satellite overpass. When the




data is available and retrieved from the Copernicus DWH, the delivery time shall be as soon as

possible, and within 1 hour.

4_IFR_6. The contractor shall develop optimum route suggestions for Arctic going vessels on demand,

based on compiled data and processed information regarding the vessel, the weather and wave

conditions, and the ice conditions.

4_IFR_7. The Contractor shall develop a system that will enable the delivery of product digitally to the

End-users upon request and based on the user delivery selection mode.

1.2.3.5.4 COMMUNICATION REQUIREMENTS

4_CR_1. The Contractor should provide a stable and secure data communication and broadband

coverage capacity to deliver the product digitally to the end-users and Arctic going vessels on

demand.




2 THEMATIC AREA 2 – SECURITY

The aim of this section is to describe the operational technical requirements for the definition and

implementation of added-value downstreaming services for the SATSURVEILLANCE Service in the security

domain.

The expected outcome is a set of services embedding operational workflows, which exploit Electro-Optical

and SAR-satellite data and deliver added-value to End-Users. The provision of outcomes facilitates the

users’ access to information avoiding the complexity of the whole process (including image collection,

acquisition, data preparation, automatic interpretation, analysis and production processes).

The following set of general requirements have been identified:

GEN 1. MARINE-EO platform shall provide new capabilities and/or improving current Copernicus services, in terms of timing, feature extraction performance, interoperability with legacy systems and end-user access.

GEN 2. MARINE-EO platform shall ensure confidentiality, integrity and security along the entire process.

GEN 3. It (MARINE-EO platform) shall allow information provided by MARINE-EO to be shared with other public authorities, as received or merged with other sources.

GEN 4. Required agreements among data/service providers and end-users shall be identified in order the end-users to have access to any data handled during implementation, operational testing and after MARINE-EO platform delivery.

GEN 5. A complete procedure to optimize data collection-cost tradeoff shall be made available to end users including performance assessments per target type and input EO data. As far as possible, specific data takes shall be avoided and cost minimized by using Sentinel data.

GEN 6. Research and innovation shall include optimization of performance through cutting-edge algorithms implementation to provide operational services. They should be intended to maximize detection and target feature extraction on Sentinels data including performance dependencies.

GEN 7. MARINE-EO SATSURVEILLANCE services shall be accessible through current communication networks deployed at authorities’ premises and compatible with models/formats agreed by user communities, particularly with data and service CISE model.

GEN 8. Services output structure shall allow merge part of the information with end-user own sources of information.

GEN 9. An analysis on sensor suitability versus surveillance needs including guidelines for service request planning shall be delivered. Surveillance needs should be established in terms of areas of surveillance, targets of interest, time frames, sea conditions and weather forecast.

GEN 10. An analysis of improvements introduced in operational capabilities (see 5.2.3) with respect to the state of the art in operational tools shall be provided. Potential of the better use of all channels included in EO products (optical bands, Infrared bands, amplitude and phase information, polarization information, radar bands, etc.) and assessment of improvement based on the operational implementation of algorithms using them shall be identified per capability.




2.1 KEYWORDS

In this document, the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",

"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC

211915:

MUST: This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute

requirement of the specification.

MUST NOT: This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute

prohibition of the specification.

SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in

particular circumstances to ignore a particular item, but the full implications must be understood

and carefully weighed before choosing a different course.

SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid

reasons in particular circumstances when the particular behaviour is acceptable or even useful, but

the full implications should be understood and the case carefully weighed before implementing any

behaviour described with this label.

MAY: This word, or the adjective "OPTIONAL", means that an item is truly optional. One vendor

may choose to include the item because a particular marketplace requires it or because the vendor

feels that it enhances the service while another vendor may omit the same item. An

implementation which does not include a particular option MUST be prepared to interoperate with

another implementation which does include the option, though perhaps with reduced

functionality. In the same vein, an implementation which does include a particular option MUST be

prepared to interoperate with another implementation which does not include the option (except,

of course, for the feature the option provides).

2.2 OPERATIONAL CONCEPT DESCRIPTION

The preliminary conceptual design schema is presented in Figure 2.

15

Request For Comments 2119. S. Bradner, Harvard University, March 1997. https://www.ietf.org/rfc/rfc2119.txt

https://www.ietf.org/rfc/rfc2119.txt




Service Catalogue

Satellite TaskingDWH / DIAS

EO Data Ordering

Data

Generate Products

Contractor

Req

uest P

rod

uct

s

Service 1

Service 2

HMI – GEO portal FTP

End-User

Existing Security Services

Border Surveillance

Maritime Surveillance

Support to EU External Action

Figure 2: Preliminary conceptual design schema.

1) The information flow starts with a User Request through an online website to a Service Provider

2) The Service Provider should have an Administrator validation approach, who shall be a technical

expert with deep knowledge on satellite information request and geospatial analysis. This

administrator shall provide also technical guidance to the Users, if needed

3) The Administrator is in charge of analysing the requests from the End-Users and performing user

request management tasks, including:

Establish the priority among possible several User requests.

Assess its feasibility (type of request, time range, etc.).

Analyse synergies or conflicts with other previous or on-going requests. Conflicts will be solved

by the Administrator.

Validate the User request.

4) The Service Acquisition Request to the Service Providers will generate a final product (detection,

tracking, etc.) which will be also stored in the Product Catalogue database.

a) Each Service provider will generate the corresponding Data Acquisition Request to the

Copernicus DWH DWH / DIAS / Copernicus Services Data Hub16 and will handle all the

acquisition requests and imagery downloads into the Product Catalogue database.

16 https://sentinels.copernicus.eu/web/sentinel/sentinel-data-access/typologies-and-services




Finally, the End-User (with the help of the Administrator) should be able to interpret and analyse the

Product (Data and/or Service) and to use it.

In the following lines, the main operational requirements are presented:

OP 1. The Contractor shall design, implement and maintain a Data Catalogue that will store the images

received from the Copernicus DWH.

OP 2. The Contractor shall design, implement and maintain a Service Catalogue that provides at least

one of the following SATSURVEILLANCE services:

o Enhanced Change Detection

o Unusual/irregular activity detection around critical

OP 3. The tenderer shall propose a solution that will provide a web-based system and an in-house

system (i.e. some modules to be installed on the End-User premises). Furthermore, the End-User

can have access to the DWH planning and imagery acquisitions with the possibility to download

them. Further information can be found on Section Error! Reference source not found.

OP 4. The Service Provider shall be able to receive orders from customers (User Requests - UR) through

its web interface.

OP 5. The Service Provider Administrator shall perform technical feasibility analysis as a response of UR.

o The feasibility analysis shall be based on the constraints included in the UR and the outcome

shall include a list of data providers fulfilling the users’ criteria.

o The feasibility analysis shall cover all the relevant missions accessible through Copernicus.

Among those, missions of interest shall be selectable.

o The feasibility analysis shall provide information about conflicts between the requested scenes

and other on-going requests.

o The Administrator shall check the possible overlapping with in-place requests.

o The Administrator shall confirm the validation status.

o The decision to resolve conflicts shall be left to the Administrator.

The operational validation of the MARINE-EO services will be carried out under common evaluation criteria

which will be decided among the MARINE-EO partners as defined by the end-users. The operational

validation is to be carried out solely by the MARINE-EO partners, as they are the End-users of the solutions

and they are in the position to measure how the different services contribute to improve their operational

tasks.

2.2.1 OPERATIONAL SCENARIOS

The MARINE-EO scenarios present two of the most challenging areas at the external borders of the

European Union as far as irregular migration and smuggling are concerned.

The following paragraphs describe possible areas for operations, where the services could be tested, to

provide a tender of the real and future evaluation environment for the developed solutions.




2.2.1.1 SERVICE 1 – OPERATIONAL AREAS FOR UNUSUAL/IRREGULAR ACTIVITY MONITORING AROUND A CRITICAL INFRASTRUCTURE

This service shall support the risk analysis and the risk management of a particular Critical Infrastructure by:

i. Detecting, recognising and identifying threats: designation of an object/entity whose

characteristics, behaviour or origin identifies it as a potential threat to the critical infrastructure.

ii. Monitoring threats: geolocating and tracking the designated threat detected in (i) during a specified

timeframe.

iii. Evaluating threats, the risk of incident occurrence and possible impact.

The service must allow setting of different stand-off distance thresholds or buffer zones (e.g. 50NM, 25NM,

5NM) around a critical infrastructure and/or around the EU coastline.

OP 6. The following functional capabilities related to critical infrastructure surveillance should be included:

Areas of interest management. Areas where geo-referenced polygons are processed independently and then information is merged to extract global analysis.

Non-collaborative vessels detection, features extraction and behavior analysis based on EO data and other auxiliary data, for instance AIS (spoofing, shutdown).

Suspicious vessel back-tracking in time series of images, AIS analysis and other possible sources of information.

Periodic reporting based on intelligence tools.

Any other identified by procurers.

Figure 3 includes the possible operational areas where critical infrastructures might be located under the

MARINE-EO project.

Figure 3: Service 1 - Unusual/Irregular activity monitoring around a Critical Infrastructure operational Areas




2.2.1.2 SERVICE 2 - OPERATIONAL AREAS FOR ENHANCED CHANGE DETECTION

This service aims at detecting evidence to support the hypothesis that certain irregular activity is taking

place in a specific area of interest (e.g. beaches/coasts are (or were) used for embarking/ disembarking

migrants, pre-frontier areas, etc.).

OP 7. The following functional capabilities related to change detection intended to irregular migration surveillance should be included:

Detection/no detection of vessels at possible departure sites taking into account specified targets of interest.

Evidence’s identification based on change detection analysis by using a group of EO products properly selected and scheduled.

Target(s) tracking estimation from EO data analysis. Adrift vessels detection and tracking estimation in a large area shall be included.

Frontex has identified the main operational areas of interest defining the main migratory routes that lead

to access to the EU by land and/or by sea (refer to Figure 4). Further information of each migratory route

can be found at Frontex website.

Figure 4: Enhanced Change Detection Operational Areas. Source: Frontex 17

FRAN and JORA data as of 5 May 2017

17 http://frontex.europa.eu/trends-and-routes/migratory-routes-map

http://frontex.europa.eu/trends-and-routes/migratory-routes-map













2.2.2 OPERATIONAL TARGETS

Service design should focus its efforts on several types of targets depending on the service, area of

operations (maritime/land) and the satellite Imagery available.

Tenderers, must describe in their proposal the expected targets that will be able to be detect with each

SATSURVEILLANCE service and the expected performances per target.

2.2.3 OPERATIONAL CAPABILITIES REQUIREMENTS

The following requirements cover operational concept analysis. They are aligned with the validation

strategy plan.

OP 8. Service definition shall be accessible to user and shall provide the access to set up service request: inputs, operational capabilities, outputs (visual and other type of information), schedule of information acquisitions and deliveries.

OP 9. Service definition shall allow creation, and reload of different AOIs as polygons.

OP 10.

Service definition shall allow selection of several operational capabilities available as processing workflows. Creation and reload of different workflows shall be allowed. Algorithm selection shall be handled here for capabilities implemented in more than one way. All the intermediate and final outputs per processing workflow shall be identified.

OP 11. Service definition shall allow selection of rules of vessel/target behavior and combination of them to create a behavior pattern that can be reloaded. Rules of behavior shall cover at least:

Detection in some AOIs created and/or selected with this specific purpose.

Vessel detection with no AIS information

No Vessel detected when AIS information indicate the contrary. (NOTE: this shall be used when EO input data and processing have the detection capability for the vessel and when EO data acquisition and AIS data stream cover the same timeframe)

Points of interest to be handled as reference in behavior rules can be created or reloaded.

Location within AOIs when backtracking based on AIS is applied. Movement behavior shall be handled as a possible refinement.

Relative location (meetings or parallel movement) between vessels or vessels to other point of interest (e.g. ports or other points on the coast) shall be included as a possible rule to be selected.

Movement/no movement identification on EO products.

Size or type of vessel.

Vessel(s) previously detected (in image time series analysis).

OP 12. Service definition shall include as inputs:

Monitoring period (dates from/to)

Data acquisition frequency (e.g. 1 per week/day).

Type of ancillary data to be handled (e.g. AIS or equivalent data, CMEMS, weather forecast) and the source of this data (for services generated at user premises sources for ancillary data can be internal).




OP 13. Service definition shall allow to propose corresponding EO product(s) inputs per each AOI.

OP 14. EO product(s) definition per AOI shall show different possibilities and restrictions for input data selection. It shall handle at least:

Coverage analysis by mission and acquisition dates (past or future). The user will select which products from those available are finally selected.

EO product(s) type and processing level.

Repetitive request for data acquisition for different time period, such us, each day, per week, etc.

OP 15. EO new acquisitions shall include data acquisition parameters selection per mission.

OP 16. Based on AOI, dates, weather forecast and targets of interest service definition shall propose EO

data products, auxiliary data, and processing workflow to the user.

OP 17. Service definition shall allow output delivery schedule management, including at least:

Only one delivery schema including or not intermediate outputs (layers)

Deliveries as soon as any intermediate or final product (layer) is generated.

Deliveries notification

OP 18. Service definition shall include trigger management definition based on possible results of rules

of behavior analysis. Automatic alert generation and manual alert generation depending on

results of rules of behavior analysis must be configurable.

OP 19. Service definition shall provide a check of service definition coherence, identify problems, and

generate a report with service definition and performance assessment for outputs. If the service

definition do not pass the check, the point of service definition where the first problem arises

shall be notified to the user to be changed accordingly.

OP 20. Detection and feature extraction capabilities for vessels shall include at least:

Target detection

Target physical features

Target movement parameters (yes/no, orientation/direction, turn, speed, )etc

Target classification (vessel types)

Target identification in data time series

They should use current Copernicus services (e.g. CMEMS) as input when available or applicable.

Performance assessment in detection and feature extraction capabilities versus inputs shall be

provided.

OP 21. Behavior analysis capabilities shall cover rules of behavior (see OP 11) and enable their

combination at will to provide meeting identification, suspicious track and repetitive behavior

detection.

Performance assessment in behavior analysis capabilities versus inputs shall be provided.




OP 22. Forward position estimation capabilities should use current Copernicus services (e.g. CMEMS) as

input when available and shall provide:

Most probable area of location for one time and at time steps if required

Most probable direction

Performance assessment in position estimation capabilities versus inputs shall be provided.

OP 23. Change detection in ports shall identify changes in general and in specific targets (ships, one

type of ship, buildings, cranes, vehicles, etc.).

Performance assessment in change detection capabilities versus inputs shall be provided

OP 24 Change detection in coastal areas shall identify changes in extended targets (e.g. forest, urban

area, crop fields, etc.) and objects (e.g. buildings, paths, communication infrastructures, etc.).

Performance assessment in change detection capabilities versus inputs shall be provided

OP 25. Alert handling shall include a "by default" automatic notification process. Alert structure should

be compatible with CISE event model.

OP 26. Re-planning capabilities shall be included at least for EO product requests involving new

acquisitions. Timeline associated to each mission shall be known and procedures implemented.

OP 27. Service outputs with position information (e.g. vector, raster, location) shall be interoperable

with most common GIS tools.

OP 28. Delivery time line shall allow dissemination of part of the complete service as soon as available. Such as: • EO products from missions when requested

• Detection analysis on time series (one delivery after each acquisition)

• Tracking estimation updates

• Others

Time to service delivery after EO product reception (at Service Provider) shall be minimized.

Ideally, first results (intermediate services, such as vessel detections) should never be longer

than 15 minutes for areas of about 250x250 Km2 and 5 minutes for areas of about 10x10Km,

past time series analysis could exceed these thresholds.

OP 29. Interoperability with other analysis of information tools should be considered by design.

Specifically outputs should be directly interoperable with tools based on CISE data and service

model.

2.2.4 REQUIREMENTS FOR OPERATIONAL CAPABILITIES VALIDATION

A complete operational validation will be carried out over the last months of PCP Phase 3. Three levels of

testing are foreseen to be carried out during the phase 3. Firstly, a simulation level intended to validate at

this level, vessels and change detection, identification, data fusion, position tracking (back and forward),

interoperability, rules and reporting capabilities and dependencies. Secondly, a simulated real time level




adds planning, timing, processing and data flows validation. Finally, real operation level will cover complete

operational trials.

Over previous phases, operational validation needs will be traced in order to guarantee appropriately final

Marine-EO platform compliance with operational needs.

A key point to meet this objective is the selection of test data-sets. Those data-sets have to be suitable to

evaluate, among others, the ultimate performance of Marine-EO operational results. At previous phases,

validation tests should use these test data-sets covering complete operational needs to validate

requirements, such as those related to functional and performance validation for service capabilities, load

tests, interoperability, data or processing workflows.

Selection of Earth Observation data for testing purposes is driven by scenarios analysis mainly by

capabilities to be tested, areas of interest, surveillance goals, EO products use optimization, interoperability

and execution threads.

Having taken into account the abovementioned, following requirements have been identified.

DAT 01. Any type of relevant data accessible from Copernicus shall be identified and actually included in

tests.

DAT 02. Data covering largest AOIs and longest period of time considered in validation shall be used,

specifically a use case with the following coarse planning:

250 x 250 Km2 monitored for 3 weeks based on Sentinel 1 and Sentinel 2 images (The

number of EO products considered to be handled depend on the available revisit times of

both Sentinel 1 and 2).

80 x 40 Km2 monitored for 3 weeks based on optical or radar contributing missions (The

number of EO products considered to be handled are roughly equivalent to 2 per day and

approximately at 5 m x 5 m spatial resolution).

10 x 10 Km2 monitored for 3 weeks based on Very High Resolution optical or radar

contributing missions (Number of EO products considered to be handled are roughly

equivalent to 1-2 per day and at a spatial resolution better than 1.5 m x 1.5 m).

Regarding data load and flows, a worst case analysis shall be carried out.

DAT 03 At least a complete test data set selected to replicate a real situation equivalent to each one of

the use cases tested shall be agreed with end-users at the beginning of design phase.

DAT 04 Data requirements arising from contractor project development should be identified in PCP first

phases.

DAT 05 Real time test data set reproduction capability shall be provided by contractors and deployed

accordingly at the beginning of the set-up phase.




2.3 FUNCTIONAL REQUIREMENTS

In the next lines, a comprehensive list of functional requirements is proposed, categorised into general

functional requirements, UR general requirements, GUI-geoportal general requirements, Archived Imagery

Search and New Acquisition Planning Tool, product catalogue and product dissemination requirements. The

list is rather exhaustive, however, additional requirements can be proposed and included in the list.

SYS 1. Each Service shall be built on common standards and service-oriented architecture.

SYS 2. Each Service shall be prepared to interact with other data sources and external systems through

the use of standard interfaces.

SYS 3. The web interface shall support the following browsers: Internet Explorer 9, 10 and 11, Edge,

Firefox and Chrome (in their latest version available). Moreover, a mobile compatible version,

using relevant libraries, shall be provided.

SYS 4. The analysis and design shall be done using the UML (Unified Modelling Language) sketches,

blueprints and methods.

SYS 5. The analysis, design and implementation of the new developed software shall be object-

oriented.

SYS 6. The selected data interchange mechanism between each Service and the external entities shall

guarantee:

• Asynchronous.

• FIFO queue.

• Confidentiality, identity and data coherence.

• No data loss.

• Message or file based.

• The system will define some backup mechanism, to keep a copy of every interchanged

message for a period of time.

SYS 7. All the interfaces shall be XML based.

SYS 8. Each Service shall validate all inputs against agreed XML schemas.

SYS 9. Each Service shall use the external interfaces adequately secured and it shall allow, mainly, FTP

and HTTP protocols. Any deviation of this requirement shall be justified.

2.3.1 USER REQUEST (UR) GENERAL REQUIREMENTS

SYS 10. A set of basic functions like creation, modification and cancellation of the UR shall be made

available.

SYS 11. The User Request Interface shall manage locations by the use of place-names by means of:

• Geo-names

• Previously names assigned by the user (tagged)

• Stored areas of interest




SYS 12. It shall be possible to edit and delete already stored areas of interest. A UR can be associated

with one or more areas of interest at the same time.

SYS 13. Each request shall be associated with a state. The supported states will depend on the kind of

request but the list will contain at least:

Saved: the order is created and saved in the system but it has not been submitted for validation yet.

Defined: the order is created by the user and submitted, however, it has not been validated by the Administrator.

Validated: the order has been technically validated.

Approved: The Administrator has approved the request.

Received: the service providers’ data has been received.

Rejected: the provider has not accepted the request.

Cancelled: the user has cancelled the order.

Discarded: The Administrator has not approved the order.

Concluded: the time period for the product availability for the user has finished and the product has been successfully removed from the exchange area.

Error: if any error is detected during the process. The Tenderer can propose a new status terminology and new associated states.

SYS 14. The System shall allow the supervision of the UR status with at least the following characteristics:

• Time ranges.

• Priority types.

• Requests types.

SYS 15. Feasibility analysis shall be shared with the user through the GUI system, with a specific data

model agreed during the solution design phase.

SYS 16. UR and feasibility analysis modifications before running the Service shall be possible.

2.3.2 GUI – GEOPORTAL GENERAL REQUIREMENTS

SYS 17. All the interaction with users shall be done through the dedicated Geo-Portal GUI.

SYS 18. A unique GUI interface shall be used to configure, manage, supervise and control UR, Products,

Data, Service Catalogue and the dissemination channels.

SYS 19. The GeoPortal shall provide the means to automatically include content provided by other open

sources and User Requests (e.g. drag and drop)

SYS 20. Users should be able to store/archive their search criteria and preferences; configure the default

map and its extent; store and share maps with other users and choose and store their preferred

language.

SYS 21. The GeoPortal shall provide the ability to define user roles and privileges and to link these to

individual geo-portal users or groups (i.e. access to different services).




SYS 22. The Contractor shall develop a user-friendly interface to provide stable and competitive

performance with independence of the number of elements managed by the system and the

number of orders triggered by users.

SYS 23. The GeoPortal GUI shall allow to display, navigate, zoom in/out, pan or overlay spatial data sets

or layers, transparency control, print and display legend information and any relevant content of

metadata.

SYS 24. The GeoPortal must be capable of passing a query to the Network Services (e.g. adhering to

INSPIRE Directive18) and to gather the query responses and transfer these at client level.

SYS 25. Files stored in the Product Catalogue shall be available through the GUI system.

SYS 26. All the generated products shall be displayed in an advanced web interface with cartography and

image manipulation tools (including drag, pan, zoom, etc.). OpenGL and HTML5 are the preferred

technologies.

SYS 27. All different types of information and derived products shall be displayed as independent data

sources. The following layers are foreseen (more can be added in accordance to the developed

services and system needs):

• Cooperative (AIS, LRIT, VMS). The screen shall display by default the last reported position

of each monitored vessel.

• Anomalies.

• Quick-look versions of all the processed imagery (either optical or SAR images).

• Route propagation estimates.

SYS 28. All the documentation and Graphical User Interface (GUI) must be in English.

SYS 29. The interface shall provide a set of basic maps (GIS-based). Among others, the following are

considered:

• Nautical charts.

• Corridor lanes.

• Bathymetry information.

• Static elements (e.g. buoys).

• Harbour locations.

• Weather forecast

• Open Street Map

• Possibility to choose as a layer anyone of the following online raster providers:

Bing Satellite Maps, Google Maps, Ovi Satellite Map, etc.

SYS 30. GUI shall support visual representation of all the EO images provided by Copernicus and Contributing missions:

Complete image at best resolution (band selection and combination)

Quick looks

Part of the image

18 http://inspire.ec.europa.eu

http://inspire.ec.europa.eu/

http://inspire.ec.europa.eu/




SYS 31. GUI shall include geocoding capabilities for images from services and from EO products from Copernicus and Contributing missions.

2.3.3 ARCHIVED IMAGERY SEARCH AND NEW ACQUISITION PLANNING TOOL

SYS 32. The GeoPortal shall allow access to search Archived Imagery from different commercial providers

and Acquisition Planning Tool to help the End-User to provide more details on the User Requests

(UR), if needed.

SYS 33. The Archived Imagery Search and Acquisition Planning Tool shall allow to search for archived

imagery or possible satellite passes over an AoI with the following parameters:

• Sensor

• Incidence angle

• Cloud cover

• Timeframe

• Catalogue Identification code, footprint and quick look (for archived imagery)

SYS 34. The tool shall indicate the amount of images already available and it shall generate a shapefile

with the AoI not covered by the archived imagery.

SYS 35. The GUI system must include an Acquisition Planning Tool to provide time estimations when a

satellite will make an optimum pass above a given AOI within a specific time period and

additional observation constraints.

SYS 36. The tool must allow the End-User to upload an AoI (at least in KML format; other vector formats

could be considered) and to compute the satellite overpasses during the time window, AoI and

acquisition angle specified by the End-User.

SYS 37. The tool will compute for each satellite:

• Satellite, sensor name, resolution

• Sensing Start Date (UTC)

• Sensing End Date (UTC)

• Pass duration

• Pass direction

• Incidence angle (degrees)

SYS 38. The Acquisition Planning Tool shall be able to estimate the satellite overpasses of all the

satellites included under the latest version of the. Copernicus Space Component Data Access

Portfolio19.

SYS 39. The tool shall also provide an estimation of the cost of acquiring an image (new acquisition or

archived) directly from the Satellite image provider and also the consumption of the Copernicus

DWH quota if the image was to be acquired through this mechanism.

19 https://spacedata.copernicus.eu






2.3.4 PRODUCT CATALOGUE GENERAL REQUIREMENTS

SYS 40 All the images and products shall be stored in a Product Catalogue by providing a metadata table

structure compatible with open-source web services, like CSW (Catalogue Services for Web).

SYS 41. Each data service and product shall be stored for a configurable time interval.

SYS 42. The Product Catalogue shall allow the definition of personalised filters and queries through GUI

system to restrict the results subsets.

SYS 43. Download request from any product in the Product Catalogue shall be possible through the main

GUI of the service.

SYS 44. The Product Catalogue shall be designed for robustness over slow or unstable network

connections.

SYS 45. The Product Catalogue shall support recursive and parallel downloading.

SYS 46. The Downloading mechanism shall be designed to be autonomous, not requiring user interaction

once the download has started.

SYS 47. The Downloading mechanism shall be designed to support download through proxies.

SYS 48. The Downloading mechanism shall be designed to support HTTP/HTTPS connections, when

available.

SYS 49. The Downloading mechanism shall be designed to support IPv6.

SYS 50. The Downloading mechanism shall be designed to support SSL/TLS.

SYS 51. The Downloading mechanism shall be designed to optimise downloading of files larger than 4GB

SYS 52. The Downloading mechanism shall include a Bandwidth Control through throttled mechanisms.

SYS 53. The Downloading mechanism shall be designed to allow parallel downloading in order to speed

up the downloading process.

SYS 54. All layers (vector, raster, imagery) must be available for publication via:

1. Catalogue DB: Uploaded or edited directly in the Catalogue DB or via WFS or

REST Map.

2. FTP

SYS 55. All visualisation files must be made available via:

1. HTTP: Uploaded via HTTP through the GUI Portal (once available).

2. FTP: Available as Layer files (.lyr) and/or ArcMap Map Document file (.mxd) via

FTP.

SYS 56. All required output files must be made available via:

1. HTTP: Uploaded via HTTP through the GUI Portal.

2. FTP.




2.3.5 PRODUCT DISSEMINATION GENERAL REQUIREMENTS

SYS 57. The Product Dissemination (PD) delivery channels will be preferably sFTP, OGC Web Services

(WFS, WMS, CSW, etc.) or POST / REST services based on HTTP requests.

SYS 58. The outputs generated by the services shall be compliant, as much as possible, with the latest

version of EUCISE2020 Data Model and services20.

SYS 59. The solution shall include a Quality Evaluator with access to the Product Catalogue in order to

validate the products designated by the administrator.

SYS 60. It shall be possible to disseminate raw data to the End-Users. The implementation of a web

service for this task will be held in favourable consideration.

SYS 61. It shall be possible to consult the status of the Product Dissemination (PD) at any point.

SYS 62. PD shall manage the notifications to be sent to users when products are available into the

reserved physical space (notification by email of the products availability associated to their URs,

server and products availability period).

SYS 63. The email text and content shall be standardized and configurable.

SYS 64. All products must indicate that the services/products are provided under EC funds and

Copernicus data by having the Copernicus Logo.

SYS 65. For those services/products/data provided under ESA-User License, the corresponding

Copernicus Copyrights clauses will be highlighted.

SYS 66. Any additional derived reports produced and included in the downstreaming services shall:

• Avoid reproducing/ duplicating already existing analysis (Frontex, UNODOC,

IOM, etc.)

• Be supported by references (citing the information source accordingly)

• Source and information reliability must be classified according to the FM 2-

22.31221

• All statements must be referenced with the corresponding source of information

• Bibliography and sources must be included in the report using ISO 690:2010

Information and documentation – Guidelines for bibliographic references and

citations to information resources

2.3.5.1 IMAGERY

SYS 67. All the images to be delivered shall be compliant with the following requirements:

• Georeferenced image in Earth geometry, corrected from off-nadir acquisition

and terrain effects

• The acquisition angle shall be as low as possible

• The provided image shall be co-registered, orthorectified and projected in the

corresponding UTM zone (other projections on request)

20 http://www.eucise2020.eu 21 http://fas.org/irp/doddir/army/fm2-22-3.pdf

http://www.eucise2020.eu/

http://www.eucise2020.eu/

http://fas.org/irp/doddir/army/fm2

http://fas.org/irp/doddir/army/fm2

http://fas.org/irp/doddir/army/fm2-22-3.pdf







• The product encoding shall be 12 bits for JPG2000 format, 16bits for GEOTIFF

format

• Imagery shall be provided in the following formats: o JPEG 2000, optimised

compression (3.5 bits/pixel) o JPEG 2000, regular compression (8 bits/pixel) o

GeoTIFF (uncompressed)

• All the images (and chip images) acquired and delivered through the Product

Catalogue shall include, in the metadata and filename, the acquisition date and

time and the sensor used.

• Chip images should be provided no later than 30 minutes after the image FTP

delivery by the CCME or Copernicus DWH CDS. The consortium seeks

competitive delivery times and the tenderers should try to minimize

information delivery.

2.3.5.2 TYPES AND FORMATS

The following output types and formats would potentially be required. The final list of output types and

formats to be produced must be defined at PCP Phase 2.


Geo-referenced Map

Geospatial TIFF

JPEG 2000

Geospatial Adobe Portable

Format (GeoPDF file)

• A1 or A3 format

• Resolution 300 dpi (unless otherwise specified)

Layer Group File

Vector data:

o .gdb

o .shp

o .kml , .kmz

o Directly ingested

into corporate DB

Raster data:

o .gdb

o .jp2

o .tiff, .tif

Imagery up to the processing level requested:

o .jp2

o .tiff, .tif

Visualization:

o .mxd

o .lyr

If orthorectification is requested, then rectified, referenced and radiometrically calibrated imagery are required





Layer Group Mapping Services

Depending on the data type and purpose:

WFS or WFS-T

WMS, WMTS or WCS

KML service

One or several services could be

required to be published via

appropriate GIS servers

Report

Adobe Portable Format (PDF file)

Microsoft Word compatible file

Optionally provided by the service in case the complexity of the results requires it

Printable Map Series

Geospatial Adobe Portable

Format (GeoPDF file)

• A1 or A3 format

• Resolution 300 dpi (unless

otherwise specified)

2.3.5.3 CARTOGRAPHIC SPECIFICATIONS

The following specifications are applicable to cartographic production:

Specification Description

Grids Both Geographic Lat/Lon (ticks) and UTM Grid (lines) must be present in the map. Colour must be clear but they should not interfere with features. Labelling of the grids must be:

DDMMSS

Meters, with a different size applied to meaningful and meaningless numbers

Grid sizes must adapt to the scale of the cartographic output

Orientation Maps must be oriented to True North

Projection

UTM (appropriate zone) on WGS84. Only in exceptionally small scales, a different projection should be used. In this case, the ad-hoc projection will be specified during the activation.

Scale Bar It must have round numbers

Map Insets Map insets are recommended when areas of particular interest need to be highlighted

Legend Legend must group features thematically. It must fit with map contents unless it is a part of a map series (where common legends are accepted)

Title A title must be included in the map.

Output Code (or

production code)

The output code must be present in the map and it must be used to name the file

(both MXD and any other required format)

Copyrights and disclaimers

The corresponding Copernicus Copyrights and the relevant disclaimers should be included.




2.3.6 DATA DICTIONARY

Data Dictionary is the categorization of geographical features into a catalogue of classes. Geographical

databases are built according to a Data Dictionary. Each geographical feature with an associated spatial

representation must belong to a certain category and it will have attributes with values.

During the elaboration of the technical offer, the tenderers must provide a suggested data dictionary based

Multinational Geospatial Co-Production Program (MGCP) TRD V4.0 extraction guidance with the

requirements listed below.

DIC 1. The data dictionary must include all layers suggested to provide each service.

DIC 2. It should be flexible enough to include modifications (adding categories, attributes or possible

values) to include ad-hoc layers.

DIC 3. Each layer and category should include a clear description in order to unambiguously identify and

define it.

DIC 4. The data dictionary must reduce the number of categories, attributes and values to the minimum

possible in order to ease handling and editing.

DIC 5. Data dictionary shall be compliant with last CISE data and service model version compliant for layers already included and an upgrade of the model for new layers.

The proposed data dictionary will be considered as a valuable input during the design phase (PCP phase 1)

in order to define the final data dictionary to be used during operations. However, it will be subject to

updates in order to tailor it to the user needs as expressed during the PCP Phase 2.

The table below presents the applicable definitions.

Table 8: Definitions applicable for each data dictionary element

Data dictionary Element Definition

Category Aggregation of thematically differentiated classes (e.g transportation – road)

Spatial representation Area, point, line

Attribute Describes each feature characteristics (E.g Road Surface Type)

Value An attribute will have only one type of value. Values can be of three different types:

• Coded: limited list of possible text values

• Actual: numeric value representing the real value of the attribute

• Free Text

2.4 DOWNSTREAMING SERVICE SPECIFIC FUNCTIONAL REQUIREMENTS

Copernicus, the European Union Earth observation and monitoring programme, entered into force in 2014

producing a wealth of data and information regarding the Earth (land, atmosphere, oceans) and cross-

cutting processes (climate change, emergency and security). Such information can be very helpful to

support the decision making of the Member States. At the same time, such information needs either

adaptation to local conditions and contexts or adaptation to the specific needs of public authorities as part




of workflow and procedures. The challenge is, therefore, to foster exploitation of Copernicus information to

match the needs of public authorities at national, regional or local levels.

MARINE-EO users have analysed what sort of technical Satellite imagery algorithms to be used in data

preprocessing and value added generation that could contribute to overcome their main operational

obstacles and thus to further develop the current surveillance capabilities.

These image exploitation technologies have been grouped in two different categories. Each category

provides a different contribution to the development of surveillance capabilities, understanding capability

as the ability to achieve a particular operational effect. The proposed technologies are not the only ones

that could be considered in MARINE-EO, additional technologies could be added. The services proposed by

the tenderers (under the SATSURVEILLANCE Service) could employ a different set as long as it fits the

challenge.

Optical and multispectral methods include unsupervised approaches, supervised and knowledge-

based approaches, pixel-based and object-oriented approaches, multivariate alteration detection,

hyperspectral approaches and approaches that deal with changes between optical images and

existing vector data, man-made object recognition, crowdsourcing features extraction, etc.

Radar methods include constant false-alarm rate detection, adaptive filtering, multi-channel

segmentation, hybrid methods and coherent detection, edge detection and features extraction,

uncoherent change detection, MTC and classification, Radargrammetric digital modelling, SAR

Signature analysis, SAR polarimetric and intereferometric methods for detection and modelling,

etc.

SEV 1. The contractor must design a complete service comprising a full solution which considers all

necessary workflows including data collection planning, data acquisition, data preparation and

data pre-processing (e.g. co-registration, calibration), value-added processing algorithms (e.g.

interferometric coherence, coefficient of variation, digital elevation), product interpretation and

report production and dissemination.

Figure 5: Service operational workflow model




Figure 6: Workflow description example

It is worth mentioning again that the employment of the technologies cited above is not mandatory, but

presents a comprehensive reference list of technologies considered by the Users as most relevant for

overcoming the operational obstacles present in the MARINE-EO scenarios.

The following Sections describe a possible concept of operation with different working modes for the

Unusual/Irregular activity monitoring and Enhanced Change Detection. However, the MARINE-EO

consortium welcomes new innovative ideas by the tender to address these challenges with the use of

satellite imagery as the main source of information.

During the elaboration of the technical offer, the tenderers must provide:

Concept of Operations for each proposed Service and mode of Operation.

Detailed description of the proposed workflows and associated algorithms. Figure 6 shows an

example on how to describe workflows

Expected performances of each Mode of operation (i.e maximum AoI to be requested, timeliness,

etc.)

Expected outputs of each service, duly described.




The tenderers must show in their proposal a solid understanding of the working procedures and possible

expected performances for each Copernicus Contributing Mission Entity (CCME) of the Copernicus Program

and the Copernicus Space Component Data Access system including the latest Data Access Portfolio22.

Tenderers are advised to consult information on the Copernicus programme23 where the evolution topics

are identified as well as the availability of Copernicus Sentinel Data. Access to Copernicus Contributing

Mission data is provided at the Commission’s website24.

2.4.1 SERVICE 1: UNUSUAL/IRREGULAR ACTIVITY MONITORING AROUND A CRITICAL INFRASTRUCTURE

A Critical Infrastructure is an asset or system essential for the maintenance of vital societal functions.

Damage to a critical infrastructure, its destruction or disruption by natural disasters, terrorism, criminal

activity or malicious behaviour may have a significant negative impact for the security of the EU and the

wellbeing of its citizens.

This Service aims to support MS and to reinforce the implementation of Council Directive 2008/114/EC by

monitoring a particular critical infrastructure, detecting abnormalities and identifying behavioural patterns

in the surroundings of the critical infrastructure in order to anticipate any sort of threats.

Reducing critical infrastructures vulnerabilities and increasing their resilience is one of the major objectives

of the EU and this Service main purpose.

This service shall support the risk analysis and management of a particular Critical Infrastructure by:

i. Detecting, recognising and identifying threats: designation of an object/ entity whose

characteristics, behaviour or origin indicate that it could be a threat to the critical infrastructure.

ii. Monitoring threats: geolocating and tracking the designated threat detected in (i) during a specified

timeframe.

iii. Evaluating threats, the risk of incident occurrence and the possible impact.

Different stand-off distance thresholds or buffer zones (e.g. 50NM, 25NM, 5NM) are set around a critical

infrastructure and/or around the EU coastline.

The main goal of this Service is to help to identify, at the operational level, what the threat (or potential

threat) can do, as well as when, where and the strength. It might include identifying the threat’s

operational decisive points, mobilisation potential, operational organisation, dispositions, military and non-

military capabilities as well as possible command and control structure.

This Service should also include the evaluation of developing insurgencies. The Service should provide (i)

assessment of the threat operations capabilities, (ii) support to the identification all possible threat

operational courses of action, (iii) probability associated to each course of action, (iv) list of factors that

may influence the threat to adopt each course of action and (v) susceptibility analysis of the threat vital

elements operational power to the potential actions of the joint force.

22 https://spacedata.copernicus.eu 23 http://copernicus.eu 24 https://earth.esa.int/web/guest/data-access/how-to-access-eo-data/gmes



http://copernicus.eu/

https://earth.esa.int/web/guest/data-access/how-to-access-eo-data/gmes















This Service should, amongst other results, include the creation of analysis-derived products for the

operational area, such as templates and reports to law enforcement organisations to determine, track,

monitor and target operational critical target sets and their associated infrastructure. Two working modes

have been identified for this service:

Maritime monitoring (mandatory).

Inland Monitoring (optional).

Maritime Monitoring

The Service should provide situational awareness through monitoring the combination of Satellite derived

products and OSINF.

Maritime Monitoring should be based on:

o Target detection and feature extraction from EO products.

o Abnormal activity detection (i.e.: spoofing, hijacking, and availability disruption) based on

historical and live AIS data processing enabling the retrieval of suspected vessel tracking

data (AIS data to be provided by the solution).

o Other proposed data sources/sensors (to be fully provided by the contractor)

Upon the abnormal behaviour detection in the inner buffer areas, the Service should acquire

archived satellite imagery (if available) or new Satellite imagery in the forecasted position. The

corresponding chip image with the vessel location and characteristics should be delivered.

This Service should provide new technologies capable to deal with the numerous challenges in maritime

monitoring such as improving small vessels detectability in certain wind and sea state by enhancing the

target-clutter ratio or characterising a target movement using sequential sub-look images such as adrift

vessel position estimation, or long distance journey.

Inland monitoring – Optional

The Service should provide land situational awareness through monitoring and exploiting the combination

of satellite imagery derived products and OSINF.

The Service should characterize the surrounding environment with High Resolution Vector Data (HRVD) and

deliver a critical infrastructure vulnerability assessment. Characterizing the surrounding environment

should be based on the vectorisation of pre-defined features of interest derived from optical satellite.

OSINF exploitation should focus on bringing innovative solutions to be used in conjunction with Satellite

Imagery, including information extraction from unstructured linguistic data, text analytics, speech and

audio recognition and analytics, open/free map databases, data mining and symbolically based high-level

information fusion. The following possible sources should be taken into account:

a. Social Media Networks (e.g. Twitter, Facebook, Instagram etc.) (SHOULD)

b. Video Streaming Sites (e.g. Youtube, Vimeo, etc) (SHOULD)

c. News aggregators (SHOULD)

d. Media News (e.g. radio, TV, press) (SHOULD)

e. Dark Web Monitoring (SHOULD)




f. Open, free or crowdsourced map databases (SHOULD)

g. Others (to be proposed)

Based on the various sources, the proposed system should validate the acquired information and issue

alerts relevant to the vulnerability of critical infrastructure locations. Alerts, supervised by the operator, can

further trigger the acquisition of new satellite imagery over risk-prone areas. Synergies with the “Enhanced

Change Detection” Service should be exploited.

SEV 2. The UR GUI shall provide the option to define:

A Critical Infrastructure

Set-up three buffers (D1, D2, D3 ) around the critical Infrastructure (e.g.: 50NM, 25 NM, 5NM).

Being D1 the outer ring and D3 the critical closer distance to the Critical Infrastructure.

Monitoring period

Rules (possible abnormal behaviour patterns)

Definition of target areas and specific considerations for each one (i.e. revisits during monitoring

period, meetings, stops, crossing, etc.).

Definition of specific AOIs within D1, D2, D3 where specific behaviour could trigger an alert or event




Figure 7: Example of the thresholding approach with three proposed distance rings around a critical infrastructure. Contains modified Copernicus Sentinel-2 data (2017)

2.4.1.1 INDICATIVE DATA SOURCES

The following list includes a set of possible data sources to be used by this Service. Please note this list is

not exhaustive and only includes the most common information sources. The tenderer shall describe, in its

proposal, an exhaustive list of information sources that will be used by the Service.

Copernicus Sentinel and Contributing Missions Data/Imagery (mandatory)

Copernicus Services from the Marine Service Portfolio can be used as inputs for the derived service,

in particular: surface winds, forecast products (for the Mediterranean or other AoIs), sea surface

height, etc.

Existing Copernicus Security Services (Border Surveillance, Maritime Surveillance, Support to EU

External Action)25

AIS data (to be fully provided by the Contractor)

Weather data (now-casts and history) (to be fully provided by the Contractor.)

Others: to be fully provided by the Contractor.

2.4.1.2 POTENTIAL OUTPUT INFORMATION LAYERS

The following list includes a set of possible output information layers for this Service. Please note this list is

not exhaustive and only includes the most common information layers. The tenderer shall describe, in its

proposal, an exhaustive list of the output information layers.

Alerts / Events

25 Access to these services should be triggered by the End-User using the existing procedures and mechanisms.




AIS data

Transportation Network (Main Roads, Harbours, Airfields)

Points of Interest

Points of Interest operational status (Airports, Harbours, Industrial Facilities, Specific buildings, etc.)

Critical Infrastructure Operational elements

Changes in the infrastructure or in the operational status

Enclosure and security measures

Topography / Bathymetry

Land use / land cover

Populated Areas

Weather information

Weather forecast impact

2.4.1.3 POTENTIAL USERS

National Maritime Safety Authorities from the Member States

European Critical Infrastructure Protection contact points (ECIP contact points)

Nuclear, energy, transport, ICT and sectorial authorities

EU Agencies (e.g. Frontex, SatCen)

2.4.1.4 MARITIME MONITORING MODE (MANDATORY)

Figure 8 shows the operational nodes being End-User, Service Provider and Copernicus DWH, which are

defined as logical collections of operational activities. Figure 8 also explains the operational process for the

Maritime Monitoring mode. Finally, the highlighted elements are the nodes, the links between them and

the characteristics of the information exchanged.

The solution described hereafter is based on Satellite data processing complemented with on AIS data

processing notwithstanding, the tenderers considering these operation modes are free to propose any

other possible solution to this challenge.




Figure 8: Operational View (OV) 3, operational node connectivity overview. Maritime Monitoring mode

During the technical offer elaboration, the tenderers must provide a proposed Service Operational View

and Concept of Operations.

SEV 3. The contractor shall provide the capability to monitor and analyse AIS tracks all around the world

(to be acquired by the contractor)

SEV 4. The Contractor should have, at least, a historical record of more than 1 year of AIS data.

AIS

End User Service Provider

Abnormal Activity Detection

Alert < 50 NM (D1)

Satellite Acquisition

Monitoring Alert

Image Processing

Validate Alert

< 50 NM (D1)

Alert < 25 NM (D2) < 25 NM (D2)

Copernicus DWH / DIAS / Copernicus Services Data HUB

Plan Acquisition

Acquisition Request

Imagery Acquisition

Download Image(s)

Critical Infrastructure

AoI /Buffer Zone

Monitoring Period

Rules (if any)

< 5 NM (D3)

Satellite Acquisition

Image Processing

Plan Acquisition

Acquisition Request

Imagery Acquisition

Download Image(s)

Monitoring Alert

Weather forecast

Other

Quicklook

Pattern detectedRisk Classification Forecast

Risk ClassificationForecastGeolocation

Pattern detectedRisk Classification Forecast

Patterndetected

Risk Classification Forecast

Quicklook Risk ClassificationForecastGeolocation




SEV 5. Upon the UR reception, the contractor shall provide the capability to monitor and to analyse AIS

tracks (to be acquired by the contractor) all around the world. Moreover, it shall provide alerts

whenever an unusual or irregular activity is detected inside the thresholds defined by the

EndUsers.

SEV 6. The tenderer shall describe the algorithms that will be used to analyse the data (Big data

processing methods, Neural Networks based, etc..).

SEV 7. The algorithms should support incremental learning to be able to learn from the End-User

feedback on the alerts (i.e. feedback ingestion loops are strongly encouraged).

SEV 8. The Service shall provide a set of predefined rules that will be included in the solution to detect

abnormal vessel behaviour based on AIS data. The tenderer should provide a brief example in the

proposal.

SEV 9. The Service shall raise an alert when an abnormal activity is detected inside of the thresholds

defined by the end End-User.

SEV 10. If deemed necessary, the Service should use any other external source to detect abnormal vessel

behaviours (e.g. OSINF).

Use_Case_1: Abnormal vessel behaviour detected between D1 and D2

Whenever an abnormal behaviour is detected between D1 and D2, the Service should raise an alert with

the following characteristics:

SEV 11. Abnormal vessel behaviour is detected through Sentinel’s Satellite Imagery Analysis and or AIS

abnormal behaviour (i.e.: spoofing, hijacking, availability disruption) is detected.

SEV 12. The solution must display the alert with the vessel/s involved in the alert, historical positioning

records that led to the alert and/or the description and details of the event (e.g. AIS switched off

and on), Vessel Navigational Status changes, AIS data updates.

SEV 13. AIS data shall include Vessel Photos and vessel technical data:

Vessel Identifiers (MMSI, IMO, Name, Callsign)

Ownership (Manager, Owner)

Ship/Vessel Type

Dimensions (Length, Breadth)

Capacity (DWT, Liquid Oil, Goss Tonnage, Net Tonnage)

Built (Year, Place, Builder)

Destination / ETA

Current Course (Degrees), Speed (Knots), Latitude/Longitude

Last Port Calls

Ship movement history (up to 30 days)

Last Report (Time).

SEV 14. The alert shall be also provided in JSON, XML, KML and optionally IVEF.

SEV 15. Optionally, if requested by the user the alert should be sent by email.

SEV 16. Every alert shall have an associated likelihood and risk classification indicator.

SEV 17. The Service shall give the option of erasing/deleting or confirming an alert to the End-User.




Use_Case_2: Abnormal vessel behaviour detected between D2 and D3

Whenever an abnormal behaviour is detected between D2 and D3 the service should raise an alert with the

following characteristics:

SEV 18. The Service shall raise an alert with the same requirements as in Use_Case_1.

SEV 19. The End-User shall validate the alert.

SEV 20. If the alert is confirmed by the End-User, the Service shall:

Try to find a VHR1 Optical archived image (Resolution ≤0.50m) or a VHR1 Spot SAR image

(Resolution <0.85m) in the location of interest at the time of the alert. If found, the

system should identify the vessel(s) and send a chip image (full resolution) of the vessel(s)

detected.

If no archived imagery is found, the system should forecast the vessel(s) location and plan

the corresponding VHR1 Optical Imagery (Resolution ≤0.50m) or VHR1 Spot SAR imagery

(Resolution <0.85m) rush acquisitions. Upon the reception of the image, the service shall

identify the vessel(s) and send a chip image (full resolution) of the vessel(s) detected

SEV 21. The EO image to be delivered and the chip image shall be provided with the following spectral

combination: Pansharpened 4 bands (R, G,B, NIR)

SEV 22. The GUI shall display:

The chip image with the vessel(s) location(s) (at the satellite image acquisition time) and

the current vessel(s) location(s)

Reliability (Likelihood) of the detection

Risk classification level indicator

Distance to the Critical Infrastructure

Scale

North Arrow

SEV 23. Upon request by the End-User, the GUI display can be saved as a Geospatial PDF in the Product

Catalogue.

SEV 24. All the images, chip images and associated products shall be available for downloading in an online

catalogue (to be provided by the contractor)

SEV 25. The Service shall propose a monitoring plan according to the vessel (s) bearing, course and speed.

The monitoring plan might involve more than one AoI.

SEV 26. The monitoring plan shall include:

Start of sensing product

Predicted reception date (of the final product)

Satellite

Look angle

Footprint of the monitoring plan

SEV 27. The monitoring plan must be updated according to the vessel route.

SEV 28. The End-User might approve completely the monitoring plan or some specific acquisitions from

the monitoring plan.

SEV 29. The Contractor shall deal with the Copernicus DWH Service to update the monitoring plans

accordingly.

SEV 30. The Contractor shall deal with the Copernicus DWH possible cancellations to re-task the

acquisition to another possible CCME compliant with the requirements.




Use_Case_3: Abnormal vessel behaviour detected between inside D3 zone

Whenever an abnormal behaviour is detected between D3 and the Critical Infrastructure, the service

should raise an alert with the following characteristics:

SEV 31. The Service shall raise an alert with the same requirements as in Use_Case_1.

SEV 32. Automatically, the Service shall:

Try to find a VHR1 Optical archived image (Resolution ≤0.50m) or a VHR1 Spot SAR image

(Resolution <0.85m) in the location of interest. If found, the system should identify the

vessel(s) and send a chip image (full resolution) of the vessel(s) detected.


the corresponding VHR1 Optical Imagery (Resolution ≤0.50m) or VHR1 Spot SAR imagery

(Resolution <0.85m) rush acquisitions. Upon the reception of the image, the service shall

identify the vessel(s) and send a chip image (full resolution) of the vessel(s) detected


combination: Pansharpened 4 bands (R, G,B, NIR)

SEV 34. The GUI shall display:

The chip image with the vessel(s) location(s) (at the satellite image acquisition time) and

the current vessel(s) location(s)

Reliability (Likelihood) of the detection

Risk classification level indicator

Distance to the Critical Infrastructure

Scale

North Arrow

SEV 35. Upon request by the End-User, the GUI display can be saved as a Geospatial PDF in the Product

Catalogue.

SEV 36. All the images, chip images and associated products shall be available for downloading in an online

catalogue (to be provided by the contractor)

SEV 37. The Service shall deal with the Copernicus DWH possible cancellations to re-task the acquisition to

another possible CME compliant with the requirements.

2.4.1.5 LAND MONITORING MODE (OPTIONAL)

This surveillance mode aims to contribute to the critical infrastructure protection of those possible threats

approaching from land.

Figure 9 shows the operational nodes being End-User, Service Provider and Copernicus DWH, which are

defined as logical collections of operational activities.

Figure 9 also explains the operational process for the Maritime Monitoring mode. Finally, the highlighted

elements are the nodes, the links between them and the characteristics of the information exchanged.




Figure 9: OV 3 operational node connectivity overview. Land Monitoring mode

During the elaboration of the technical offer, the tenderers must provide a proposed Service Operational

View and Concept of Operations.

SEV 38. The Service should provide land situational awareness based on the buffer areas defined by the

End-User.

SEV 39. The Service should provide land situational awareness through monitoring and exploiting the

combination of Satellite derive products and OSINF.

2.4.1.5.1 EO SATELLITE DERIVED PRODUCTS

SEV 40. When a UR is received, the Service should try to exploit Sentinel data to identify

Possible venues of approach classified according to the risk

Trafficability and/or permeability assessment

Risk Assessment (colour-coded)

Any other product proposed by the Contractor of interest for the provision of the service and the


VHR/SAR Satellite

Acquisition

Report

Image processing

Plan Acquisition

Acquisition Request

Imagery Acquisition

Download Image(s)

AoI /Buffer Zone

Monitoring Period

Rules (if any)

Risk Update

VHR/SAR Satellite

Acquisition

Image Processing

Plan Acquisition

Acquisition Request

Imagery Acquisition

Download Image(s)

OSINF Monitoring

Alert

Validate Alert

Risk Update

Media Monitoring

Social Networks Monitoring

AIS

Weather forecast


Features Avenues of Approach TrafficabilityRisk Assessment




evaluation of the Critical Infrastructure vulnerability.

SEV 41. When a UR is received, if needed the service should acquire a VHR1 optical image (Resolution ≤

0.50m).

Upon the image reception, the Service should produce a High Resolution Vector Data (HRVD),

based on the vectorisation of pre-defined features of interest derived from optical satellite

imagery, including at least:

Lines of communications

Physical Barriers

Land Cover

Geography related features

Any other relevant features (to be determined by the Contractor)

SEV 42. All features shall be digitalized according to Multinational Geospatial Co-Production Program

(MGCP) TRD V4.0 extraction guidance.

SEV 43. The HRVD should be delivered through the Product Catalogue as a geodatabase (.gdb file)

compatible with the last version of ESRI GIS platform. The .gdb file is a container to hold the

feature datasets and associated tables related to each other.

SEV 44. The High Resolution Vector Data should be provided in both Universal Transverse Mercator (UTM)

using WGS84 for the Datum with the corresponding Zone and WGS84 Web Mercator (Auxiliary

Sphere) (EPSG: 3857).

SEV 45. The extraction criteria and scale considerations should be proposed by the Contractor within the

tender and during the Service specification.

SEV 46. With the extracted features the service should create an initial risk assessment through the

provision of the following products:

Possible venues of approach classified according to the risk

Trafficability and/or permeability assessment

Risk Assessment (colour-coded)

Any other product proposed by the Contractor of interest for the provision of the service

and the evaluation of the Critical Infrastructure vulnerability.

SEV 47. The Service should display these products through the GUI and make them available through the

Product Catalogue as GeoPDFs and vectorised data (Shape compliant).

2.4.1.5.2 OSINF AND EO MONITORING

SEV 48. The Service should provide land situational awareness service though monitoring and exploiting

the combination of satellite imagery derived products and OSINF, including the following sources:

Social Media Networks (e.g. Twitter, Facebook, Instagram etc.) (SHOULD)

Video Streaming Sites (e.g. Youtube, Vimeo, etc.) (SHOULD)

News aggregators (SHOULD)

Media News (Radio, TV, Press) (SHOULD)

Dark Web Monitoring (SHOULD)

Weather Forecast Open Sources (SHOULD)

Vector data Open Sources (e.g. OpenStreetmap, Wikimapia, etc) (SHOULD)

SEV 49. The Service should layover the results and alerts from the OSINF monitoring in the EO initial

derived products.




SEV 50. The GUI should provide a comprehensive dashboard comprising the OSINF possible alerts.

SEV 51. The GUI should be able to change the Risk assessment layer according to the OSINF alerts.

SEV 52. Whenever a new alert with high reliability and impact is detected, the Service should raise

Warning to the End-User.

SEV 53. If the Warning alert is confirmed by the End-User the Service shall:

Try to find a VHR1 Optical archived image (Resolution ≤0.50m) in the location of interest.

If found, the system should identify the vessel(s) and send a chip image (full resolution) of

the vessel(s) detected.


the corresponding VHR1 Optical Imagery (Resolution ≤0.50m) rush acquisition. Upon the

reception of the image, the service shall identify the vessel(s) and send a chip image (full

resolution) of the vessel(s) detected.


combination: Pansharpened 4 bands (R, G, B, NIR).

2.4.2 SERVICE 2: ENHANCED CHANGE DETECTION

This Service aims to detect evidence supporting the hypothesis that certain irregular activity is taking place

in a specific AoI (e.g.: beaches/coasts are (or were) used for embarking / disembarking migrants, pre-

frontier area, etc.). This Service aims to provide new technologies capable to deal with the numerous

challenges yet to be overcome including:

The technical capacities to handle large volume of satellite data, including new technologies based

on crowdsourcing for satellite imagery analysis and/or new methods for automatic change

detection.

High performance computing for data processing and final product mosaicking

More robust classifiers to minimize human intervention through the use and development of

automatic object detection and recognition. Of particular interest are methods which not only

detect changes but are also capable to infer the nature of change (change identification).

Hyperspectral signature library exploitation for land monitoring, land use classification, object

detection or object recognition

Deep learning approaches for feature recognition.

Behavioural pattern characterization throughout data exploration (Exploratory Spatial Analysis) and

spatial data analysis (pattern analysis, geostatistics, spatial regression, etc.)

Object analysis based on EO and SAR multi-geometry acquisition, interferometry and polarimetry

techniques.

Two main operation modes are proposed in this Service:

Reconnaissance (change detection)

Statistical characterization mode

The reconnaissance mode consists of a preliminary step devoted to accurately characterise the AoI

cartography. The cartographic characterisation is then used to locate pre-defined, single or group,




fixed/deployed facilities or objects/features in a big AoI at a pre-defined time. Initially, this mode aims to

identify anomalies inside pair/series of images collected with the same geometric parameters. Once

detected, the mode proceeds with the key features/objects characterisation (e.g. equipment, temporary

settlement, suspicious activities) over areas pre-defined inside the initial large AoI.

Within this mode, the second phase takes place, in which possible threats are under investigation via the

detection and, if possible, characterisation of unexpected activity/changes occurring in the AoI.

This statistical characterisation mode is intended to assure periodic monitoring over an AoI and to quantify

events, in order to keep control of a wide variety of possible pre-defined features/objects in a pre-defined

area at pre-defined time of possible indicators provided by the End-User (e.g. number of skiffs, number of

vehicles, new tracks, etc.).

There might be scenarios in which no characterisation analysis is needed (e.g. no hotspot is detected) or

where multiple parallel characterisation analysis is carried out and needs to be monitored and

characterised (e.g. multiple hotspots are detected).

Therefore, the designed workflow shall be based on the analysis of multiple images oriented to:

Preliminary AoI scanning aimed at the identification of focal locations or using open-source

information to keep track of stable features of interest (e.g. beaches, harbours etc.)

Suspicious activity detection

Selection and characterisation of the features/objects of interest

The main output is based on the AoI characterisation to provide detailed thematic and technical (e.g.

surface elevation and, where applicable, target heights and shape) information to the End-User. This mode

objective is represented by the continuous survey of land-use / land-cover changes and ground activities

occurring over key sites and the related surrounding zones of interest.

Three working modes are envisaged:

Mode 1 – Regional Change Detection (Sentinel-based Change Detection)

Mode 2 -- Targeted Change Detection

Mode 3 – Action Mode.

Where, normally:

The Targeted Change Detection Mode might be triggered by the Regional Change Detection Mode

The Action Mode will be triggered by the Regional Change Mode or Targeted Change Detection

Mode.

In order to cover the gaps that the different law enforcement bodies and their respective operational nodes

may have, the following requirements are derived for the Enhanced Change Detection Service:

SEV 55. The UR GUI shall provide the option to define:

An AoI (by drawing on the interface or by uploading a KML/KMZ)

A set of indicators to be monitored




A monitoring period

A set of rules

SEV 56. Upon the UR reception (including the AoI and characteristics of the objects/features to be

monitored), the Service shall propose to the End-User:

To automatically download, pre-process Sentinel images (corregistration,

orthorectification and projection in the corresponding UTM area) and start the analysis

process. (Mode 1).

The validation of the HR and VHR images Acquisition Planning over the AoI, to proceed

with the imagery acquisition, downloading and data preparation (corregistration,

orthorectification and projection in the corresponding UTM area) to start the analysis

process. (Mode 2).

SEV 57. The Contractor shall provide innovative Change Detection algorithms, solutions, workflows or

automatic image processing with respect to a set of monitored indicators (e.g. big infrastructure

changes, road/tracks changes, etc.).

SEV 58. The service should provide situational awareness through monitoring and exploiting the

combination of Satellite derived products and OSINF, including the following sources:

Social Media Networks (e.g. Twitter, Facebook, Instagram, etc.) (SHOULD)

Video Streaming Sites (e.g. Youtube, Vimeo, etc.) (SHOULD)

News aggregators (SHOULD)

Media News (Radio, TV, Press) (SHOULD)

Dark Web Monitoring (SHOULD)

Weather Forecast Open Sources (SHOULD)

Vector data Open Sources (OpenStreetmap, Wikimapia, etc.) (SHOULD)

SEV 59. The proposed algorithms can be based on electro-optical, SAR and/or multispectral image

processing.

SEV 60. The proposed algorithms should include techniques to classify the changes in the AoI.

SEV 61. Upon the detection of a change, the Service shall raise a visual and an electronic alert.

SEV 62. The alert shall be provided in JSON, XML, KML and optionally IVEF.

SEV 63. Optionally, if requested by the End-User, the alert should be sent by email.

SEV 64. Every alert shall have an associated likelihood and a risk classification indicator.

SEV 65. The End-User shall validate the alert to proceed with a deeper analysis.

SEV 66. If the alert is confirmed by the End-User, the Service shall:

Try to find a VHR1 Optical archived image (Resolution ≤ 0.50 m) or a VHR1 Spot SAR image

(Resolution < 0.85m) in the AoI.

If no archived imagery is found, the system should plan the corresponding acquisition of a

VHR1 Optical Image (Resolution ≤ 0.50cm) or a VHR1 Spot SAR image (Resolution <

0.85m) rush acquisitions.

SEV 67. The Service shall digitalise, quantify and classify the corresponding changes.

SEV 68. The VHR1 EO images shall be provided with the following spectral combination: Pansharpened 4

bands (R, G,B, NIR)

SEV 69. The VHR1 SAR images shall be provided in single polarisation HH. Moreover, the Single Look

complex product is required in HDF5 format.

SEV 70. All the images to be delivered shall be compliant with the following requirements:




Georeferenced image in Earth geometry, corrected from off-nadir acquisition and terrain

effects

The acquisition angle shall be as low as possible

The provided image shall be corregistered, orthorectified and projected in the

corresponding UTM zone (other projections on request)

The product encoding shall be 12 bits for JPG2000 format, 16bits for GEOTIFF format

Imagery shall be provided in the following formats:

o JPEG 2000, optimised compression (3.5 bits/pixel)

o JPEG 2000, regular compression (8 bits/pixel)

o GeoTIFF (uncompressed)

All the images (and chip images) acquired and delivered through the Product Catalogue

shall include, in the metadata and filename, the acquisition date and time and the sensor

used.

SEV 71. All the images acquired and delivered through the Product Catalogue shall include, in the

metadata and filename, the acquisition date, time and sensor used.

SEV 72. All the changed features shall be digitalised according to Multinational Geospatial Co-production

Program (MGCP) TRD V4.0 extraction guidance.

SEV 73. The HRVD should be delivered through the Product Catalogue as a geodatabase (.gdb file) format,

a proprietary database structure used in ESRI GIS platform. The .gdb file is a container to hold the

feature datasets and associated tables related to each other. The Geodatabase should be

compliant with version 10.3.1.

SEV 74. The HRVD should be provided in both Universal Transverse Mercator (UTM) using WGS84 for the

Datum with the corresponding Zone and WGS84 Web Mercator (Auxiliary Sphere) (EPSG: 3857)

SEV 75. The extraction criteria and scale considerations should be proposed by the Contractor in the

tender and during the Service specification.

SEV 76. The final product (HRVD and report in GeoPDF) shall be provided no later than 3 hours after the

image FTP delivery by the CCME or Copernicus DWH CDS.

2.4.2.1 MODE 1 - REGIONAL CHANGE DETECTION (SENTINEL-BASED CHANGE DETECTION)

The current open satellite data wide availability (e.g. Sentinel-1 and Sentinel-2 data) allows users to have

long time series of free data, which capture and store, all the changes taking place in the territory. This

reconnaissance mode aims to detect possible changes in routes, obstacles or terrain and to recognise

possible illegal activities or threats within a zone defined by boundaries. This reconnaissance mode is

appropriate when knowledge of the threats is vague, knowledge of the terrain is limited or there have been

alterations in the terrain (e.g. earthquake, flooded area, etc.).

This mode aims to monitor changes over very large AoIs (e.g. 500 km x 60km). Figure 10 shows this mode

operational view. Synergies with the Land Monitoring Service, OSINF, Copernicus Services (Land,

Atmosphere Climate) and EO Monitoring Service, should also be considered and applied. Apart from

detecting, the system should identify the nature of change (e.g. new construction, change attributed to the

phenology of vegetation, etc.).






Figure 10: OV 3 operational node connectivity overview. Regional Change Detection - Enhanced Change Detection

2.4.2.2 MODE 2 – TARGETED CHANGE DETECTION

This second mode is devoted to accurately characterise the AoI cartography. The cartographic

characterisation is then used to locate pre-defined, single or group, fixed/deployed facilities or

objects/features in a big AoI at a pre-defined time. Initially, this mode aims to identify anomalies inside

pair/series of images collected with the same geometric parameters. Once detected, the mode proceeds

with the key features/objects characterisation (e.g. equipment, temporary settlement, suspicious activities)

over areas pre-defined inside the initial large AoI.

Figure 11 explains the operational process for the Targeted Change Detection Mode, focusing on the

operational nodes that are logical collections of operational activities. The main elements are the nodes,

the links between them, and the characteristics of the information exchanged.




Report

SentinelAcquistion

Imagery Processing

Validate Alert

Plan Acquisition

Acquisition Request

Imagery Acquisition

Download Image(s)

AoI /Buffer Zone

Monitoring Period

Change Detection

VHR/SAR Satellite

Acquisition

Extract features

Plan Acquisition

Acquisition Request

Imagery Acquisition

Download Image(s)

Open Source

Colletion

Alert


Features Risk ClassificationGeolocation




Figure 11: OV 3 operational node connectivity overview Targeted Change Detection Mode

2.4.2.3 MODE 3 – ACTION MODE

This Action Mode is intended to assure periodic monitoring over an AoI and quantify events, in order to

keep control of a wide variety of possible pre-defined features/objects in a pre-defined area for at pre-

defined time of possible indicators provided by the End-User (e.g. number of skiffs, number of vehicles,

new tracks, etc.).

Figure 12 explains the operational process for the Action Mode, focusing on the operational nodes that are

logical collections of operational activities. The main elements are the nodes, the links between them, and

the characteristics of the information exchanged.




Report

VHR/SAR Satellite

Acquisition

Imagery Processing

Plan Acquisition

Acquisition Request

Imagery Acquisition

Download Image(s)

AoI /Buffer Zone

Monitoring Period

Change Detection

Open Source

Colletion


New FeaturesBaseline Features




Figure 12: OV 3 operational node connectivity overview. Action Mode - Enhanced Change Detection

2.4.2.4 INDICATIVE DATA SOURCES

The following list includes a set of possible data sources to be used by this Service. Please note this list is

not exhaustive and only includes the most common information sources. The tenderer shall describe, in its

proposal, an exhaustive list of information sources that will be used by the Service.

Copernicus Sentinel and Contributing Mission Data/Imagery (mandatory)

Copernicus Services from the Marine Service Portfolio can be used as inputs for the derived service,

in particular: surface winds, forecast products (for the Mediterranean or other AoIs), sea surface

height, etc.

Weather data (now-casts and history) (to be fully provided by the Contractor)

Open Source Information

Others: to be fully provided by the Contractor.

2.4.2.5 POTENTIAL OUTPUT INFORMATION LAYERS

The following list includes a set of possible output information layers for this service. Please note, this list is

not exhaustive and only includes the most common information layers. The tenderer shall describe, in its

proposal, an exhaustive list of the output information layers.

Alerts / events


Report

VHR/SAR Satellite

Acquisition

Imagery Processing

Plan Acquisition

Acquisition Request

Imagery Acquisition

Download Image(s)

AoI /Buffer Zone

Monitoring Period

Quantifiy Activity

Target of Interest

Open Source Colletion


Risk ClassificationDetections Heatmat

Pattern Statistics




Detailed transportation network (roads, trails, cart tracks, culverts, tunnels, harbours, airfields)

BCPs (Checkpoints, enclosure, capacity, current activity)

Points of Interest

Points of Interest operational status (airports, harbours, industrial facilities, specific buildings, etc.)

Gathering areas

Possible camp dwellings

Changes in the camps

Human geography layers

Administrative boundaries

Ancillary information related to the detected changes

Topography / bathymetry

Land use / land cover

Populated areas

Weather information

Weather forecast impact

2.5 NON-FUNCTIONAL REQUIREMENTS

2.5.1 SW & HW

The tenderer should include, in the detailed technical proposal, a preliminary description of the Software

and Hardware architecture proposed for each Service. The description should detail each Service expected

performances and the proposed workflows from data collection planning, data acquisition, data

preparation (including data pre-processing and value-added processing algorithms), product interpretation

and report production and dissemination.

SCA 1. The Solution’s architecture should integrate flexible, reliable and scalable systems.

SCA 2. The Service shall be fully scalable (high cohesion - loosely coupling modular architecture).

SCA 3. The implemented SW design (mainly interfaces) should be modular (high cohesion and loose

coupling), preferably based on open systems to enable adding new features, making modifications

and / or evolving the SW.

SCA 4. The SW design should be as modular as possible; interfaces between modules will be defined to

minimise the degree of coupling between them.

SCA 5. System SW & HW design should provide expandability and maintenance. Thus, it should allow the

modification or extension of any of its parts without affecting the operation of the others.

SCA 6. The Service components should be, if possible, reusable, meaning the feature could be used in

different scenarios with null to minimum changes.

2.5.2 AVAILABILITY AND RELIABILITY

The Services to be developed under the SATSURVEILLANCE Thematic Area shall support European Union

policies by providing information in response to Europe’s security challenges and therefore support law

enforcement authorities or End-Users, which might require using the Service on a 24x7 basis. Due to the

Service characteristics, the Tenderer shall describe the availability, reliability and maintainability measures

for retrieving planned data sets and products by detailing the expected service levels performances.




LOG 1. Service design shall provide high availability (24 x7), providing most of its operational capabilities

even in case of failure of one or more of its subsystems.

LOG 2. The Services shall be able to continue operating despite receiving and processing invalid or wrong

data. The Solution must inform the End-User with an acoustic and visual alert about the operation

in “Degraded Mode”.

LOG 3. The Services will provide high computing availability, having a continuous, uninterrupted, fault

tolerant Solution.

LOG 4. The Availability shall be ≥ 99% where: 𝐴𝑔𝑟𝑒𝑒𝑑 𝑆𝑒𝑟𝑣𝑖𝑐𝑒 𝑇𝑖𝑚𝑒 (𝐴𝑆𝑇)−𝑑𝑜𝑤𝑛𝑡𝑖𝑚𝑒

Availability (%) = 𝑥 100 𝐴𝑆𝑇

LOG 5. The Services support schedule will be developed to allow a continuous operation of at least two

months for each individual Service. The Contractor is responsible for ensuring sufficient

maintenance time before deployments.

LOG 6. The solution shall be fully interoperable and it shall manage and coordinate the interaction among

the different Services.

LOG 7. The solution shall be fully scalable so that it can easily adapt to new integration needs or

performance changes, reliability and data volume requirements.

LOG 8. The solution shall assure the proper scalability for a period of 5 years.

2.5.3 QUALITY CONTROL

During the technical offer elaboration, the tenderers must provide a document (Quality Control Plan)

detailing how quality control will be internally handled during the production phase/operations.

The Contractor must abide to quality control measures. The Contractor must perform data quality control

procedures based on ISO 19157, which has been adapted for the INSPIRE implementation (please refer to

“JRC Technical Reports on Data Quality in INSPIRE: Balancing Legal Obligations with Technical Aspects”26

which presents the most commonly used data quality elements). Moreover, in order to ensure high quality

standards, the Contractor shall include additional data quality measures or even it shall commit to reach

higher data quality thresholds.

2.5.4 MAINTENANCE

LOG 9. The System shall provide audit mechanisms, registers and metrics to monitor it.

LOG 10. The maintainability described as a measure of how quickly and effectively a Service, component

or CI (Configuration Item) can be restored to normal working conditions after a failure shall be: Total downtime in hours

Maintainability (MTRS in hours )= ≤ 2 hours Number of service breaks

26 http://inspire.ec.europa.eu/documents/INSPIRE_/JRC83209_Online_Data_quality_in_INSPIRE.pdf






2.5.5 VERIFICATION

The main objective of the verification phase (PCP Phase 3) is to confirm that the Services have been built in

the right configuration and with the expected technical performance level. The verification shall measure a

set of quantitative indicators (MoPs) following the procedures defined by the Contractor and approved by

the contracting authority in the Contract PCP Phase 1.

These MoPs will be identified by the Contractor according to each Service technical features and they will

provide a measure for each Service technical performance and for the SATSURVEILLANCE Service as a

whole.

Therefore, the technical specification of each Solution components and interfaces shall be provided by the

Contractor and it shall have associated one or more MoPs to verify if the Service has been built correctly.

VAL 1. The Contractor shall deliver an automated test environment, including tools and procedures for

testing the system.

VAL 2. All tests shall be automated.

VAL 3. The system shall provide three environments:

Test environment: where all the integration and unitary tests will be executed. (FQT)

Pre-Production environment: where all the performance and load tests will be executed. (FAT)

Production environment: where the fully operational version will run (for each End-User)

(OSAT). In this phase, requests will be launched to certify that the System receives the

products properly, without additional costs for the Contracting Authority.

VAL 4. The Contractor shall deliver the test dataset, test data generators, test tools and plans required

for the execution of the system tests.

VAL 5. The automated test environment shall provide metrics for the test results, test coverage and

coverage of functional and systemic requirements.

VAL 6. The automated test environment shall allow testing future developments.

VAL 7. The Tenderer shall define a validation plan allowing the Contracting Authority to validate the

implemented System and data accuracy and quality. The proposal shall detail the type of

validation test to be performed as well as the metrics used to assess the output results accuracy

and quality.

2.5.6 TRAINING

The Contractor shall train End-Users on the Solution exploitation. The training includes the generation of

training material and execution of the training sessions, without additional costs for the Contracting

Authority. Thus, a course of a minimum length of 48h for at least 6 people (with End-User role) shall be

provided. Training courses will take place in PCP phase 3 of the project.




Additional courses provided by the Contractor will be valued positively during the proposals evaluation. The

Contractor shall cover all costs derived from the End-Users journey (if needed) to attend the courses and/or

the web platform that will host the training sessions.

2.6 SPACE DATA COMPONENT

The European Space Agency (ESA) has been entrusted by the European Commission with the responsibility

of coordinating satellite data access, including the Copernicus Contributing Missions (CCMs). ESA is

responsible for the management and implementation of the Copernicus Space Component Data Access

system27.

2.6.1 SATELLITE IMAGERY PROVISION AND THE CSCDA MECHANISM

The Service provision will rely on Earth Observation (EO) imagery provision via the Copernicus Space

Component Data Access system (CSCDA), DIAS including VHR optical data and SAR imagery and the

Copernicus Services Data Hub for the provision of Sentinel Data

MARINE-EO is supported with a dedicated DWH data quota to be used for Activations. The characteristics

of the imagery available for the Copernicus Services are defined in the Copernicus Space Component Data

Access Portfolio (DAP): Data Warehouse 2014 – 2020. It is the responsibility of the Contractor to review the

latest DAP version available. The Contractor shall be aware of the EO data ordering process as well as the

parameters and conditions applicable to the Copernicus Contributing Missions, such as the delivery

timeliness. Information about the Sentinel dedicated missions is available at the Sentinel website.

Satellite data will be made available to the Contractor free of charge at the second and third phases of the

PCP under the CSCDA mechanism, procuring licensing for space data. After signing the Framework

Contract, the Contractor will be asked to sign the ESA – User license for the use of Copernicus Contributing

Missions data - Data Warehouse phase 2 (2014-2020)28. This license acceptance is necessary if data other

than Sentinel and ESA data are to be downloaded. The Contractor will accept the licensing terms and

conditions applicable to the use of Copernicus Contributing Missions. It has to be highlighted that access to

the DWH mechanism will be provided through Marine-EO and all data belong to the project.

During the PCP phase 2, all the necessary technical and administrative arrangements will be established for

the appropriate use of the satellite imagery during the execution of the Framework Contract.

The use of imagery from non-satellite but airborne sensors such as Unmanned Aerial Vehicle (UAV) and

aircrafts is not foreseen in the Service.

The Contracting Authority may provide other imagery sources, if the licensing conditions are equivalent or

better than those of the CSCDA mechanism and such alternative images: (i) they are free of charge and do

not involve any additional cost; (ii) they do not create any additional administrative burden and (iii) they

are properly credited in the Results. Additionally, open and free satellite imagery, such as Landsat, Modis

and any other sensor, could be used.

27

https://spacedata.copernicus.eu 28

https://spacedata.copernicus.eu/documents/12833/14545/DAP_Release_v2.2 (Contractor must use the latest version available at the Copernicus website)









2.6.2 ACCESS TO SATELLITE DATA

SAT 1. The Contractor will be responsible for ordering the imagery to ESA via the CSCDA mechanism and

it will be the unique interface with ESA for the Service provision.

SAT 2. All the Activations must be acknowledged and approved by the End-User.

SAT 3. The imagery identification, selection and ordering will be performed by the Contractor. These

actions might require 24x7 service to deal with possible changes in the satellite imagery

acquisition planning, cancellations and re-tasking.

SAT 4. For each activation, the Contractor must inform the End-User of the available quota and the

expected quota consumption.

SAT 5. The Contractor shall download the imagery, perform a Quality Control (QC) and report the QC

results to the End-User. Additionally, found incidences shall be reported so that MARINE-EO can

take the appropriate actions, if necessary.

SAT 6. The awarded Tenderer must ensure the capacity for EO imagery fast download, storage and

processing

2.6.3 QUOTA AVAILABLE FOR PROTOTYPING, TESTING AND OPERATIONAL DEMONSTRATION

The proposed MARINE-EO implementation roadmap consists on consecutive implementation phases

including the set of activities necessary to achieve the Project goals and to mitigate possible future risks

including the DWH quota management.

The exact available quota to test SATSURVEILLANCE/SATOCEAN Services shall be defined during the

implementation of PCP Phase, since there are several “Order Options” that need to be specified and agreed

(between End-Users and Contractors) including satellite tasking, data delivery timeliness, processing

options, cloud coverage classes.

QUT 1. Potential costs in Satellite image acquisition arising for unforeseen situations (e.g. unforeseen

testing) shall be assumed by the Contractor.

QUT 2. If, for whatever reasons, the Contractor needs more images than the one covered by the DWH

quota, the Contractor shall buy the images directly from the image provider (not through DWH)

and the costs shall be assumed by the Contractor.

QUT 3. All acquisition requests through the DWH shall be previously validated by MARINE-EO Consortium

End-Users. The End-User must be informed of:

Estimated quota consumption

Quota Available

Purpose

AoI

Dataset Used.




2.7 SOLUTION READINESS ASSESSMENT

A continuous readiness assessment for each delivered Service will be carried out. The objective is to know

the maturity of the services that will be provided for real operations as well as to evaluate and monitor the

progress of the development effort through the project lifecycle. Thereby, the contractor shall take into

account the following requirements:

SRL 1. PCP projects cover a specific part of the innovation cycle. Thus, the Solution’s TRL at the beginning

of the contract should be preferably 4 or 6. The contractor shall demonstrate the evolution of this

TRL level throughout the project lifecycle, aiming at the end of PCP phase 3 to reach TRL 7-8.

SRL 2. The Contractor shall commit to provide, if it required by MARINE-EO Consortium, the supporting

information to justify the Solution’s initially claimed TRL. TRLs definition, description and required

supporting information are detail in the "DoD TRA Deskbook (2009)".

SRL 3. The Contractor shall commit to actively cooperate with the MARINE-EO E Consortium in order to

execute, during the MARINE-EO project lifecycle, the following assessment points:

A post-CDR during the development phase after the Critical Design Review (Phase 2).

A post-V&V assessment after the execution of all Verification and Validation activities

performed during testing and operation phases (Phase 3).

SRL 4. The Contractor shall engage in all assessment activities, mainly:

To become acquainted with the System Readiness Level (SRL) model that will be applied

by the MARINE-EO Consortium. SRL is a concept that offers an approximate measure of

System/Solution maturity as an aggregated measure of technology and integration

readiness across elements and interfaces, based on Technology Readiness Levels (TRL) and

Integration Readiness Levels (IRLs).

To examine with the MARINE-EO Consortium the Solution's physical architecture, which

are candidate items for a SRL assessment, and to identify the Critical Technology Elements

(CTEs)29, classified as either primarily hardware or software. This will define the network

diagram granularity for the Solution, which will lay the basis for the readiness assessment

activities.

To define, if applicable, with the MARINE-EO Consortium operational strings over the

previous diagram. This concept refers to identify the components required to utilise a

single function of the system/Solution, just because complex systems often offer

numerous options for conducting operations.

To answer timely and thoroughly to the TRL/IRL questionnaires designed by the MARINE-

EO Consortium, as many times as required, in order to get TRL/IRL evaluations as well as

to compute an overall Solution status assessment via SRLs. The SRL scale is calculated by

using a normalised pair-wise comparisons matrix of TRLs and IRLs, revealing the actual

architecture of the Solution.

29

The definition of a CTE is: “A technology element is “critical” if the system being acquired depends on this technology element to meet operational requirements (within acceptable cost and schedule limits) and if the technology element or its application is either new or novel or in an area that poses major technological risk during detailed design or demonstration” (DoD TRA Deskbook, 2009).




To review and take part in the outcomes analysis and document status elaboration

(reports/roll-up charts) after each assessment point.

To provide supporting information, if required, to justify the reached TRLs and IRLs for

each Solution in each assessment point.




3 REFERENCE ARCHITECTURE REQUIREMENTS

3.1 Envisaged Architecture

This section provides the envisaged architecture for the deployment of MARINE-EO operational and

support services. As reference architecture, it is not foreseen, herein, to provide the full set of a typical

System Architecture specifying data models that will be applied, technologies and modules specifications,

corresponding APIs and envisaged connectors, but rather an overview of an architecture that will help the

tending preparation procedures. However, the reference architecture does provide relevant flows and

operations of each downstream service processes and basic components that shall be developed.

Overall the purpose of this content is to present an architecture approach that can be followed within the

context of MARINE-EO both for SATOCEAN & SATSURVEILLANCE downstream (operating and supporting)

services. As already stated, the architecture is based on “demands” (requirements) collected from the end-

users (Public Authorities) and as such the document describes a set of platform components, functionalities

and interfaces that shall be developed

3.2 Overview of the envisaged architecture

The overall system design comprises the practical basis for establishing and applying the set of downstream

services that will be served to MARINE-EO end-users. With reference to the previous requirements defined

above and according to information gathered (and agreed among Consortium partners) from the RFI and

PIN concerning of applying two different lots, two distinct web based platforms shall be developed having,

to the extent possible, a common HMI where the end user should be able to register and make use of the

Downstream services and/or also to request further EO-based services. Thus, the reference architecture

envisaged for what concerns the MARINE-EO downstream and support services is based on the consensus

to both meet current/forthcoming activities, trends and fulfil the requirements that have been identified.

High Level Architecture (Figure 13) shall be designed to function as a service to intermediate and end-users,

for i) providing capabilities and methods to transparently query, visualize and access products and sub-

products of heterogeneous datasets via MARINE-EO system and ii) having also the capability to allow

intermediate service providers to apply additional services, on end-users/market request. The solution shall

support the deployment of the services to be made either to MARINE-EO (Cloud) resources or locally on

user premises (The latter mostly concerns SATSURVEILLANCE services). MARINE-EO Platform shall ensure

the proper integration of third-party products that could be added after the end of the project. The concept

is not, as in other projects, to develop and test only some services serving current needs but to ensure that

other service providers shall be able to use the existing enablers, add new ones and create other marine

related services like applications, in a simple and intuitive technical approach. In this context, a schema for

a role-based access control system shall be integrated to the platform.

The platform will consist of the following components:

1. Three interfaces towards the users are provided: i) Web Portal, providing access to different applications, data and related documentation via a simple Web browser, ii) Web Services,




according to standardized or widely used interfaces, are provided to invoke MARINE-EO services, iii) Appropriate admin interface for managing on demand requests,

2. An appropriate data management solution for big data analysis is deemed necessary, 3. Tools to easily deploy scalable processing and data analytics, accessing the complete data archive

(discover and access) on the platform, 4. OpenStack or similar private cloud for service deployment.

The platform should be scalable enough to store and process large data-sets, whilst allowing analytics on

large time series of data.

Figure 13 High Level Architecture of MARINE-EO

3.2.1 Platform Tool

As Copernicus commences a new era of huge amount of data, services and products (e.g. Sentinels,

CMEMS, Contributing mission), thus an optimal software tool should be used for the “Platform Tool” so as

to uninterruptedly process large amounts of data efficiently, by separating the data into smaller amounts

and performing large numbers of parallel operations on the data. This may apply either for regular




processing of big data and/or for on-demand processing of EO data, providing fast access and analytics on

long time series of historical data.

This shall be commonly used to support all MARINE-EO’s downstream services and others that are

envisaged to be developed after the end of the project, allowing other demanding workflows and processes

to be parallelized on a powerful processing cluster with direct access to archive data. The current status of

those services is to run on a single server, fragmented, with limited capabilities and operational/cost

efficiency.

The powerful Platform tool that, will be chosen by the tenderers, will ease the process to integrate and

deploy new applications and services in a few steps, whereby modular techniques shall be replicated and

reused in other deployments.

3.2.2 Product/Service exploitation

The Product/Service exploitation tool is serving the access to all Marine-EO products and services through a

web/desktop platform that supports discovery, viewing and data access interfaces using widely accepted

open standards. This tool shall have the capability to stand as a distributed facility, offering the complete

archives of all MARINE-EO’s downstream feature services and raw data.

3.2.3 Data Manager

A state-of-the-art storage system tool should be used to store EO raster data, making them available to the

platform and to the end-users. Network File System and Distributed Filesystem technologies (e.g. HDFS,

GlusterFS and MogileFS) are recommended to be used as the Data manager tool. The Data Manager will be

the main interface (e.g. RESTful API) of several catalogues responsible for searching and accessing of data.

Further to this, the solution should allow the data ingestion from different providers (e.g. Copernicus

Sentinels, CMEMS, download service for the Landsat, other distributed sources such as in-situ data),

ensuring high-performance access to (big) datasets.

3.2.4 Web portal & Desktop App

A web portal and a desktop application shall provide access to all MARINE-EO downstream services,

together with supporting services. The portal and the desktop app should provide all information on the

data and components available on the platform sharing knowledge amongst end-users. Both shall be

designed and integrated providing tailored information depending on MARINE-EO feature services, by using

advanced and widely used components such as JavaScript libraries and Geographic Information System

(GIS) components.

All web-based functionalities shall be designed to make the data, products and services more exploitable

for a wide public.

3.2.5 Web Services

All MARINE-EO services shall be based on widely used interfaces at all levels such as data discovery, data

access, data analytics and on-demand processing, adhering to the extent possible to open standards. There

http://hadoop.apache.org/hdfs/

http://www.gluster.org/

http://danga.com/mogilefs/




are several OGC30 (Open Geospatial Consortium) standards that shall be used for the service

implementation such as WMTS, WFS, WCS, WPS31, but also RESTful interfaces that more easily can be

generated and used by developers. Using OGC and other widely used standards is really critical and a key

requirement of MARINE-EO in order to ensure the interoperability of all services to the new Copernicus era

of the various exploitation platforms that are and will be available such as DIAS, TEPs, EoMALL and other

initiatives coming from the industry.

3.2.6 Cloud Middleware - OpenStack Cloud

Cloud based OpenStack software tool is able to control large pools of compute, storage and networking

resources throughout a big data center. This cloud computing technology allows dynamic resource

provisioning that safeguards both uninterrupted performance and scalability. Though, OpenStack32 is

considered an applicable option as cloud middleware for a private cloud solution. The solution offers pre-

configured VM (Virtual Machines), providing the appropriate OpenStack environment needed to the end-

users to work with data (access to the complete data archive) and develop/deploy/run services and

applications on the platform. Furthermore, end-users can also customize the environment to their needs by

downloading more data and adding other (e.g. software) tools.

Each MARINE-EO feature service, though, will be deployed through Cloud Middleware leveraging on

interfaces, tools and the Integrated Development Environment (IDE) that will ease the process. All system

components shall be loosely coupled and use messaging for communication. A wide range of s/w, libraries

and other tools and components shall also be available to developers. As an upcoming solution, DIAS (Four

different consortia have signed contracts with ESA33) can be considered as cloud middleware.

As an already implemented case can be considered ESA’s Research and Service Support (RSS)34 that

supports the Earth Observation community in exploiting EO data, by developing new algorithms and

applications and generating and delivering value-added information, through the RSS CloudToolbox

service35. The RSS CloudToolbox service provides registered ESA EO-SSO users with customised virtual

machines (VMs) made available on a cloud infrastructure, that are equipped with the latest ESA and third-

party tools for EO data processing (e.g. SNAP, Sentinel Toolboxes, NEST, PolSARpro)36.

3.2.7 Data Storage

Data storage shall contain all these types of datasets that are needed for MARINE-EO feature services,

minimizing the big cost of big data. The bidder, based on service requirements, shall propose the ultimate

data model and all relevant interfaces that will be used or developed for harvesting and storing data to

MARINE-EO cloud infrastructure.

Apart from the well-known applied solutions (PostgreSQL/ PostGIS) that provide spatial querying capability

on data, it is necessary, for systems’ scalability, the database to be designed on multiple nodes, exposing its

30

OGC. Available online: http://www.opengeospatial.org/ 31

OGC standards. Available online: https://en.wikipedia.org/wiki/Open_Geospatial_Consortium 32

OpenStack. Available online: https://www.openstack.org/ 33

http://copernicus.eu/news/copernicus-dias-contracts-signed 34

Research and Service Support (RSS). Available online: https://wiki.services.eoportal.org/tiki-index.php?page=About+RSS 35

RSS CloudToolbox service. Available online: http://eogrid.esrin.esa.int/cloudtoolbox/ 36

ESA Software Tools. Available online: https://earth.esa.int/web/guest/software-tools

http://www.opengeospatial.org/

https://en.wikipedia.org/wiki/Open_Geospatial_Consortium

https://www.openstack.org/

https://wiki.services.eoportal.org/tiki-index.php?page=About+RSS

http://eogrid.esrin.esa.int/cloudtoolbox/

https://earth.esa.int/web/guest/software-tools




own native interfaces to back-end and front-end interfaces. The communication with the database shall be

made through dedicated API both for the data providers and the service users.

3.2.8 Downstream Services

There are 5 (3 for SATOCEAN and 2 for SATSURVEILLANCE) operating and several supporting services that

will be developed within MARINE-EO context. Operating services are dedicated to specific scenarios serving

identified needs from the end-users. In contrast, supporting services are more generic and in a sense

complementary to operating services. This section, based on scenarios defined in previous documents,

defines both types of services, providing also the operating activities of each service and clarifying the

products expected to be delivered.

In order to elaborate the understanding of figures below (UML Activity diagrams37), hereunder common

assumptions are being made:

There are three main actors in all services the end user who usually triggers the process, the service provider who automatic or semi-automatic provides the service and the Data storage where all data and products are archived.

The operating activities shall be as simple and generic as possible minimizing the occurrence of a service not being available. However, usefulness and usage of the service shall be ensured.

All services are based on data and parameters that have already been defined in previous sections.

All figures below are indicating for each use case scenario the envisaged workflow of operations that could be enhanced/ modified based on Contractors proposed solution, keeping though intact what is expected to be provided.

Most of operating activities are initiated from the end-users, having also some cases where regularly (daily, weekly) the service automatically retrieve, compute data and generate value added information that can be retrieved or further processed based on end-user request.

37

UML Activity diagram. Available online: https://en.wikipedia.org/wiki/Activity_diagram




3.2.8.1 Operating Services

3.2.8.1.1 MARINE environmental status in hot spots (AOIs e.g. Gulfs, MPAs etc.)

Figure 14 SATOCEAN-UCS-1: MARINE environmental status in hot spots (AOIs e.g. Gulfs, MPAs etc.) service operational activities

3.2.8.1.2 Fish Farms: Detection of Fish farms threats

Figure 15 SATOCEAN-UCS-2: Fish Farms: Detection of Fish farms threats




3.2.8.1.3 Detection of vessels and icebergs in Arctic areas

Figure 16 SATOCEAN-UCS-3: Detection of vessels and icebergs in Arctic areas

3.2.8.1.4 Unusual/Irregular activity monitoring around a Critical Infrastructure

Please see Figure 8: Operational View (OV) 3, operational node connectivity overview. Maritime Monitoring

Services in section 2.4.1.

3.2.8.1.5 Enhanced Change Detection

Please see Figure 10: OV 3 operational node connectivity overview. Regional Change Detection - Enhanced

Change Detection, Figure 11: OV 3 operational node connectivity overview Targeted Change Detection

Mode and Figure 12: OV 3 operational node connectivity overview. Action Mode - Enhanced Change

Detection in section 2.4.2.




3.2.8.2 Supporting Services

The following sub-sections provide information about the supporting services that need to be developed.

3.2.8.2.1 Assurance Service

Overview

Return a confidence certificate regarding the likelihood of the service being successful in regards of data

availability to implement the service (new acquisition or archived imagery).

Workflow

Each Service Provider must assign an Administrator, who shall be a technical expert with knowledge on

satellite imagery and geospatial analysis. The Administrator will perform technical feasibility analysis on a

User Request. The Administrator has to investigate and assess the feasibility of the orders (User Requests,

UR) (type of request, time range).

The system must have a view mode and specific sections for the Service Provider’s Administrator. This view

mode will include (pending) user requests, the choice to discard or validate a request, evaluation reports

made by End-Users and more.

The system must have an automated or semi-automated way to provide all the information needed to help

the administrator’s feasibility assessment of an order and a standard response to a user request because

the End-Users have to know in advance the availability and the effectiveness of a specific service. After the

validation (see request states below) from the administrator, the system will send a report to the End-User,

that will contain a description of what will be delivered, the cost of the service, timelines of delivery and at

which confidence interval. The system notifies the End-User and waits for an action. The End-User must

Validate, Modify, or Cancel the order (User Request).

The End-Users must be able to know specific things prior to using it, importantly, the probability or the

confidence interval of detecting an object of a particular size in an Area of Interest. As mentioned, all

acquisition requests through the DWH shall be previously validated by the End-Users. Also, the End-User

must be informed about: Estimated quota consumption, Quota Available, Purpose, AOI, Dataset Used.

According to the acknowledgement/assurance report, the End-Users decide whether to proceed with the

order, hold or postpone.

The Phases of a User Request could be the following:

Table 9: Possible request states

Request States Description

Saved The end-user prepares a User Request and saves it

for later, without submitting it.

Defined The end-user makes a User Request.

Received The admin receives and has to assess the feasibility




Request States Description

of the User Request.

Validated (by admin) The admin assesses the User Request as feasible and

proposes data orders which are required to fulfil the

request as well as additional conditions which might

impact the service (e.g. weather conditions,

detectability of objects etc.).

Validated (by end-user) The end-user approves the order(s) after being

informed by the assurance service report.

Rejected The admin rejects the order.

Modified The End-User modifies the order.

Postponed The End-User suspends temporarily the order

(usually after the assurance report).

Canceled/Discarded The End-User cancels the order.

Concluded The End-User evaluates the quality of service

provided.

3.2.8.2.2 Evaluation Service

Overview

Allow end-users to return feedback on the actual performance of the system/ the EO-based service and

their overall experience.

Workflow

The End-Users after a time-period following the service delivery will be prompted via an email to evaluate

the service they received. The evaluation will be done through an online form, such as a questionnaire. The

questionnaire will ask the users to rate certain features and characteristics of the services on a scale from 1

to 5. The questionnaire will also contain some open-ended questions where needed, so that the users can

add extended comments, suggestions and/or recommendations for the services they received, and any

complaints they may have that were not covered by the questions. Once the evaluation report is ready, the

system will notify the Administrator and forward the results. The results will be added in a system where

they will run through an analysis, and an aggregated score for the service will be produced. This score will

be calculated along with other user submitted scores, and a collective result (a rating) for each service can

be displayed on the portal, as a feedback for the rest of the users, using figures such as plots, charts or

relevant.

3.2.8.2.3 Login Service

Overview




The site will support users with multiple access levels. The users will register, create an account, and then

log into the system. This will ensure that only verified users will be able to access the services and make

requests. The system will offer three types of users: the individual user; the organization; and the

organization member.

Workflow

A person can apply for an account on the portal. The administrator will receive the application and a

number of steps will be followed. During the application for an account, the applicant will be asked to fill in

a form with certain pieces of information. Such information will be their personal information, the reason

they are applying for an account, and what type of user account they are applying for. If the applicant

applies for an individual user account, they will be prompted to fill in their billing details (as optional field so

as to ease the process of generating requests) as well. If the applicant applies for an organization account,

they will also be prompted to fill in billing details, as well as details for their organization, such as the type

of organization, etc. If the user applies for an organization member user account, then they will be asked

for their organization email or details. The administrator, then, will contact the organization in question in

order to verify that the potential user is indeed a member of this organization. If this is verified, the

applicant’s account will be activated, and they will be able to use the services according to the quota of

their organization.

The billing will be according to the types of user. Individual users will have different prices and quota from

organization users. Organization users will have larger quota, given that their members will be using the

service. These three types of users and authentication will ensure the security and best practice of the

services.

3.2.8.2.4 Catalogue & Subscription Service

Overview

The supporting service shall provide the technological means to the End-Users to view the available

services and the relevant AoI that those services are being applied to. A catalogue that can retrieve and list

all offered services is deemed necessary, including also a subscription mechanism, where users shall

subscribe to, in order to access and view the available services. For security services the subscription may

not be an easy process as it should be allowed by the administration.

Workflow

The OGC EO Product Collection, Service and Sensor Discovery using the CS-W ebRIM Catalogue document is

available and free to the public at http://www.opengeospatial.org/standards/bp.

The service provision will rely on the data, services and products that will be available for specific oOI, thus

the user shall be able to be easily informed about the available data/services/products and the relevant

AoIs based on an intuitive catalogue.

Standard approaches can create a catalogue such as Catalogue Service – Web (CSW) provided by OGC that

defines common interfaces to discover, browse and query the metadata of data/services/products. There

was a specific initiative, in which OGC created a tailored document for EO Product Collection, Service and

http://www.opengeospatial.org/standards/bp




Sensor Discovery using the CS-W ebRIM Catalogue. The standard document delivered a set of minimum

metadata elements that are required to designate a collection of EO products. The proposed approach of

the “Catalogue document”38 is to identify a common set of elements grouped in a common (EOP) schema

and extend this common schema to add sensor class specific metadata.

Based on this and after the end of the project, additional service Providers will be able to register their

Copernicus based services in the Service catalogue of MARINE-EO. The approach must have a registration

form for the service providers, nominating an Administrator.

A subscription mechanism shall be developed allowing users to easily have access and use and/or view the

services. For security services and information that are not publicly available (e.g. DHW data), a specific

workflow shall be implemented, engaging also the administrator of the service.

3.2.8.2.5 Service Request

Overview

End-Users shall be able to request for a specified AoI the implementation of an existing service. Each

request is followed by an acknowledgement from the provider that contains a description of what will be

delivered, the cost, timelines for delivery and at which confidence interval. Based on the

acknowledgement, the users decide to proceed with the order, hold or even postpone: this is a multi-

criteria decision made based on the evidence provided in the acknowledgment plus the current operational

situation and other decision rules falling outside the project context.

Workflow

The End-Users will be able to navigate through the different services and select those that fit their

operational routine. The navigation will be achieved either by simply browsing the services, or by applying

filters. The filters available, according to the service characteristics and the relevant metadata, will be the

following: time, place and product types (Optical Imagery, Radar Imagery - SAR). The browsing of the

services will also have a different view, in order to help the users with what they are looking for and best

meet their needs. This view will comprise of a map, on which all services will be listed according to the area

they are referring to or they are available for. By selecting an area the End-User will be presented with a

catalogue/registry listing all available services that could be requested.

3.2.8.2.6 Access to Sentinels and contributing missions data

A registered user shall be able to search through the catalogue service all Satellite data that are available

together with all information extracted through the metadata files from the end-products.

Sentinel data

A tool shall be developed to download Sentinel data from ESA or other Collaborative Ground Segments

such as the Hellenic National Sentinel Data Mirror Site and the CODE-DE (Copernicus Data and Exploitation

platform – Deutschland). The tool shall be capable of downloading the whole products or only one tile per

product. The development of such tool shall be based on schihub API that is well defined and is based on

two APIs the Open Data Protocol (OData), the Search (Solr). In addition, it is important for the user to be

38 Catalogue document. Available online: http://www.opengeospatial.org/standards/bp

https://sentinels.space.noa.gr/

https://code-de.org/

https://code-de.org/

https://scihub.copernicus.eu/userguide/5APIsAndBatchScripting

http://www.opengeospatial.org/standards/bp




aware of the limitation that each user can download two products. Most probably a Python routine should

be needed to be developed; enabling batch downloads of Sentinel products from ESA distribution website

or others. To this end, the tool shall allow to perform catalogue searches and select the data by date, type,

location and in some cases even per cloud percentage.

As an alternative to the current status, DIAS is to become the solution to all above limitations and provide

not only direct access to Sentinel and other products but also the resources to deploy the solutions close to

the data, providing lots of advances and functionalities to make easily both the development and the

integration of downstream services.

Copernicus Contributing Mission data

Copernicus Contributing Missions (CCMs) data deliver essential information, having a complementary role

to Sentinel data, whilst satisfying most of additional requirements that are needed (e.g. Very High

Resolution data – radar/optical/Atmospheric).

The process of gathering CCM data is the following: EC collects users’ requirements and then, through

procurement procedures, ESA is gathering data through series of CCMs. All types of datasets and the

conditions under which the corresponding EO data are accessible is being described in Data Warehouse

phase 2 DAP v2.2.

Contributing Mission data can be ordered through the Copernicus User´s Personal Area, which requires

registration to the Coordinated Data Access System (CDS). The user needs to subscribe to the ADDitional

Datasets (available on-demand, see https://spacedata.copernicus.eu/web/cscda/data-offer/add-datasets).

Ordering is done through a Standard Data Request page or through a Service Project Emergency Request

Form (SPERF), depending on the time-critical conditions. Even after ordering, the user needs to

communicate with the DHW administrator about the availability of imagery, image quicklook reviews and

eventually accept satellite images once they become available.

Thus, the process acquiring CCM data it is not an automated process, as it stands for Sentinel data. The user

has to create a Copernicus SSO account (Single Sign On Login) to access the Copernicus Space Component

Data Access (CSCDA) services. Then, through an interface, the user shall specify the specific quota of data

that is needed and then a process is initiated. Depending on the quote, the process can last from couple of

hours to some days. Thus, it is a not straightforward process, as it requires a lot of communication (both via

email and even by phone) with the DWH.

3.2.8.2.7 Authorization & Authentication techniques

Overview

Implementation of EU eyes only cryptographic techniques. MARINE-EO Service requests and deliveries will

take place over public networks and infrastructures (mostly internet). Thus, it is mandatory to propose

certain communication security techniques (like encrypted transmission) plus user authorization and

authentication techniques. A MARINE-EO Public Key Infrastructure (PKI) will have to be considered to allow

peer-to-peer secure communications between providers and end-users.

Workflow



https://spacedata.copernicus.eu/web/cscda/data-offer/add-datasets

https://ssoidp.copernicus.eu/idp/umsso20/adapter?conversation=e1s1

https://ssoidp.copernicus.eu/idp/umsso20/adapter?conversation=e1s1




The data that will be provided through the MARINE-EO service system includes sensitive data and requires

special attention, especially in privacy compliance issues and security. The authorization techniques used in

user registration provide a first firewall against cyber threats and data theft. However, more obstacles need

to be set up in order to secure the proper use and distribution of the data, offered by the service. The

authentication process should make use of the latest technologies ensuring security against online identity

theft. This will ensure that only registered and verified users will have access to the content of the website.

The data distribution can, for example, comply with the standards of eDelivery39 technical specifications,

which allow the secure and reliable exchange of documents and data.

3.3 Architecture requirements

This sub-section provides specific requirements based on information provided in section 0 which the

proposed architecture must adhere to. These architectural requirements are being formalized contributing

to the tender specifications.

3.3.1 Functional Requirements

RAf 1. The contractor shall have hands on experience on retrieving data, services and products from EO

(e.g. NASA, COPERNICUS, CMEMS) and relevant (e.g. NOAA) infrastructures.

RAf 2. MARINE-EO platform shall be equipped with three types of access interfaces: Web Portal

providing access to different applications, data and related documentation via a simple Web

browser, ii) Web Services, according to standardized or widely used interfaces, are foreseen to

invoke MARINE-EO services, iii) Appropriate admin interface for managing on demand requests.

RAf 3. MARINE-EO solution shall provide a single-sign-on approach to use all downstream services.

RAf 4. OpenStack or similar private cloud solution shall be used for service deployment.

RAf 5. A data management solution for big data analysis shall be proposed, automated workflow and/or

machine learning techniques.

RAf 6. The system shall provide widely used interfaces at all levels (data discovery, data access, data

analytics, on-demand processing), if possible based on open standards.

RAf 7. Tools to easily deploy scalable processing and data analytics, accessing the complete data archive

(discover and access) on the platform.

RAf 8. Widely use of OGC standards shall be ensured (e.g. WMTS, WCS, WPS, WFS CSW) and RESTful

interfaces where deemed necessary, so as to be easily integrated from other interested parties

and/or be easily replicated in other areas.

RAf 9. The data storage to be used by the system will be composed by a wide variety of sources that

implies a wide variety of data formats and services.

39 eDelivery. Available online: eDelivery building block.pdf

https://joinup.ec.europa.eu/sites/default/files/ckeditor_files/files/(Building%20Block%20DSI_IntroDocument)%20(eDelivery)%20(v1%2002).pdf




RAf 10. MARINE-EO system shall regularly poll all data (connectors) either new or updated data, thus

providing access to the most up-to-date data from all available sources.

RAf 11. The system shall provide access to the End-users on the full archive of raw, processed historic EO

data as well as the corresponding products.

RAf 12. Both standardized and non-standardized external data interfaces shall be integrated into

MARINE-EO solution.

RAf 13. Two entry points to the system should be provided to end-users (Web-Platform and the Desktop

App), providing universal access to the data, products and services which in turn gets data from a

variety of different sources

RAf 14. Data privacy and sharing should be ensured by applying a code of practice based on entrusted

solutions.

3.3.2 Non-Functional Requirements

RAnF 1. The contractors shall have background knowledge of all past and undergoing activities on EO

threads (e.g. DIAS, TEPs, Available proprietary system solutions).

RAnF 2. The proposed solution shall be extensible enough to ingest and connect new data sources from

other AOIs.

RAnF 3. Interoperability should be ensured at each development stage, adhere both to common well-

defined interfaces (OGC and others).

RAnF 4. Both modularity of each component and communication between modules should be ensured.

RAnF 5. The system must be scalable enough so as to safeguard the performance as the number or the

frequency of service requests increase.

RAnF 6. High availability of the services shall be ensured, being robust enough to external factors (e.g.

server cash, unexpected transmissions problems).

RAnF 7. The solution shall include an advanced security technology, providing different levels of access

to end-users and admin.




4 GENERAL REQUIREMENTS (THEMATIC AREAS 1 AND 2)

4.1 CONTRACT MANAGEMENT REQUIREMENTS

As stated in ISO/IEC 15288:2015, the purpose of the contract assessment and control process is to

determine the status of the contract and contract execution plan in order to ensure that the contract

performs according to the plan and schedule to satisfy technical objectives.

This process evaluates the progress, achievements and business objectives (contrasting them with the

requirements and plans), periodically and at major events. Information is communicated for management’s

action when significant variances are detected. This process also includes redirecting the contract activities

and tasks, as appropriate, to correct identified deviations and variations from the Contract Management

Plan. Redirection may include re-planning when appropriate.

The Contractor shall provide contract management processes and tools adequate for monitoring and

evaluating the progress achieved in the execution of the contract phases. The main objectives of these

processes are:

Continuous monitoring of the contract progress.

Early identification of problems and successes.

Evaluation of contract’s achievements.

The methodology provided by the Contractor shall be based on a comprehensive list of well-defined

milestones and the set of pre-defined procedures should ensure that these milestones are successfully

reached.

4.1.1 CONTRACT MANAGEMENT PLAN (MILESTONES, DELIVERABLES, WORK BREAKDOWN STRUCTURE, ETC.)

MNG 1. A Project Management Plan (PMP) including all the deliverables table of contents shall be included

in the proposal. At least the following contents shall be well identified in PMP:

Operational Concept

System/Subsystem Specification

Interface Requirements Specification

Service deployment lifecycle

Software testing approach

Quality Management approach

Configuration Management approach

TRL Assessment




MNG 2. Progress report shall be delivered to the Lead Procurer by E-mail. The Contractor shall propose a

complete reporting strategy taking into consideration that:

Current versus planned status

Main achievements

Main problems and mitigation actions

Points to be taken into account by Buyers

MNG 3. Documentation shall be provided in electronic format compatible with MS Office 2010 (or

equivalent) as long as not otherwise agreed with the Contracting Authority.

MNG 4. The Contractor shall define a risk management plan according to the ISO/IEC15288:2008,

describing how risk management will be structured and performed on the project. During the

project, the Contractor shall gather the potential risks details (technical, operational, managerial,

etc.) which can appear during the contract execution. For each potential risk, the Contractor shall

assign the estimated probability and the expected impact as well as proposing the most adequate

mitigation strategy to reduce or mitigate the risk.

MNG 5. Documentation and milestones included in 3.5 TD1 are mandatory: Any documentation

concerning contractors that could be requested by European Commission over PCP

implementation shall be generated

4.1.2 CONTRACT MONITORING (SCHEDULE, PAYMENTS, INTERMEDIATE RESULTS, ETC.)

MNG 6. For the execution of the implementation phase, an agile software development process shall be

used (e.g. Scrum).

MNG 7. The Tenderer shall describe, in their proposal, the development process including the involvement

and feedback from the Contracting Authority.

MNG 8. The Tenderer shall indicate, in their proposal, the intended scope of the initial iteration(s).

MNG 9. The Contractor shall provide a requirements management solution with web-access to the

MARINE-EO Consortium to create, review, edit and discuss requirements held in a requirements

repository. All the documentation (OCD, SSS, SRS, IRS, RVTM, IDD, SSDD, STP, STR, STD) shall be

kept up to date in this tool with the corresponding backward and forward traceability

MNG 10. The requirements management solution shall provide bi-directional traceability for impact analysis

and traceability compliance from the Terms of Reference (TOR) through the entire design cycle

(OCD, SSS, SSDD, etc.) up to SAR Test Reports.

MNG 11. The requirements management solution shall provide means to promote the collaboration with

MARINE-EO consortium through requirements discussion.

4.1.3 CONTRACT IMPLEMENTATION (WORK TEAM COMPOSITION, ACCREDITED EXPERIENCE, SUBCONTRACTING, ETC.)

MNG 12. The Contractor shall provide a complete work team organisation description. Such description

shall include a clear view of the roles and responsibilities defined for the project development,




highlighting the strong points of the working team that justifies its suitability for this particular

contract.

MNG 13. The Tenderer shall accredit large experience in satellite-based downstreaming services. The

Tenderer should accredit such experience by describing services that are currently operationally

exploited by End-Users.

MNG 14. The Contractor shall take care of all the subcontracting tasks associated with the certification of

the external Data and Service Providers or the provision of modules of the service catalogue.

This shall include:

The drafting and consolidation of a Service Level Agreement (SLA) document that allows

the system to meet the expected performance.

The promotion of a certification procedure for each external entity.

Tracking of the proper service provision.

The Tenderer shall specify which services can be delivered and which are foreseen to be

covered by potential third parties.

4.1.3.1 PCP PHASE 1: SERVICE DESIGN (5 MONTHS)

During the design phase, the awarded projects will commence to develop the required Services.

MNG 15. The following technical milestones and derived documentation are mandatory:

Technical

milestone

Expectations Content to deliver

M1.2) Preliminary Design Review (PDR)

documentation

delivery

The PDR ensures that (i) the preliminary design and basic system architecture are complete and (ii) there is technical confidence that the needed capability can be satisfied within cost and schedule goals. A preliminary design (hardware and software), including interface descriptions, is complete and satisfies all requirements in the system functional baseline.

Requirements trace between functional and allocated baselines is complete and consistent.

System performance analysis is complete and assessed to meet requirements. Computer system and software architecture designs have been established. All Computer Software Configuration Items (CSCIs), Computer Software Components (CSCs), and Computer Software Units (CSUs) have been defined. Software Requirements Specifications (SRSs) and Interface Requirement Specifications (IRSs), including verification plans, are complete and baselined for all CSCs, satisfying the system functional requirements.

Interface control documents trace all software interface

requirements to the CSCIs and CSUs.

Executive summary

Operational, functional and data workflows

Data and service models

System/Subsystem Design Description (SSDD)

Interface Design Description (IDD)

Traceability Matrix

TRL assessment at this level (maturity analysis)

Phase 2 offers - feasibility analysis for next PCP stages




4.1.3.2 PCP PHASE 2: PROTOTYPING (9 MONTHS)

During the prototyping phase, the scientific and technical management activities will continue to take

place. At this phase, the Contractor is expected to develop a preliminary implementation of the services

and to demonstrate it.


Technical

milestone


M2.2) and M2.4) Critical Design Review (CDR) documentation

delivery

The CDR confirms the system design is stable and it is expected to meet system performance requirements. Moreover, the CDR confirms the system is on track to achieve affordability.

A detailed design (hardware and software), including interface descriptions, is complete and satisfy all requirements in the system functional baseline.

Requirements trace among functional, allocated and initial product baselines are complete and consistent.

Initial product baseline documentation is sufficiently complete and correct to enable hardware fabrication and software coding to proceed with proper configuration management

An estimation of the system reliability and maintainability based on engineering analyses, initial test results or other sources of demonstrated reliability and maintainability.

Verification (development test and evaluation) assessment to date is consistent with the product baseline and indicates the potential for test and evaluation success.

All risk assessments and risk mitigation plans have been updated, documented, formally addressed and implemented.

System/Subsystem Design Description (SSDD) - The design of a CSCI and HWCI (Update)

Database Design Description (DBDD) - The design of a database if needed

Interface Design Description (IDD) - The design of one or more interfaces (Update)

Traceability Matrix

Software Validation Specification(SVS)

TRL assessment update

M2.5) Factory

Acceptance Tests

(FAT)

The FAT milestone determines whether the Prototype design technologies are mature and proven. Product acceptance system, including acceptance test

procedures and associated equipment, has been

validated and put under configuration control.

Prototype Software & Hardware Test Plan (STP) - A plan for conducting qualification testing

Prototype Software & Hardware Test Description (STD) – Test cases/procedures as run for qualification testing




Technical

milestone


Prototype Software & Hardware Test Report (STR) - Test results of qualification testing

Traceability Matrix

4.1.3.3 PCP PHASE 3: DEVELOPMENT, VERIFICATION AND OPERATIONAL VALIDATION (13 MONTHS)

At this phase, the remaining Contractors will develop the final version of the services, verify and validate

them.


Technical

milestone


M3.4) Set-up

Phase Readiness

The Set-up phase readiness technical milestone is the

technical assessment point at which the actual system

performance is verified to meet the requirements

defined in the system performance specification and

documented in the system functional baseline.

Documented achievement of functional and/or

allocated baseline requirements through the

appropriate documented verification method

(analysis, demonstration, examination, testing or any

combination thereof) are reviewed and verified.

Software & Hardware Test Plan (STP) - A plan for conducting qualification testing

Software & Hardware Test Description (STD) – Test cases/procedures for qualification testing

Traceability Matrix

M3.5) End-Users Training

Software User Manual (SUM) – Software practical

instructions for the users

Specific training sessions are given to the End-Users.

Software User Manual

(SUM) - Software practical instructions for the users Procedure to optimize data collection-cost tradeoff shall be made available to end users including performance assessments per target type and input EO data

Technical analysis on sensor suitability versus surveillance needs including guidelines for service request planning




Technical

milestone


M3.6) Operation Result testing and System Acceptance Review (SAR)

The SAR milestone determines the testing of the

system in real operational scenarios.

Technologies are mature and proven in the final form,

in operational environments.

Product acceptance system, including acceptance test procedures and associated equipment, has been validated and put under configuration control.

Software & Hardware Test Report (STR) - Test results of qualification testing

Integration Test Reports.

Traceability Matrix

Operational Validation

During this phase, each solution that integrates the MARINE-EO Services (developed and tested) shall be

run in a real operation for a certain period of time (TBD).

The operation of the Solutions in real environment will allow the Contracting Authority to measure a set of

Operational Indicators MoE (Measures of Effectiveness) defined by the End-Users during the Phase 1 of

MARINE-EO project.

MNG 18. If failures are detected during the operation review, the Contractor will have a limited period of

time to implement the necessary minor changes required for enhancing the results before initiating

another operational period. This second period (one month) will be re-scheduled inside the available

window of operation related to the coordinating and participating authorities’ availability.

4.1.4 EXPLOITATION PLAN

MNG 19. The Contractor shall develop at each PCP phase a short to mid-term exploitation plan, including a

commercialization strategy considering other acquisition modalities different to direct purchase (e.g.

provision surveillance services, leasing of equipment, renting of equipment, coownership, etc.) and the

roadmap designed to take each Service to market.

This study shall describe the Services, conditions for contracting or acquiring this product, SLAs, costs

breakdown, potential market, etc., indicating whether the full solution or parts of it can be used. If only

parts of the solution can be used, the selected parts have to be obviously able to function as a separate set.

The study shall also show the potential re-usability and extensibility of such services regarding End-User

type and domain (other than maritime surveillance).




5 ANNEXES

5.1 PDR DOCUMENTATION PER LOT

It can be made up of one or several documents. Apart from annexes, no more than 100 pages of should be

included. A comprehensive view of the proposed design shall be included within the 100 pages’

documentation.

Annexes for traceability matrices, data schemas, or long and detailed descriptions are not page limited.

Following contents are not mandatory but part of the evaluation processes will be organized around them.

Executive summary (1 page)

Operational, functional and data workflows Aim: Context of operational scenarios (actors, external systems/entities, timelines, deployment, etc.) functional and data associated workflows description.

System scope

Operational environment (system boundaries shall be clear)

Support environment (external entities and interrelations with the system)

Description of operational scenarios

Capabilities identification and workflows

Deployments and support NOTE: Some workflows can be included in an annex

Data and service models

Approach to be followed (interoperability with CISE model shall be included here)

Service structure, modularity and interoperability

Data approach (data analysis and standards)

Data and service model structure NOTE: complete description must be included in an annex


Comprehensive architecture view: static and dynamic

Configuration items design: Functions, dependencies, interfaces, data, workflows, traceability


Software and hardware external interfaces

Man-machine interfaces

Software items interfaces

NOTE: when required complete description can be included in an annex

Traceability Matrix




Configuration items to requirements in technical offer to tender documentation

Tender documentation to technical offer to configuration items


Identify current TRL for items to be analysed (those not already operational) and final goal

Per item, describe the planned process to reach final TRL including validation

5.2 CDR DOCUMENTATION PER LOT

It can be made up of one or several documents. Apart from annexes, no more than 100 pages of should be

included. A comprehensive view of the proposed design shall be included within the 100 pages’

documentation.

SSDD and ICD It shall be a new version of part of the contents included in PDR documentation. Data base

design shall be included if necessary. A description of the Software Validation Specification shall be

provided. Finally, TRL assessment shall be updated, including achievements and planned steps.

Annexes for traceability matrices, data schemas, or long and detailed descriptions are not page limited.


Executive summary (1 page)


Comprehensive architecture view: static and dynamic

Configuration items design: Functions, dependencies, interfaces, data, workflows, traceability

Database Design Description (DBDD)

Database schema

Connection string

Relational tables description


Software and hardware external interfaces

Man-machine interfaces

Software items interfaces

NOTE: when required complete description can be included in an annex

Software Validation Specification (SVS)

Validation tasks identification: items, requirements to be tested/not tested, test pass-fail criteria, other criteria when no tests are included. A group of test designs will be identified.




General test environment: tools, deployments, interfaces, test data sets and support

Test design specification: items, features to be tested, interfaces, inputs, outputs, test environment, pass-fail criteria

NOTE: Procedures (when available, they will be included in annexes)

Traceability Matrix

Configuration items to requirements in technical offer to tender documentation (update)

Tender documentation to technical offer to configuration items (update)

Test designs to requirements in technical offer to tender documentation

Tender documentation to technical offer to test designs


Per item under analysis, describe current achievements and planned process to reach final TRL including validation

5.3 FAT DOCUMENTATION PER LOT


Prototype Software & Hardware Test Plan (STP)

A plan for conducting qualification testing

Prototype Software & Hardware Test Description (STD) – Test cases/procedures as run for qualification testing

Procedures from SVS executed during actual tests

Prototype Software & Hardware Test Report (STR) - Test results of qualification testing

Summary of activities carried out

Items and requirements covered at this point (level of compliance)

Outcomes analysis

Next phase validation approach

Traceability Matrix

Test cases to requirements in technical offer to tender documentation (update)

Tender documentation to technical offer to test cases (update)


Per item under analysis, describe current achievements and planned process to reach final TRL including validation




5.4 PHASE 3 DOCUMENTATION CONTENTS

To be defined.

Documents

Tender Document 2 MARINE-EO PCP CHALLENGE · 2018-06-29 · Pre-Commercial Procurement (PCP) Tender Document 2 – MARINE-EO PCP CHALLENGE Deadline to submit an offer: 9th April 2018