D2.14 HEIMDALL Integration and Verification...

D2.14

D2.14

HEIMDALL Integration and Verification Report

Instrument Collaborative Project

Call / Topic H2020-SEC-2016-2017/H2020-SEC-2016-2017-1

Project Title Multi-Hazard Cooperative Management Tool for Data Exchange, Response Planning and Scenario Building

Project Number 740689

Project Acronym HEIMDALL

Project Start Date 01/05/2017

Project Duration 45 months

Contributing WP WP 2

Dissemination Level PU

Contractual Delivery Date M42

Actual Delivery Date 05/01/2021

Editor Georgios Gardikis (SPH)

Contributors S. Pantazis, A. Manolopoulos, S. Konstantinidis, A. Marinos, J. Mastoras, I. Mertzanis, T. Michalakis, I. Papaioannou (SPH)

HEIMDALL [740689] D2.14

05/01/2021 i

Document History

Version Date Modifications Source

0.1 24/11/2020 ToC SPH

0.2 10/12/2020 Integration and verification approach SPH

0.3 17/12/2020 Integration and testing, QA version SPH

0.4 21/12/2020 QA review DLR-KN, PCF

1.0.D 21/12/2020 Final version SPH

1.0.F 05/01/2021 Version approved for submission DLR

HEIMDALL [740689] D2.14

05/01/2021 ii

Table of Contents

List of Figures ........................................................................................................................ iv

List of Tables .......................................................................................................................... v

List of Acronyms .................................................................................................................... vi

Executive Summary .............................................................................................................. 8

1 Introduction .................................................................................................................... 9

2 Overview of the HEIMDALL system...............................................................................10

2.1 Overall system architecture ....................................................................................10

2.2 Key system elements .............................................................................................11

2.3 Integration and verification approach ......................................................................11

HEIMDALL system integration ........................................................................11

Integration testing and verification ...................................................................14

3 Integration and testing ...................................................................................................16

3.1 GUI ........................................................................................................................16

Deployment and Integration ............................................................................16

Integration tests ...............................................................................................16

3.2 User and Role Management ...................................................................................17



3.3 Earth Observation ..................................................................................................18



3.4 Aerial based data ...................................................................................................19



3.5 Landslide monitors .................................................................................................20



3.6 Crowdsourced and First Responders data .............................................................21



3.7 External Systems ...................................................................................................22



3.8 Fire Simulation .......................................................................................................24

HEIMDALL [740689] D2.14

05/01/2021 iii



3.9 Flood Simulation ....................................................................................................26



3.10 Landslide modelling ................................................................................................27



3.11 Scenario Management ...........................................................................................29



3.12 Risk and Impact Assessment .................................................................................30



3.13 Situation Report .....................................................................................................32


Integration Tests .............................................................................................32

3.14 Scenario Matching..................................................................................................33



3.15 Decision Support ....................................................................................................34



3.16 SatCom ..................................................................................................................35



3.17 Information Gateway ..............................................................................................36



3.18 Catalogue ...............................................................................................................37



4 Conclusion ....................................................................................................................39

5 References ....................................................................................................................40

HEIMDALL [740689] D2.14

05/01/2021 iv

List of Figures

Figure 2-1: HEIMDALL high-level system view .....................................................................10

Figure 2-2: Local unit architecure .........................................................................................11

Figure 2-3: HEIMDALL system physical topology .................................................................13

Figure 3-1: Successful login using the GUI ...........................................................................17

Figure 3-2: User name and role properly displayed (top right) ..............................................18

Figure 3-3: EO product properly displayed as a map layer ...................................................19

Figure 3-4: Data from drones ................................................................................................20

Figure 3-5: Sensor data integration ......................................................................................21

Figure 3-6: FR data integration .............................................................................................22

Figure 3-7: Weather forecast integration ..............................................................................23

Figure 3-8: Integration of external data .................................................................................24

Figure 3-9: Triggering a new simulation ................................................................................25

Figure 3-10: Wildfire simulation results .................................................................................25

Figure 3-11: Flood simulation triggering................................................................................26

Figure 3-12: Flood simulation results ....................................................................................27

Figure 3-13: Landslide modelling triggering ..........................................................................28

Figure 3-14: Landslide modelling results ..............................................................................28

Figure 3-15: Scenario management (1/3) .............................................................................29



Figure 3-18: Wildfire impact assessment ..............................................................................31

Figure 3-19: Landslide impact assessment ...........................................................................32

Figure 3-20: Situation report document ................................................................................33

Figure 3-21: Scenario matching ............................................................................................34

Figure 3-22: Decision support ...............................................................................................35

Figure 3-23: Alert message editing .......................................................................................37

Figure 3-24: Browsing Catalogue products ...........................................................................38

HEIMDALL [740689] D2.14

05/01/2021 v

List of Tables

Table 2-1: Integration plan ....................................................................................................14

Table 2-2: Test case template for integration tests ...............................................................14

Table 3-1: Test case TS_INT_01 ..........................................................................................16









Table 3-10: Test case TS_INT_10 ........................................................................................27









HEIMDALL [740689] D2.14

05/01/2021 vi

List of Acronyms

AOI Area of Interest

API Application Programming Interface

AVA Avanti Communications LTD

CA Consortium Agreement

CIMA Centro Internazionale in Monitoraggio Ambientale – Fondazione CIMA (CIMA Foundation)

COP Common Operational Picture

DLR Deutsches Zentrum für Luft- und Raumfahrt e.V. (German Aerospace Center)

EO Earth Observation

FTP File Transfer Protocol

GUI Graphical User Interface

HTTP HyperText Transfer Protocol

ICGC Institut Cartogràfic I Geològic de Catalunya (Catalan Institute of Cartography and Geology)

JSON JavaScript Object Notation

LU Local Unit

REST Representational State Transfer

SP Service Platform

SPH Space Hellas S.A.

UeRM Users and Roles Management Module

UNISTRA Université de Strasbourg (University of Strasbourg)

VPN Virtual Private Network

WP Work Package

WPL Work Package Leader

HEIMDALL [740689] D2.14

05/01/2021 vii

Intentionally blank

HEIMDALL [740689] D2.14

05/01/2021 8

Executive Summary

By M41, all the components of HEIMDALL have been integrated into an end-to-end system. The final HEIMDALL system has been engineered according to the project’s system engineering methodology and plan, complies with the updated functional requirements, and its implementation has followed the system architecture document.

This document overviews the integrated HEIMDALL system, describes the technical approach followed for the integration of each element and includes a set of system-level tests which verify the proper interconnection and interoperability among the system elements.

In HEIMDALL, integration continued in an iterative matter, as the services further evolved and more and more API methods and features were added. In each iteration, a series of functional tests (defined by the developer of each module) were conducted to verify proper communication. This iteration resulted in four major system releases: A, B, C and Final.

To enable this continuous integration in HEIMDALL, the project adopted a distributed physical deployment of the system. Most of the system elements/modules are deployed in the premises of the partners developing them. The whole system is brought together using a hub-and-spoke Virtual Private Network (VPN).

Having the Service Platform (SP) as the central element/mediator among all modules, the following modules have already been fully integrated: GUI; User and Role Management; Earth Observation processors; Aerial-based data sources; Landslide monitors; Crowdsourced and First Responders data; External systems; Fire simulators; Flood simulators; Landslide simulators; Scenario management module; Risk and Impact assessment module; Situation report module; Scenario matching module; Decision Support system; Information Gateway and Catalogue.

The interconnection and interoperability of each module has been verified with system-level integration tests, which commonly involve the SP and GUI and verify the communication of data to and from the modules and the HEIMDALL user.

The satellite communications subsystem was not be integrated as the format of the final demonstration was changed and the setup could not be performed due to the restrictions for the COVID pandemic.

Nevertheless, the HEIMDALL system is fully operational. Minor issues, if any, will be addressed to ensure proper operation during the project final demo under all planned scenarios.

HEIMDALL [740689] D2.14

05/01/2021 9

1 Introduction

By M41, all the components of HEIMDALL have been integrated into an end-to-end system. Its features have been already verified through the functional tests presented in this document and validated during the end-user workshops.

The final HEIMDALL system has been engineered according to the project’s system engineering methodology and plan [1], complies with the updated functional requirements, as identified in [2] and its implementation has followed the system architecture document [3]. This document overviews the integrated HEIMDALL system (delivered as a full prototype [4]), describes the technical approach followed for the integration of each element and includes a set of system-level tests which verify the proper interconnection and interoperability among the system elements.

The rest of the document is structured as follows. Section 2 of this document briefly recalls the HEIMDALL system architecture and main components and discusses the integration and verification approach. Section 3 focuses on each of the HEIMDALL system elements/modules and describes how it has been integrated into the system, also presenting the results of focused integration tests. Finally, Section 4 concludes the document.

HEIMDALL [740689] D2.14

05/01/2021 10

2 Overview of the HEIMDALL system

The present section briefly overviews the HEIMDALL system and its components. A more thorough presentation can be found in [1] and [3].

2.1 Overall system architecture A high-level illustration of the HEIMDALL system is shown in Figure 2-1. HEIMDALL uses different data sources, space, ground and aerial based as inputs – as well as external systems and data sources. A Local Unit (LU) provides services for scenario management, modelling and simulation features to forecast the behaviour of hazard, risk and vulnerability assessment, situation assessment and decision support.

Figure 2-1: HEIMDALL high-level system view

In Figure 2-1 the architecture of a local unit (LU) is presented including the interfaces. The simulators shown in the centre upper part include simulators for fire, flood and landslide. Modules that are using the simulation results as input are shown below and are namely the risk assessment (RVA), the impact summary (IA) generation and decision support (DS). On the right-hand side everything needed for communication is shown. An information gateway (IG) connects the system via satellite communication (SatCom) or the commercial internet with a receiver application for smartphones for the FRs or the general public. For the federated architecture, the system can connect to a catalogue and provides the dedicated interface to other system instances. In the lower central part of the figure, the user role management module (UeRM) the graphical user interface (GUI) and the scenario management (SM) are illustrated. The overall interconnecting middleware is the Service Platform (SP) that orchestrates the whole system.

Integrated Service Platform (Local Unit)

Control Centre

Data Sources External Systems

Ground-based data

Aerial sensors

Space-based data

Data Sources

Services

Scenario Management

Modelling and Simulation

Risk and vulnerability assessment

Situation Assessment and

DSS

Data Sharing and Communication

First responders on the field

Population

Graphical User Interfaces

HEIMDALL [740689] D2.14

05/01/2021 11

Figure 2-2: Local unit architecure

2.2 Key system elements More specifically, here is a complete list of the HEIMDALL system components:

• Service Platform (more information is available in Deliverable D4.2 [5]

• User Role Management (more information is available in Deliverable D4.5 [6]).

• User interface (more information can be found in Deliverables D4.7 [7] and D4.9 [8]).

• Communication and information sharing services (Catalogue and interface to other instances in Deliverable D4.14 [9]).

• Information gateway and Satellite communications (more information is available in D4.17 [10]).

• HEIMDALL Data Sources o Earth Observation (more information can be found in Deliverable D5.2 [11]). o In-situ Sensors (aerial- and ground-based) (more information can be found in

Deliverable D5.5 [12]).

• Mobile application for the first responders (more information will be available in Deliverables D5.7 [13] and D5.8 [14]).

• External data sources and services (e.g., Copernicus services, resource management, weather forecasting, etc.) (more information is available in Deliverable D5.10 [15]).

• Simulators (more information is available in D5.13 [16]).

• Risk assessment (more information can be found in Deliverable D6.3 [17]).

• Impact summary generation (more information can be found in Deliverable D6.5 [17] and D6.8 [19]).

• Decision support (more information can be found in Deliverable D6.11 [20]).

• Scenario management (more information is available in Deliverable D6.15 [21]).

2.3 Integration and verification approach

HEIMDALL system integration As shown in the high-level architecture of Figure 2-2, the Service Platform (SP) acts as the central part of the Local Unit, interconnecting all system elements. This centralised (“star topology”) approach greatly facilitates integration; integrating a module in HEIMDALL means

HEIMDALL [740689] D2.14

05/01/2021 12

implementation of the necessary interfaces and connecting the module with the HEIMDALL system, i.e. connect it with the service platform (SP) as middleware and integrate the features in the graphical user interface (GUI) so that the output to be visualised and the module controlled by the user. There is no need to implement peer-to-peer interfaces connecting each system element with one another.

A second technical decision which further simplified integration is the adoption of HTTP REST (as communication protocol) and JSON (as data structure format) for most of the interfaces, as will also be described in Section 3 to follow. The partner developing the module which exposed the REST interface (server-side) initially provided a set of sample data along with the JSON schema to be followed, so that the implementation of the service consuming endpoint could start early. Following, a service mock-up was often used, to test the communication even before the service was ready. And, even after the initial connection in the early system releases, integration continued in an iterative matter, as the services further evolved and more and more API methods and features were added. In each iteration, a series of functional tests (defined by the developer of each module) were conducted to verify proper communication. This iteration resulted in four major system releases: A, B, C and Final.

To enable this continuous integration in HEIMDALL, the project adopted a distributed physical deployment of the system (see Figure 2-3). As seen, most of the system elements/modules are deployed in the premises of the partners developing them. The whole system is brought together using a hub-and-spoke Virtual Private Network (VPN) maintained by SPH. The VPN enables a virtual co-location of all modules, which are allowed to communicate as if they were in the same physical network. Communication takes part using state-of-the-art authentication and encryption methods.

HEIMDALL [740689] D2.14

05/01/2021 13

Figure 2-3: HEIMDALL system physical topology

As soon as even an early version of the module was made available, the module was connected to the VPN using client software installed in the physical -or virtual- compute node hosting the module.

The integration plan (schedule) was introduced in D2.1 and updated since then in D2.2-D2.5. Table 2-1 (part of the system engineering plan [1]) below shows in which system release the first version of each module was integrated in the overall system.

At the moment, the final versions of all the modules have been successfully integrated, apart from the satellite communications platform. Drone and satellite communication systems integration have been initially moved to the final release, since they are actually physical systems which were planned to be deployed in the field but this has been later dropped because of the COVID pandemic situation and the related restrictions. However, to ensure proper communication, a lab-based version of the drones system has been already interconnected with the SP and interoperability has been secured. As for the satellite communications platform, it was planned to provide network (Layer-3) level interconnection for the platforms in the field with commercial products, so its integration would not have any impact at application level – and thus does not require any specific software developments.

HEIMDALL [740689] D2.14

05/01/2021 14

Table 2-1: Integration plan

Module Release A Release B Release C

Final

GUI X

User and role management X

Service platform X

Earth observation X

Aerial based data X

Landslide monitors X

Crowdsourced and first responder’s data X

External systems X X X

Fire simulation X

Flood simulation X

Landslides X

Scenario management X

Risk and impact assessment products and workflows X

Impact summary X

Scenario matching X

Decision support X

Satellite communication X

Information gateway X

Catalogue X

Interface to other local units X

Integration testing and verification Following the integration of each version of the HEIMDALL modules into the system, a set of functional tests were run to verify interoperability (integration testing). An indicative subset of these functional tests is presented in Section 3 to follow, defined using the test case template shown in Table 2-2 below – which is an adaptation of the generic test case template used throughout the project.

Table 2-2: Test case template for integration tests

Test ID Unique test identifier in the format “TS_INT_#”

System elements whose integration is verified

• List of HEIMDALL modules

Test objective [Specific functionality which is verified]

HEIMDALL [740689] D2.14

05/01/2021 15

Test procedure

Detailed steps to be followed in order to perform the test in the form

1. The user …

2. The user…

3. …

Test prerequisites/ configuration

List of pre-requisites which are mandatory to be fulfilled before the test starts; in the form

• …

Success criteria [Conditions to be fulfilled for the test to be successful]

Success PASSED / NOT TESTED / FAILED

It must be noted that the test cases presented in the section to follow specifically focus on verifying the proper integration of the respective element of the HEIMDALL system. They are neither meant to illustrate the proper operation of each system element /module (which is the aim of the unit tests presented in the corresponding implementation deliverables [3]-[19]) nor to verify in an exhaustive manner all system features, which have already been presented in the other technical deliverables.

For most test cases, a screenshot of the GUI has been included as evidence of the respective information being properly delivered.

HEIMDALL [740689] D2.14

05/01/2021 16

3 Integration and testing

This section describes the way of integration/interconnection of each module in the HEIMDALL system and presents indicative integration tests which verify the proper integration and interoperability. It should be mentioned that verifications of each of the features is considered part of the modules development and the necessary test can be found in the dedicated deliverables.

3.1 GUI

Deployment and Integration The GUI has been deployed as a Docker1 container in a Rancher2 cluster hosted in SPH premises. There is one GUI instance per SP instance (five instances in total, corresponding to the five Local Units).

The GUI interfaces directly with the SP. The data format is JSON and BOSH (Bidirectional-streams Over Synchronous HTTP), the latter specifically for the chat session. Communication takes place over HTTP/REST and Websockets.

Integration tests The integration test below focuses on merely the login procedure in the GUI. With respect to the rest functionalities, since the aim of the GUI is to provide a human-friendly interface for retrieving and submitting information to and from the system element, the integration of the GUI is exhaustively covered by the tests presented in the next sections. Figure 3-1 presents the result illustrated at the GUI.

Table 3-1: Test case TS_INT_01

Test ID TS_INT_01


• GUI

• SP

Test objective Testing of the login procedure

Test procedure 1. The user accesses the GUI and enters their login credentials


• The user needs to be registered in the HEIMDALL system

Success criteria Login is successful and the username appears in the GUI

Success PASSED

1 https://www.docker.com/

2 https://rancher.com/

https://www.docker.com/

https://rancher.com/

HEIMDALL [740689] D2.14

05/01/2021 17

Figure 3-1: Successful login using the GUI

3.2 User and Role Management

Deployment and Integration The User and Role Management has been deployed as a separate process coupled with the SP, hosted in SPH premises. There is one UeRM instance per SP instance (five instances in total, corresponding to the five Local Units).

The UeRM interfaces directly with the SP. The data format is JSON and communication takes place over HTTP/REST.

Integration tests The UeRM integration test verifies the proper matching of the username and role. Figure 3-2 presents the result illustrated at the GUI.


Test ID TS_INT_02


• GUI

• SP

• UeRM

Test objective Testing of the role assignment

Test procedure 1. The user accesses the GUI and enters their login credentials

2. The user checks their assigned name and role in the GUI


• The user name and role need to be assigned in the UeRM

HEIMDALL [740689] D2.14

05/01/2021 18

Success criteria Login is successful and the correct name and role is displayed in the GUI

Success PASSED

Figure 3-2: User name and role properly displayed (top right)

3.3 Earth Observation

Deployment and Integration The Earth Observation processing submodule has been deployed as a Virtual Machine, hosted in UNISTRA, DLR and CTTC premises.

The EO module interfaces with the SP. The data is represented as shapefiles, and JSON is used for the image metadata. Communication takes place over FTP due to the volume of the images; the SP implements an FTP service to which images are pushed and eventually integrated in the map service.

Integration tests The EO integration test verifies the proper integration of the EO data in the SP. Figure 3-3 presents the result illustrated at the GUI.


Test ID TS_INT_03


• GUI

• SP

• EO processing modules

Test objective Testing of the EO data integration

Test procedure 1. A new satellite image is processed to retrieve the burnt area

HEIMDALL [740689] D2.14

05/01/2021 19

2. The product of the processing is pushed to the SP

3. The user logs in the GUI and accesses the data


• A satellite image from a recently burnt area needs to be fed to the SP from the EO module

Success criteria When the respective layer is activated in the GUI, the burnt area is properly displayed, correctly superimposed on the map.

Success PASSED

Figure 3-3: EO product properly displayed as a map layer

3.4 Aerial based data

Deployment and Integration The drones subsystem is meant to be physically deployed in the field. It communicates with the HEIMDALL VPN and eventually with the SP over a cellular (4G) or satellite network connection. For testing Wi-fi connection in lab was used.

The data are encoded in JSON and as binary encoded images. Communication is over HTTP/REST.

Integration tests The aim of the test is to access and visualise data from drones, as integrated in the Common Operational Picture (COP). Figure 3-4 presents the result illustrated at the GUI.


Test ID TS_INT_04


• GUI

• SP

• Drones subsystem

Test objective Testing of the integration of aerial based data

HEIMDALL [740689] D2.14

05/01/2021 20

Test procedure

1. A new image is captured from a drone

2. The image is published to the SP



• (None)

Success criteria

A notification should appear about the availability of new drone image data. The new image should appear georeferenced in the GUI (as point on the map). By clicking on it, the actual photo should appear.

Success PASSED

Figure 3-4: Data from drones

3.5 Landslide monitors

Deployment and Integration The landslide monitors are physically deployed in the field. The collected data are fed to the SP over the HEIMDALL VPN, using a standard Internet connection.

The data are formatted as JSON and communicated over HTTP/REST.

Integration tests The integration test aims at verifying the proper communication of sensor data to the SP and eventually to the GUI. Figure 3-5 presents the result illustrated at the GUI.


Test ID TS_INT_05


• GUI

• SP

• Landslide sensor network

HEIMDALL [740689] D2.14

05/01/2021 21

Test objective Testing of the sensor data integration

Test procedure 1. A series of data are captured by the sensors



• (none)

Success criteria The sensor data visualised in the GUI should match the sensor stimuli.

Success PASSED

Figure 3-5: Sensor data integration

3.6 Crowdsourced and First Responders data

Deployment and Integration The data from the crowd and the first responders are coming from the HEIMDALL mobile app, installed in the users’ devices (smartphones). The collected data are fed to the SP over the HEIMDALL VPN, using a standard (cellular, WiFi) Internet connection.

The data are formatted as JSON and communicated over HTTP/REST.

Integration tests The integration tests verify the proper inclusion of the FR data in the COP. Figure 3-6 presents the result illustrated at the GUI.


Test ID TS_INT_06


• GUI

• SP

• HEIMDALL app

HEIMDALL [740689] D2.14

05/01/2021 22

Test objective Testing of the FR data integration

Test procedure 1. A user captures an image with the mobile app and submits it.



• The HEIMDALL app needs to be installed in the users’ device and registered.

Success criteria The captured picture must appear in the GUI, properly time-stamped and geo-referenced.

Success PASSED

Figure 3-6: FR data integration

3.7 External Systems

Deployment and Integration These services are external to the HEIMDALL system. They are maintained by third parties, usually as cloud (Software-as-a-Service) services.

The data format is usually JSON and/or bitmap-encoded images (in various formats), depending on the service. Communication usually takes over HTTP/REST. The service is exposed by the third party, whereas the HEIMDALL SP acts as client, consuming the service (whereas for all other HEIMDALL modules the SP acts as server). In other cases, external data which are off-line and are not subject to frequent updates, are manually ingested by the SP, upon request.

Integration tests The integration tests verify the proper inclusion of third-party data in the COP. Here we focus on the weather forecast services and ELSUS data. Figure 3-7 and Figure 3-8 presents the result illustrated at the GUI.

HEIMDALL [740689] D2.14

05/01/2021 23


Test ID TS_INT_07


• GUI

• SP

• External meteo service

Test objective Testing of the integration of weather forecast data

Test procedure

1. The user logs into the GUI

2. The user accesses the current weather forecast


• (none)

Success criteria The displayed weather forecast must be complete and match the one accessed through the weather provider’s website.

Success PASSED

Figure 3-7: Weather forecast integration

In addition, Figure 3-8 below shows the result of the manual integration of external data off-line, in this case a part of the European Landslide Susceptibility Map (ELSUS).

HEIMDALL [740689] D2.14

05/01/2021 24

Figure 3-8: Integration of external data

3.8 Fire Simulation

Deployment and Integration The fire simulation service is deployed as a cloud service, maintained by TSYL. It connects to the SP over the Internet and the HEIMDALL VPN.

The data are encoded in JSON and communicated over HTTP/REST.

Integration tests The integration tests focus on the entire management of the simulation process, i.e. the triggering of the simulation over the HEIMDALL system and the visualisation of its results. Figure 3-9 presents how the user can trigger a fire simulation and Figure 3-10 presents the results.


Test ID TS_INT_08


• GUI

• SP

• Fire simulation service

Test objective Testing of the fire simulation triggering and retrieval of results

Test procedure


2. The user requests a simulation for an active scenario

3. The user is notified for the completion of the simulation and visualises the results.


• A scenario should have been created and made active

Success criteria

The visualisation of the simulation should be meaningful and consistent. The results are cross-checked with the internal data in the simulation service.

HEIMDALL [740689] D2.14

05/01/2021 25

Success PASSED

Figure 3-9: Triggering a new simulation

Figure 3-10: Wildfire simulation results

HEIMDALL [740689] D2.14

05/01/2021 26

3.9 Flood Simulation

Deployment and Integration The flood simulation service is deployed in a separate Virtual Machine, hosted by CIMA. It connects to the SP over the Internet and the HEIMDALL VPN. The data are encoded in JSON and communicated over HTTP/REST.

Integration tests The integration tests focus on the entire management of the simulation process, i.e. the triggering of the simulation over the HEIMDALL system and the visualisation of its results. Figure 3-11 presents how the user can trigger a flood simulation and Figure 3-12 presents the results.


Test ID TS_INT_09


• GUI

• SP

• Flood simulation service

Test objective Testing of the flood simulation triggering and retrieval of results

Test procedure





• A scenario should have been created and made active

Success criteria


Success PASSED

Figure 3-11: Flood simulation triggering

HEIMDALL [740689] D2.14

05/01/2021 27

Figure 3-12: Flood simulation results

3.10 Landslide modelling

Deployment and Integration The landslide modelling service is deployed in a separate Virtual Machine, hosted by ICGC. It connects to the SP over the Internet and the HEIMDALL VPN.


Integration tests The integration tests focus on the entire management of the simulation process, i.e. the triggering of the simulation over the HEIMDALL system and the visualisation of its results. Figure 3-13 presents how the user can trigger a fire simulation and Figure 3-14 presents the results.


Test ID TS_INT_10


• GUI

• SP

• Landslide modelling service

Test objective Testing of the landslide simulation triggering and retrieval of results

Test procedure





• A scenario should have been created and made active.

HEIMDALL [740689] D2.14

05/01/2021 28

Success criteria


Success PASSED

Figure 3-13: Landslide modelling triggering

Figure 3-14: Landslide modelling results

HEIMDALL [740689] D2.14

05/01/2021 29

3.11 Scenario Management

Deployment and Integration The scenario management service is deployed in a separate Virtual Machine, hosted by CIMA. It connects to the SP over the Internet and the HEIMDALL VPN.


Integration tests The integration tests focus on the creation, parametrisation, and access of a scenario. Figure 3-15, Figure 3-16 and Figure 3-17 present the results illustrated at the GUI.


Test ID TS_INT_11


• GUI

• SP

• Scenario management

Test objective Testing of the scenario management process from the GUI

Test procedure


2. The user creates a scenario and edits its parameters

3. The user verifies the stored scenario


• (none)

Success criteria The scenario parameters must be correct.

Success PASSED

Figure 3-15: Scenario management (1/3)

HEIMDALL [740689] D2.14

05/01/2021 30



3.12 Risk and Impact Assessment

Deployment and Integration The risk assessment service is deployed in a separate Virtual Machine, hosted by CIMA. The Impact Summary module is hosted by DLR. Both connect to the SP over the Internet and the HEIMDALL VPN.


HEIMDALL [740689] D2.14

05/01/2021 31

Integration tests The integration tests focus on the creation and visualisation of an impact assessment. Figure 3-18 and Figure 3-19 show the impact summary for wildfire and landslide cases, respectively.


Test ID TS_INT_12


• GUI

• SP

• Risk and Impact assessment


Test procedure


2. The user selects the active scenario or makes one of the available scenarios active

3. The user selects an AOI and requests an impact summary


• At least a scenario should exist and marked as active

• There should be at least one completed hazard simulation for that scenario

Success criteria The impact assessment must be meaningful, correspond to the AOI and consistent with the simulation results.

Success PASSED

Figure 3-18: Wildfire impact assessment

HEIMDALL [740689] D2.14

05/01/2021 32

Figure 3-19: Landslide impact assessment

3.13 Situation Report

Deployment and Integration The situation reporting service is deployed in a separate Virtual Machine, hosted by DLR. It connects to the SP over the Internet and the HEIMDALL VPN.

The output situation report is a EDXL-SitRep format and communicated over HTTP/REST to either the IG for first responders information to be displayed at the App or to MS Word docx.

Integration Tests The integration tests focus on the creation of a situation report. Figure 3-20 presents the resulting document.


Test ID TS_INT_13


• GUI

• SP

• Situation report module


Test procedure 1. The user logs into the GUI

2. The user requests a situation report for a specific scenario


• The incident must pre-exist in the SP

• There should be at least one completed hazard simulation for the active scenario, marked as candidate for the what-if analysis

• There should be at least one completed impact assessment for the what-if candidate simulation

Success criteria The downloaded document needs to be accessible and the contents must be consistent with the information in the GUI.

Success PASSED

HEIMDALL [740689] D2.14

05/01/2021 33

Figure 3-20: Situation report document

3.14 Scenario Matching

Deployment and Integration The scenario matching service is deployed in a separate Virtual Machine, hosted by DLR. It connects to the SP over the Internet and the HEIMDALL VPN.


Integration tests The integration tests focus on the query of a scenario with specific parameters. Figure 3-21 presents the results illustrated at the GUI.


Test ID TS_INT_14


• GUI

• SP

• Scenario matching

Test objective Testing of the scenario management query from the GUI

Test procedure


2. The user specifies the query parameters (e.g. hazard type, synoptic situation…) and weighted criteria

3. The user browses through the results and selects one of them to check the lessons learnt and other data contained


• The scenario database must be properly populated.

Success criteria The results must match the parameters specified.

Success PASSED

HEIMDALL [740689] D2.14

05/01/2021 34

Figure 3-21: Scenario matching

3.15 Decision Support

Deployment and Integration The decision support service is deployed in a separate Virtual Machine, hosted by DLR. It connects to the SP over the Internet and the HEIMDALL VPN.


Integration tests The integration tests focus on the query of a scenario with specific parameters. Figure 3-22 presents the results illustrated at the GUI.


Test ID TS_INT_15


• GUI

• SP

• Decision Support service

Test objective Testing of the DSS functionality from the GUI

Test procedure


2. The user requests decision support for a specific scenario

3. The results are displayed


• Incident information must pre-exist.

• There should be at least one completed hazard simulation for that scenario

Success criteria The DSS results must be meaningful, taking into account the parameters of the incident.

Success PASSED

HEIMDALL [740689] D2.14

05/01/2021 35

Figure 3-22: Decision support

3.16 SatCom

Deployment and Integration The satellite communications terminal and antenna was planned to be deployed in the field by AVA and is meant to provide Internet connectivity in cases where terrestrial network is not available. The SatCom infrastructure would essentially enable connectivity at the network layer of the protocol stack (namely IP protocol layer), allowing all application protocols to be transported accordingly.

The integration did not take place because of the restrictions due to the COVID pandemic situation, which made the installation of satellite terminal onsite not possible or in any case risky.

Integration tests The integration test will essentially verify connectivity to the HEIMDALL system over satellite.


Test ID TS_INT_16


• SP

• SatCom

Test objective Testing of the HEIMDALL network access

Test procedure

1. The user attaches an access unit (laptop, tablet, smartphone) to the LAN side of the satellite terminal

2. The user connects to the HEIMDALL VPN and accesses the GUI using a browser.

3. The user tests the connection to all needed HEIMDALL services (by ICMP and/or HTTP requests to the respective hosts/services)

HEIMDALL [740689] D2.14

05/01/2021 36


• Satellite connectivity must have been established.

Success criteria The GUI must be accessible and fully functional. All needed HEIMDALL services must be accessible.

Success NOT TESTED

3.17 Information Gateway

Deployment and Integration The Information Gateway service is deployed in a separate Virtual Machine, hosted by DLR. It connects to the SP over the Internet and the HEIMDALL VPN.


Integration tests The integration tests focus on the creation of an alert message with specific parameters. Figure 3-23 presents the results illustrated at the GUI.


Test ID TS_INT_17


• GUI

• SP

• Information Gateway

Test objective Testing of the alert feature from the GUI

Test procedure


2. The user composes an alert and selects the audience to whom the alert is issued


• A scenario should be activated

Success criteria The contents of the alert must match the parameters specified.

Success PASSED

HEIMDALL [740689] D2.14

05/01/2021 37

Figure 3-23: Alert message editing

3.18 Catalogue

Deployment and Integration The Catalogue service is deployed in a separate Virtual Machine, hosted by DLR. It connects to the SP over the Internet and the HEIMDALL VPN.


Integration tests The integration tests focus on browsing of the Catalogue products. Figure 3-24 present the results illustrated at the GUI.


Test ID TS_INT_18


• GUI

• SP

• Catalogue

Test objective Access to the Catalogue products from the GUI

Test procedure


2. The user subscribes for specific products in the Catalogue


• The Catalogue needs to be sufficiently populated.

Success criteria

The results must match the actually published products. The GUI notifies the user whenever there is a new matched product corresponding to the subscription preferences.

Success PASSED

HEIMDALL [740689] D2.14

05/01/2021 38

Figure 3-24: Browsing Catalogue products

HEIMDALL [740689] D2.14

05/01/2021 39

4 Conclusion

This document provided an overview of the activity of system-wide integration and validation of the HEIMDALL system. Apart from the SatCom subsystem, which will be deployed in the field during the final demo, all HEIMDALL modules have been interconnected and fully interoperable with one another.

The HEIMDALL system is fully operational. Minor issues, if any, will be addressed to ensure proper operation during the project final demo under all planned scenarios.

HEIMDALL [740689] D2.14

05/01/2021 40

5 References

[1] B. Barth et al., HEIMDALL D2.5: “ System Engineering Report Issue 5”, 12.2020

[2] Barth, B., et al. (2020). HEIMDALL D2.9: HEIMDALL Requirements Report – Issue 4

[3] Mulero Chaves, J. et al. (2018). HEIMDALL D2.12: HEIMDALL System Architecture

[4] Pantasis, S., et al. (2020) HEIMDALL D2.13: HEIMDALL Integrated System

[5] Pantazis, S. et al. (2020) HEIMDALL D4.2: Service Platform Design and Specification - Final

[6] Pantazis, S. et al. (2020) HEIMDALL D4.5: Users and Roles Management Specifications – Final

[7] Mathew, D. et al. (2018) HEIMDALL D4.7: User Interface Design –Draft

[8] Mathew, D. et al. (2018) HEIMDALL D4.9: User interfaces – Draft

[9] Barth, B. et al. (2020) HEIMDALL D4.14: Communications and Information Sharing – Final

[10] (2020) HEIMDALL D4.17: Communications to Remote Areas – Design and Specifications – Final

[11] Friedemann, M. et al. (2020) HEIMDALL D5.2: EO Tools and Products – Specifications – Draft

[12] Luzi, G. et al. (2020) HEIMDALL D5.5: In-Situ Sensors – Specifications – Draft

[13] To be released on M38 (2020) HEIMDALL D5.7: First Responders Data Module Design

[14] To be released on M38 (2020) HEIMDALL D5.8: Smartphone/Tablet Device Application for First Responders

[15] Pantazis, S., et al, (2020) HEIMDALL D5.10: Interfaces for External and Existing Systems – Specifications – Final

[16] Mendes, M. et al, (2020) HEIMDALL D5.13: Modelling and Simulation Services – Specifications – Final

[17] Friedemann, M. et al. (2020) HEIMDALL D6.3: Validated Risk Analysis and Emergency Response Methods which have been Coordinated with Product Development – Final

[18] Mendes, M. et al. (2020) HEIMDALL D6.5: Concept on Hazard, Scale and User-Specific Risk Assessment Information, Products and Service Workflows - Final

[19] Friedemann, M. et al. (2020) HEIMDALL D6.8: Situation Assessment, Impact Summary Generation and sCOP/SITREP Specification and Implementation Report – Final

[20] Friedemann, M. et al. (2020) HEIMDALL D6.11: Decision Support Specification and Implementation Report - Final

[21] Friedemann, M. et al. (2020) HEIMDALL D6.15: Scenario Specification, Scenario Management Specification and Scenario and Situation Metrics – Final

HEIMDALL [740689] D2.14

05/01/2021 41

End of document

Date post:	09-Mar-2021
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

D2.14 HEIMDALL Integration and Verification...

Documents