Interoperability Profiles for Command/Control Systems and Sensor Systems in Emergency Management

Informacje na temat projektu

C2-SENSE

Identyfikator umowy o grant: 607729

Projekt został zamknięty

Data rozpoczęcia 1 Kwietnia 2014

Data zakończenia 30 Września 2017

Finansowanie w ramach

• Specific Programme "Cooperation": Security

Koszt całkowity € 4 323 658,00

Wkład UE € 2 885 416,00

Koordynowany przez

SAFRAN ELECTRONICS & DEFENSE
France

Final Report Summary - C2-SENSE (Interoperability Profiles for Command/Control Systems and Sensor Systems in Emergency Management)

Executive Summary:
1.1.1. Project context and objectives
Effective management of emergencies, crises and disasters depends on timely information availability, reliability and intelligibility. To achieve this, many different organizations, with different Command and Control (C2) Systems and Sensor Systems have to cooperate. This cooperation requires interoperability.
Unless standards and well-defined specifications are used, the interoperability of these systems can be quite challenging, technologically complex, time-consuming and expensive.
To address this challenge, in C2-SENSE Project, a “Profiling” approach has been used to achieve seamless interoperability by addressing all the layers of the communication stack in the security field. In this respect, C2-SENSE project's main objective was to develop a profile based Emergency Interoperability Framework that uses existing standards and semantically enriched Web services to expose the functionalities of C2 Systems, Sensor Systems and other emergency/crisis management systems.
This has been developed in three steps:
(1) first, an Emergency Domain Inventory has been created by surveying existing standards, real-life use cases of sensors, devices, C2 systems and emergency management architectures for different scenarios in the security field.
(2) Based on this inventory, a common Emergency Domain Ontology has been developed to gather all stakeholders' knowledge in a unique and flexible data model.
(3) Finally, by using the concepts in this ontology, by also taking into account both functional and operational requirements as well as different countries' cultural, linguistic and legal issues, Emergency Interoperability Profiles that constitute the framework has been developed.

Interoperability Stack of the C2-SENSE Project
The necessary standardization activities have been initiated to evolve C2-SENSE Emergency Interoperability Framework into a standard specification for interoperability of Sensor Systems and C2 Systems. C2-SENSE has assessed its outcomes in a realistic “Flood Scenario in Italy” pilot to ensure that the developed technologies are generic and applicable in a real-life setting.

Project Context and Objectives:
1.2. Summary description of project and objectivesC2-SENSE objectives:
Main objectives can be summarized as follow:
• O1: Propose an interoperability framework for heterogeneous networks composed of sensors and control centres via protocol profiles for crisis management and a service-oriented architecture (achieved)
• O2: Demonstrate the framework concept (achieved through the pilot application)
• O3: Propose standards (for the interoperability and interoperability certification methodology) (partially achieved)
The demonstration has been executed on May the 4th 2017 in Bari (Italy) and hosted by Regione Puglia department of Civil Protection. Several stakeholders, representing local authorities, took an active part in the execution of the Pilot Application. All attendees participated in a discussion and answered the C2-SENSE questionnaire, indicating if the C2-SENSE is usable and what it should be improved in order to turn C2-SENSE results into a product.
1.2.2. How C2-SENSE works and how it could be a help for the future:
The aim of C2-SENSE’s framework is to provide a proof-of-concept demonstrating how to improve interoperability by using the Profiles that we have developed and also how to validate the conformity of the different systems to the ‘contract’ that is defined in such Profiles. C2-SENSE’s profiling approach strives to provide an effective way of defining communication workflows and assuring that such rules are automatically enforced in a crisis situation. This is achieved by connecting all the relevant information systems, including the legacy systems, to a common information space and defining the workflows through Profiles. The C2-SENSE framework then uses the information from the Profiles to automatically translate the data models and route the information flows as needed. As a result, some of our tools are strongly coupled with the Profiles and cannot be easily replaced by any of the existing systems, as they directly use Profiles as input or as output.
The C2-SENSE framework is composed of several modules that are working together and are completely tunable and adaptable, according to the needs of the specific environment or scenario. Policies and the way the tool works should be introduced gradually and temporarily used in parallel with existing tools, aiming at a gradual and effective deployment in the real environment. Because of the integration with modern technologies, operators will find it easy to interact with the framework and receive immediate and consistent help in the critical decision-making phase. Emergency operators can then exploit the flexibility of the communication system and the integration of modern communication systems to improve responsiveness and the ‘enter into action’ activities.
The framework includes an enterprise service bus (ESB), and a set of Legacy Application Representatives (LARs). These components allow the connection of various end-user systems and ensure that vital information is transformed as needed and delivered to different systems and organisations, as defined in a Profile. Even if no other C2-SENSE elements were used, the use of ESB and LARs would certainly improve the communication between different stakeholders and organisations by making it more difficult to make mistakes. Likewise, the Emergency Map component goes beyond the state of the art in terms of configurability and multilingual support and allows easy exchange of standardised messages in heterogeneous and multilingual teams. As the project targets all the levels of the Interoperability Stack, different emergency responders and managers require different Profiles. For example, an Alert Profile can be used to define who can initiate the alerts and who needs to be alerted, depending on the type and parameters of alert. On a more generic level, the Emergency Interoperability Profiles are categorised in “Physical”, “Technical” and “Organisational” Profiles. Organisational Interoperability Profiles support the efficient exchange of information and data between different organisations at the level of organisation, whereas Technical Interoperability Profiles formalise the contract between the different services and their interfaces and enforce workflows at a software level. Organisational Interoperability Profiles are particularly helpful in cross-border and international relief operations where different languages can form a barrier to communication. Technical Interoperability Profiles, which are substantially more complex to design, can also be used to automatically generate or configure software, as well as validate the conformity of the systems to Profiles. Finally, the Physical Interoperability Profiles describe the near-hardware configuration parameters of physical systems (e.g. sensor configuration data).
C2-SENSE offers tools that simplify profile generation and also working towards using the Profiles for automated generation of the software or automated configuration of the software in a system. Profile generation is supported by the Profile Definition and Specialization Tool and the conformance validation by the TestBATN testbed. This testbed was successfully used in eHealth and other domains prior to C2-SENSE and adapted by SRDC for use in the emergency management domain.
Sharing of knowledge between the actors involved in the crisis management is made difficult by the variety of incompatible standards that are already used in different organisations. The focus of C2-SENSE is on supporting cross-organisational interoperability, at all levels of command. This is achieved through seamless and automated mapping between such standards. Sharing the project results is important for the team and they have a number of dissemination activities in place that underline C2-SENSE’s main aspects and key achievements. Partners have attended several conferences and workshops. Academic partners (AIT, PIAP, SRDC) were particularly active and participated in conferences and workshops from 2015 to 2017. Among more than 30 conferences and workshops we can mention IWEI20A5, OGC2015, ISESS2015, I-ESA2016, ISESS2017, OASIS 2017. At a national level, partners have participated in meetings with emergency associations and public and governmental entities, taking the chance to distribute advertising materials and informing candidate stakeholders about the current activities and possible exploitation and collaboration activities they may be interested in.
The team’s focus for the end of the project was to initiate the standardisation of the Emergency Interoperability Profiles by running a test pilot in the region of Puglia, Italy. C2-SENSE’s work helps crisis situations come alive on maps through streams of real-time data, aiding the decision-makers and supporting an improved response. After a training of the stakeholders in order to understand how C2-SENSE works, stakeholders could see the benefits of C2-SENSE and a report has been issued including improvement that could be done to get a product.
Ultimately, all have been convinced whether a crisis is national or international, improved interoperability and communication can only be beneficial.

1.3. A description of the main S&T results/foregrounds
1.3.1. Architecture
C2-SENSE Emergency Interoperability Framework has been initially designed as a Service Oriented system where all software components communicate using SOAP and the service orchestration is supported by dedicated framework service. In the course of the project, we have realised that the crisis management work is message-centric in nature and re-designed the framework as an event-based system, where all the framework elements are connected by an Enterprise Service Bus. This has resulted in some communication and messaging abstractions – most notably in the form of the Web Services protocol (enriched with relevant protocol adapters) and the use of the ESB technology, as a key middleware component for everything related to messaging and messaging analysis.
The functionalities of the individual framework components pertaining to different interoperability layers are illustrated in Figure 1.

Figure 1: C2-SENSE Framework
Starting with the (lowest) Physical Interoperability layer, the IP based gateway supports the near-hardware integration of the external components to the C2-SENSE framework and manages the physical connections between the networked applications and devices. A similar function is provided, specifically for sensors, by the AnySen adapter. Adapters from the Protocol Interoperability Layer support protocol-level integration of the legacy software systems and manage the end-to-end delivery of messages and documents.
Components from the Data/Object Model Interoperability Layer and the Semantic Information Interoperability Layer pick up from here and provide the necessary syntactic and semantic mapping of the messages exchanged. Components from the Knowledge Layer manage the creation of a common operational picture of the crisis situation and support the cross-organizational collaboration for joint decision making. Finally, the components from the Aligned Procedures and Operations Layer provide support for aligning the emergency procedures and operations and reaching of agreements between the organisations involved.
For end users and integrators, the software components from the Semantic, Data/Model and Protocol interoperability are never used stand alone. Instead, they merge into intelligent connectors, so-called Legacy Application Representatives (LARs). LARs are generated by Web Service Creator Tool and facilitate the connection between the C2-SENSE system and end-user systems. LARs handle this connection and provides communication among systems through an Enterprise Service Bus (ESB), which is not explicitly shown in the figure. Resulting simplified functional architecture of the C2-SENSE Emergency Interoperability Framework is shown in Figure 2.

Figure 2 C2-SENSE Framework in a higher level

1.3.2. Description of profiling approach
Interoperability is the ability of two or more systems to exchange data and to mutually understand the information which has been exchanged. In emergency management, different Command and Control (C2) Systems and Sensor Systems need to exchange information with each other for the effective management of disasters. Without standards and well-defined specifications, however, the interoperability of these systems can be quite challenging, technologically complex, time-consuming and therefore expensive. Although there are some commonly used standards and specifications in command and control, sensor and disaster management domains, there is no single specification on how to use these standards together when disparate systems need to interoperate. How can (disparate) systems (and users) exchange data, how can they communicate, and which rules should they follow? In other words, how is the challenge of lack of this crucial interoperability properly addressed? In order to solve this problem, in C2-SENSE, we provided the solution by using the profiling approach.
Profiling is a practical approach to achieve seamless interoperability among disparate systems. The profile concept aims to eliminate the need for a prior bilateral agreement between partners in an information exchange network by defining a standard set of messages/documents, choreographies, business rules and constraints. The profile compliant partners are able to exchange information and services among themselves. This means that when a new exchange partner joins the network, there is no need for an agreement as long as it conforms to a predefined profile. Considering the nature of disaster management, in which the responding organizations can change at runtime (especially during international intervention cases), these generic profiles provide much-needed coordination flexibility in order to deal with the unexpected circumstances and prevent a chaotic response.
Profiling has already been successfully used in domains such as eHealth through “Integrating the Healthcare Enterprise Profiles” and eProcurement through “CEN BII Profiles”. The conventional profiling approach addresses only the first three layers of the Interoperability Stack: the “Communication Layer” covers the transport and communication layer protocols; the “Document Layer” addresses the content format of the messages and documents exchanged among the applications, and the “Business Process Layer” addresses the choreography of the activities to be executed by the participants. For emergency management applications, on the other hand, organizational aspects such as policies, procedures, operations and strategies are no less important than technical aspects of interoperability. Hence, the profiling approach introduced in C2-SENSE addresses all the layers of the Interoperability Stack shown below. For each layer, all necessary messages/documents, choreographies, business rules or constraints are specified.

Based on the technical and organizational requirements, the profiles (C2-SENSE Emergency Interoperability Profiles) that were defined in the C2-SENSE project are grouped into three categories:
• Technical Interoperability Profiles
• Physical Interoperability Profiles
• Organizational Interoperability Profiles
Technical Interoperability is associated with hardware/software components, systems and platforms that enable machine-to-machine communication to take place. This kind of interoperability is often centred on (communication) protocols and the infrastructure needed for those protocols to operate. In this regard, Technical Interoperability Profiles are defined as technical specifications that enable information exchange among systems/platforms in a standard way. They concern about Protocol, Data/Object Model, Information and Knowledge Interoperability layers. In C2-SENSE 15 Technical Interoperability Profiles are defined. The list of Technical Interoperability Profiles with their brief description and link to full profile description online are presented in the following table.
Profile Description Online Link
Alert The Alert profile describes how alerts and notifications can be represented digitally and exchanged among all kinds of emergency information systems. It describes a series of activities for the exchange of effective public warning messages. https://service.ait.ac.at/c2-sense/content/alert

Audit Trail and Node Authentication (ATNA) Audit Trail and Node Authentication profiles describe the security environment assumed for the node such as user identification, authentication, authorization, access control etc. It establishes security measures to provide information confidentiality, data integrity and user accountability. https://service.ait.ac.at/c2-sense/content/audit-trail-and-node-authentication

Emergency Situation Map Emergency Situation Map profile describes how a user/organization is provided with a common operational picture of the emergency area using a real-time data and geographical maps. It describes how to get the data, maps and mash-ups. https://service.ait.ac.at/c2-sense/content/emergency-situation-map

Hospital Communication Hospital Communication profile describes how hospitals can communicate with each other and with other members of the emergency management team about the status, services and resources of the hospital. These include bed capacity and availability, emergency department status, available service coverage, and the status of hospital’s facility and operations. https://service.ait.ac.at/c2-sense/content/hospital-communication

Human to Human communication (H2H) This profile will be used to exchange any information that cannot be exchanged through any of the Interoperability Profiles. https://service.ait.ac.at/c2-sense/content/human-human-communication

Mission Plan Mission Plan profile describes which organization will perform which action in the event of an emergency according to country’s emergency plan and organizational structure. The mission plan is generated and distributed by the competent authority who is in charge of managing the emergency situation. https://service.ait.ac.at/c2-sense/content/mission-plan

Permission Permission profile describes how an organization (requester) can ask for permission to perform some specific action from an organization (responder) who is authorized to respond to the permission request. Responder can either give permission or decline it. https://service.ait.ac.at/c2-sense/content/permission

Resource Management Resource Management profile describes how organizations (resource consumer and resource supplier) can communicate about the allocation of resources across the emergency incident life-cycle. This includes preparedness, pre-staging of resources, initial and on-going response, recovery and demobilization/release of resources. https://service.ait.ac.at/c2-sense/content/resource-management

Scheduling Scheduling profile describes in which order the actions in the mission plan will be performed. It will be used in conjunction with Mission Plan Profile. https://service.ait.ac.at/c2-sense/content/scheduling

Sensor Management Sensor Management profile describes how organizations can configure sensors to gain observations from areas of interest. This is important across the whole emergency incident life-cycle, including preparedness, pre-staging of sensors, initial and on-going response, recovery and demobilization/release of sensors. https://service.ait.ac.at/c2-sense/content/sensor-management

Sensor Measurement Sensor Measurement profile describes how sensors transmit their measurements to the C2 Systems, where organizations can analyze the observations. This is important across the whole emergency incident life-cycle, including preparedness, initial and on-going response, recovery and demobilization/release of sensors. https://service.ait.ac.at/c2-sense/content/sensor-measurement

Situation Analysis Situation Analysis profile describes how a user or an organization is provided with a possibility to simulate the situation on the ground for a given set of data. The profile describes how to get the data, maps, mash-ups and simulation results. https://service.ait.ac.at/c2-sense/content/situation-analysis

Situation Reporting Situation Reporting profile describes how an organization (sender) can send situational reports to another one (receiver). It describes a series of activities for the transmission of timely available situational reports https://service.ait.ac.at/c2-sense/content/situation-reporting

Tracking of Citizens Tracking of Citizens profile describes how organizations can exchange emergency citizen and tracking information during evacuation or patient encounter through admission or release. It supports citizen tracking across the emergency medical services, as well as hospital evacuations and patient transfers, providing real-time information to responders, emergency management, coordinating organizations and care facilities in the chain of care and transport. https://service.ait.ac.at/c2-sense/content/tracking-citizens

User Authentication and Authorization (UAA) User Authentication and Authorization defines a means to establish one name per user that can then be used on all of the devices and software that participate in this integration profile. It greatly facilitates centralized user authentication management and provides users with the convenience and speed of a single sign-on. https://service.ait.ac.at/c2-sense/content/user-authentication-and-authorization


Data models and protocols relevant for each of the profiles are shown in the table below.
Profile Data/Object Model(s) Protocol
Alert EDXL CAP SOAP
Audit Trail and Node Authentication (ATNA) Proprietary based on RFC-3881 REST
Emergency Situation Map OGC WMS and OGC WFS SOAP
Hospital Communication EDXL HAVE SOAP
Human to Human Communication (H2H) Proprietary based on EDXL SOAP
Mission Plan Proprietary based on EDXL SOAP
Permission Proprietary based on EDXL SOAP
Resource Management EDXL RM SOAP
Scheduling Proprietary based on EDXL SOAP
Sensor Management OGC SWE SOAP
Sensor Measurement OGC SWE SOAP
Situation Analysis OGC WPS SOAP
Situation Reporting EDXL SitRep SOAP
Tracking of Citizens Proprietary based on EDXL TEP SOAP
User Authentication and Authorization (UAA) Proprietary and XACML REST

Physical Interoperability Profiles are the main part of Physical Interoperability Layer. They contain data and information about physical connection with the communication medium and specify the data acquisition procedure. Physical Interoperability Profiles match the interoperability definition and can successfully be used in Physical Interoperability Layer, as they allow connection of a large variety of devices with specified interface and protocol to systems such as C2-SENSE Framework.
Physical Interoperability Profiles are based on the XML data format. Its structure is universal for all the profiles. Universal structure of physical profile includes all important information about device and data to be collected from the communication medium. The profile is strictly adapted to the physical interface and protocol. Information included in proper field (for example communication specification) are unlimited, so basically every detail of configuration can be specified in the profile. In C2-SENSE, 3 Physical Interoperability Profiles have been developed and tested:
• GPRS modem, connected to the PC with RS232 interface and MODBUS RTU protocol
• Device for electrical parameters measurement
• 866MHz or 433 MHz Radio Transceivers
In these above-described cases, three adapters are created automatically and they are in charge of following readings:
• Adapter 1 (GPRS) – two temperature measurements, two relative humidity measurements, two rainfall measurements.
• Adapter 2 (Power meter) – Network voltage, network frequency, THD (Total Harmonic Distortion).
• Adapter 3 (Radio) – three temperature measurements, three relative humidity measurements.
Detailed technical information about Physical Interoperability Profiles are available at https://service.ait.ac.at/c2-sense/content/physical-profiles
Organizational Interoperability Profiles cover Aligned Operations and Procedures and Harmonized Strategy/Doctrines layers. They concern about cooperation among organizations at procedural or operational level. C2-SENSE Organizational Interoperability Profile template enables any organization involved in the crisis management to prepare and write new inter-organization agreements, which describe the nature of cooperation in everyday operations among them. The template is aligned with relevant international standard recommendations and applicable to all types and sizes of organizations that wish to prepare, maintain or improve their inter-organization partnering agreement and demonstrate conformity to other organization when arranging the initial dialogue with potential partners.
In C2-SENSE, two organizational profiles have been provided:
• Organizational profile for establishing partnering agreement
• Organizational profile for reviewing existing partnering agreements
The first profile provides a guideline on how to prepare and establish partnering arrangements, which are aligned to “ISO 22397:2014: Societal security – Guidelines for establishing partnering arrangements” and “ISO 22301:2012: Societal security – Business continuity management systems – Requirements”; while the second one enables organizations to make an audit of their agreements and review the conformity with aforementioned standards. Further information can be found at https://service.ait.ac.at/c2-sense/content/organisational-interoperability-profiles.
1.3.3. Technical interoperability and software development
The Physical layer, Protocol layer, Data/Object Model layer, Information layer and Knowledge layer relate to “Technical Interoperability” between software systems of the different organisations. Most of the C2-SENSE framework components are situated in the technical interoperability layers. Likewise, the tests and demonstration at the “demo day” on the 4th of May, 2017 at Bari (Puglia region, Italy) concentrated at testing the technical interoperability support of the C2-SENSE framework. The functions and elements that are pertinent to these five interoperability layers are described hereafter.
Physical Interoperability
The “Physical Interoperability” layer manages the physical connections between the networked applications and devices. Some generic physical interoperability profiles have been developed for implementing the most popular interfaces and protocols.
Because we made choice of IP exchanges inside of our C2-SENSE system, we had to develop an IP based Gateway (IPGW) to enable the exchange of data using prominent wired and wireless communication mediums generating dependent adapters on the basis of the physical profiles. This provides universal communication service over a heterogeneous physical network, even for the devices and applications that usually do not use TCP/IP or UDP/IP protocols, and allows us to physically interconnect external application or networks with C2-SENSE.
Main results of our work are relative to the IP Gateway (PIAP) with the physical interoperability profiles, and the sensor protocol interface AnySen (AIT), accompanied with Sensor Configuration and Sensor Measurements profile.
Physical layer has been customized to meet the Regione Puglia infrastructure requirements. It is based on multiple measurement points (nodes) communicating with IP Gateway. Then, it forwards the data to the base station. In Regione Puglia, it was possible to use GSM/GPRS and radio for the communication, and FTP to obtain data from the existing Puglia network.
The underlying idea of AnySen is to interface (m)any sensor(s) without the need for adapting and recompiling the software. This had been achieved by creating a highly flexible sensor protocol interface, which allows for the description of the sensor protocol with configuration files. AnySen only exposes high-level parameters (e.g. sampling rate) to users of the C2-SENSE framework (i.e. crisis manager), as defined in the “Sensor Configuration Profile”.
For the C2-SENSE project, AnySen has been refined to reach a high level of maturity in industrial projects, which proved the concept of a generic sensor driver, so that over 25 types of sensors could be integrated into a data acquisition system.
However, even though AnySen does support many sensor types, it did not support many platforms, because it was coded in C/C++. In order solve this problem, the driver was modernized and ported to Java in the C2-SENSE project.
Protocol Interoperability
The objective was to achieve the protocol interoperability of emergency applications/systems and sensors using heterogeneous protocols. In this respect, “Protocol interoperability” addresses the transport level protocols such as TCP/IP, HTTP, SOAP , REST or SMTP and is in charge of end-to-end delivery of messages.
Some different data format has been handled by the C2-SENSE system (XML, JSON, CSV, XLS) with different protocols (HTTP, SOAP, SMTP) and the said data integrators have been developed.
We used Web service protocols for the protocol interoperability layer by exposing the proprietary services of emergency applications and organizations as “Web services”.
Two protocol interoperability profiles have been defined, and the corresponding Protocol Adapters implemented: (1) Sensor Protocol Adapter and (2) Emergency Applications/Systems Protocol Adapter.
SAFRAN studied the feasibility and design of the legacy systems protocol adapters.
Communication among the components and services was based on the Enterprise Service Bus (ESB), which is developed by LUTECH.
Two software components have been implemented:
• Component Legacy Applications Protocol Adapters (SAFRAN) – The protocol adapter framework lets C2-SENSE systems exchange data with legacy applications that do not comply with protocols defined for C2-SENSE, as presented in Figure 3.


Adapters Protocol & Organization concerned in C2Sense demonstrator
CAP/RSS RSS/ATOM & CAP
Fire Brigade
E-mailer SMTP
Prefecture
TRBoNet TCP/Proprietary
Volunteers
AOL ActOnline proprietary
Municipality
Facebook Facebook
Information to population
Twitter Twitter
Information to population
Figure 3 : Protocol adapters versus organization (Legacy application)

• Component Enterprise Service Bus (Lutech) – The C2SESB component simplifies, through its WS-compliant interface, the interactions (i.e. messages exchange and delivery) between generic systems and the C2-SENSE service bus (see Figure 4)


Figure 4: C2-SENSE architecture with Legacy Applications Representatives and ESB
Data/Object Model Interoperability
Data/Object Model Interoperability Layer involves using the relevant content standards. Common standard interfaces allow data communication among the disparate systems.
The C2-SENSE consortium agreed that it would not be pertinent to have a standardized unique central data model to be imposed on every actor. Modern operability is more based on semantic mediation. For that reason, our data model has been message based and relied on existing standards like EDXL and OGC ones.
In the C2-SENSE Project, the functionality of applications has been exposed as Web services whose interfaces will conform to the related standards.
Thus, the goal was to define the data/object model and to develop the Web Service Creator Tool (WSCT) and the Data Integrator (DI); WSCT was used for building applications from defined profiles and protocol adapters, and DI was used by WSCT to integrate and translate messages at the syntactic level.
We developed a Web Service Creator Tool (WSCT) to generate “Legacy Application Representatives” (LARs) as web applications (also called web services). These LARs embed protocol adapters and expose web services conforming to C2-SENSE standards. They call the Data Integrator (Lutech) and/or the Semantic Interoperability Suite (SRDC) for message translation (syntactic and semantic interoperability).
Information Interoperability
Information Interoperability layer is about mapping dynamic information to each other. The goal was to develop information interoperability profiles as well as semantic mediation mechanisms to be able to harmonize information conforming to different but overlapping emergency standards.
The main steps of our development were:
• Develop Information Interoperability Profiles – Fifteen interoperability profiles with their full description have been defined,
• Explicate the semantics of different but overlapping electronic standards as ontologies,
• Provide semantic mediation among these ontologies,
• Describe the business and operational properties of services through the Universal Service Description Language (USDL),
• Develop Semantic Interoperability Suite.
Semantic Interoperability Suite has been defined through the three components, which have been studied and developed during the C2-Sense project by SRDC:
• Emergency Ontology Creator Tool
• Mapping Generator Tool,
• Semantic Mediator
Knowledge Interoperability
The goal was to establish a common operational picture of the crises situation and to provide support of collaboration for joint decision making. That has been done through the “Knowledge layer” in the C2-SENSE architecture. There were several tools to be developed in order to provide the functionality:
• Collaboration Environment - AIT
• Emergency Maps Tool (EMT) - AIT
• Sensor Management Tool – AIT
• Messaging/Communication Platform - LUTECH
• Registry of Emergency Web Services - PIAP
• Profile Monitoring Tool - SRDC
• Profile Definition Tool - SRDC
• Security and Privacy Tool - SRDC
• Profile Repository – PIAP
• LimitChecker – AIT
• Object of Interest (OOI) Repository - AIT
• GIS Server (depreciated) – AIT

All of these tools have been developed and participated in the integration environment provided by LUTECH.

1.3.4. Organizational Interoperability
Organizational interoperability is concerned with modelling business processes and helping these processes to cooperate and bringing about the collaboration of administrations that wish to exchange information and may have different internal structures and processes. Therefore it addresses the top four layers in the Interoperability Stack Aligned Procedures, Aligned Operations, Harmonized Strategy/Doctrines and High Level/Political Objectives. Organisational interoperability support in C2-SENSE consist of:
1) Harmonization of emergency organizations process with Service Level Agreements and Organizational Level Agreements support, with two main sub-topics:
• Service Level Agreement Specifications
o A survey/analysis of pre-existing standardization efforts in the digital SLA / OLA context, with a specific focus on the WS-agreement specification
• SLA / OLA Templates
o Ad-hoc documental templates have been created for the sake of simplifying the redaction of actual SLAs / OLAs documents between the organisations
These functions are supported by three software components:
• Component Profile Specialization Tool (PST)
o A business process modeller capable to describe the (business process) interactions between the C2-SENSE actors both visually and with BPMN-compliant descriptors
• Component Process Execution Engine (PEE)
o A BPMN executor integrated with the C2-SENSE environment, specifically targeted at the execution of the PST-generated profiles
• Component Service Level Agreement Negotiation Tool (SLANT)
o A digital catalogue for storing and activating Service Level Agreements; once a specific SLA is activated, SLANT can execute (external) enforcement processes should any SLA issues occur
2) Harmonized Strategy Doctrines and High-Level Objectives.
The most research activity was done to examine the public available deliverables of projects that are listed in EU Security Research Catalogue, relevant policies, and e.g. ISO standards in order to represent our recommendations to use the findings of analyzed projects, where we chose the most pertinent information for a particular issue. The research had positive results and we were able to find material that regulates following aspects:
• Procedural: this case treats the procedural issue that can occur and the relative procedural challenge.
• Cultural: here the topic is ‘how to cover the cultural misalignments among organisations’
• Ethical: recommendation that help organisations to talk about the ethics of their work
• Language: recommendation that help to deal with language misalignments among regions
• Law/legal: list of recommendations to solve legal and political misalignments.

3) Civil protection organizational and procedural interoperability profiles
This task provided a template for the writing of the Organizational Interoperability Profiles (OIPs) as well as the framework for assessing the existing organizational agreements that are aligned with this template and tested by analysing several existing agreements. OIPs cover Aligned Operations and Procedures and Harmonized Strategy/Doctrines layers of the interoperability stack. These layers address the cooperation among organisations at procedural or operational level.
This task concentrates on the analysis of existing international standards, encapsulating the relevant material from their recommendations and also focuses on the analysis of existing organizational agreements among civil protection sector. The analysed standards in this deliverable provide recommendations to organisation structure and how their internal procedures could be applied. The results of this work were used to demonstrate how misalignments in the procedures and agreements of different organisations can be recognised according to relevant standards.
The outcome of this task is specifically documented in report D4.3 “Civil protection organizational and procedural interoperability profiles”, which describes organisation interoperability profiles developed in WP4.
This deliverable provides two Organizational Interoperability Profiles:
The first profile can be used to create a template for formal documentation of cooperation agreements among organisations involved in the emergency domain while assuring that the agreements are complete, comparable and aligned with the analysed standards.
The second profile can be used to analyse several existing partnering agreements later on. The results of this analysis clearly illustrate the lack of alignment with the international standards and the need for better alignment of the organizational agreements across Europe.
C2-SENSE Organizational Interoperability Profile template enables any organisation involved in the crisis management to prepare and write new inter-organisation agreements, which describe the nature of cooperation in everyday operations among them. The template is aligned with relevant international standards recommendations and applicable to all types and sizes of organisations that wish to prepare, maintain or improve their inter-organisation partnering agreement and demonstrate conformity to other organisation when arranging the initial dialogue with potential partners.
Therefore, OIP ensures a degree of interoperability among organisations in planning, establishing, implementing, operating, monitoring, reviewing, maintaining operations, even in the situation, when their organisation's structures or internal procedures are different. This can help emergency organisations to recognize and resolve their cross-organizational interoperability issues.
This report results can be treated as an understandable roadmap of existing standards, which can help public authorities to understand the usage of standards and also can help standardization developers to provide useful standards, also can get major stakeholders and Public Authorities to understand the use of standards and apply them. The incorporation of the aforementioned recommendations will ensure that the defined organizational profiles are in line with the stakeholders’ needs and requirements.
The main objective was achieved by proposing the Organizational Interoperability Profiles, which are aligned with several international standards recommendations, therefore describe and illustrate the methodology that allows the end-user organisations to prepare their partnering agreements or organizational procedures in a formalized way.
1.3.5. Integration process
The purpose of the integration process is to deliver the virtual environment that is required for the testing, execution and management of all the software artefacts needed by C2-SENSE for its operations. The environment has thus been structured taking into account:
- the Consortium needs and requirements, documented preliminary as part of Work Package 2 (WP2 – User Requirement Analysis, System Analysis and Design) and Work Package 7 (WP7 – C2-SENSE Pilot Application Deployment);
- the best practices required to deliver and operate such kind of environments
The integration process covers activities from the planning and the architectural decisions that have been made to the resulting infrastructure and its actual organization.
Given the somehow deeply technical nature of the integration process, this paragraph documents some low-level information about the physical hardware hosting the Integration Environment as well as some functional details on the ways guest applications communicate between themselves and / or external systems.
Integration Environment
The original goal of the integration process was to deliver a virtual environment where Partners could deploy and manage with ease every single software application needed by C2-SENSE.
For this purpose, a hardware (hosting) infrastructure had to be created along with some necessary management tools and processes. The result had to support effectively all the Partners in their software development lifecycles: test, deploy, run, upgrade.
Alongside with the traditional challenges that integration solutions must face, C2-SENSE has some specific issues that stem from the nature of the Consortium and had to be taken into account while designing the actual Integration Environment. Most importantly:

- The absence of a unified technological stack, which translates into a potential proliferation of software dependencies and system requirements – thus creating a higher burden on maintaining the correct environment configuration with possibly evolving requirements, conflicting components, outdated libraries etc.
- The absence of a unified deployment process, which translates into the need for many specific rollout scripts or procedures that cannot be centralized effectively and that are difficult to document, evolve, be executed by different actors (like administrators or people involved in troubleshooting activities).
- The need to keep track of integration issues themselves, which are expected to arise during the early stages of the integration activities as well as during the normal execution (run) phase. Those may, e.g. be related to problems between hosted components and the environment (e.g. a wrong operative system version) or to the incompatibilities between different cooperating components (e.g. an unexpected response format sent out by a service producer).
Aware of the aforementioned C2-SENSE-specific issues and built on top of standard, modern practices about software delivery automation and infrastructure changes management, the proposed Integration Environment solution relies on two key concepts: hardware virtualization and software containerization.
Virtualization
The core concept behind virtualization is to run multiple and isolated instances of independent operative systems (guests) on top of a single, non-virtualized, operative system (host). Virtualization accomplishes this goal by means of a so-called, implementation-dependent hypervisor software layer. Using a virtualized guest system, any specific software component (an “application” according to the terminology used in Figure 5) can be run on a well-defined, isolated and ready-made system that can be deployed without integration and configuration needs in as many different environments as needed.

Figure 5 – How virtualization compares to standard application deployments
Virtualization brings in many advantages over traditional deployment techniques. At a very high level it is possible to group those benefits into 5 categories:
Partitioning
- Run multiple operating systems on one physical machine
- Divide system resources between virtual machines
Isolation
- Provide fault and security isolation at the hardware level
- Preserve performance with advanced resource controls
Encapsulation
- Save the entire state of a virtual machine to files
- Move and copy virtual machines as easily as moving and copying files
Hardware independence
- Provision or migrate any virtual machine to any physical server
Ease of deployment
- Since each VM represents an isolated and reproducible environment, application deployment can simply be a one-time aforethought
Other than that, hypervisor-integrated availability and fault tolerance protects the virtualized applications. Should a node or server ever fail, all its VMs are automatically restarted or continued on another machine, minimizing downtime and data losses.
Containerization
Application containerization is an operating system level virtualization method for deploying and running distributed applications without launching an entire virtual machine (VM) for each single component. Instead, multiple isolated systems are run on a centralized control host. The application containers hold the components such as files, environment variables and libraries necessary to run the desired software. Proponents of containerization point to gains in efficiency for memory, CPU and storage as key benefits of this approach compared to traditional virtualization: because application containers do not have the overhead required by VMs, it is possible to support many more containers on the same infrastructure (a concept sometimes referred to as “density”). This approach grants of course the same important benefits characterizing the virtualization: an application container can run on any guest system without requiring changes.

Figure 6 – How containerization compares to virtualization
Containerization builds on top of the advantages already seen for the virtualization technology (section 0), but reinterprets them from a slightly different, more operations-oriented, point of view:
Rapid application deployment
- containers include the minimal runtime requirements of the application, reducing their size and allowing them to be deployed quickly
Lightweight footprint and minimal overhead
- containers are typically very small, which facilitates rapid delivery and reduces the time to deploy new application containers
Portability across machines
- an application and all its dependencies can be bundled into a single container that is independent from the host version of the operative system kernel, platform distribution, or deployment model; it can thus be transferred and executed to another machine without compatibility issues
Version control and component reuse
- it is simple to track successive versions of a container, inspect differences, or roll-back to previous versions
Sharing and simplified maintenance
- it is possible, and convenient, to use a remote repository to share containers with others

While the key concepts of virtualization and containerization offer the building blocks to deliver an integration environment, there are still some components that need to be introduced in order to make it work effectively.
Requests routing and load balancing
Requests routing is a necessary part of an integration environment. Each deployed service still needs to be reachable from internal and / or external networks in order to make its own services accessible (and useful). This requirement can be fulfilled by assigning an externally visible network address to any relevant service. Such address, however, should not change over time – a requisite that is not simple, or even reasonable, to satisfy in an evolving environment where services may need to be tested, updated, moved to different sub-networks or temporarily brought offline for maintenance reasons etc. To overcome the issues associated with this kind of scenarios a reverse proxy is an extremely valuable solution that lets us to decouple and resolve public, immutable and documented addresses, to private, mutable ones.


Figure 7 – reverse proxy taking requests from the outside and forwarding them to actual servers inside the integration environment
For example, reverse proxies can operate when multiple web-servers must be accessible via a single public IP address. The web servers listen on different ports in the same machine, with the same local IP address or, possibly, on different machines and different local IP addresses altogether. The reverse proxy analyzes each incoming request and delivers it to the right server within the local area network.
Once a reverse proxy has been designed as the single access point of the environment, many other helpful functionalities can be enabled as needed, typically with few configuration changes. Among those that could be more interesting for the C2-SENSE project:
- Reverse proxies can hide the existence and characteristics of an origin server or servers and offer a layer of security against a broad range of attacks
- In the case of secure websites, a web server may not perform SSL encryption itself, but instead offloads the task to a reverse proxy that may be equipped with SSL acceleration hardware
- A reverse proxy can distribute the load from incoming requests to several servers, with each server serving its own application area

1.3.6. Validation process
To validate the results of the project we decided to use the entire Technical requirement (TR) as base for the whole process. We defined three possible ways to validate a TR:
• By architecture. The SW architecture itself allows determining whether that specific TR is addressed. No TR-specific testing for this type of requirement was needed but an accurate evaluation of the architecture.
• By component: This required that a C2-SENSE component is designed and implemented to cover one or more C2-SENSE TRs.
• By (integration) test cases: Some Technical Requirements was validated through the coordinated execution of a workflow executed by the integrations of components on a running architecture .
Based on this understanding, C2-SENSE has followed a pragmatic approach for test and validatin, which is defined as follows:
1. The architecture is re-checked in order to verify which TRs are validated by architecture.
2. At Component owner was asked to perform some component-level testing as part of the development.
3. The integration testing has been performed in task T5.3 were we mainly concentrated at defining and performing the acceptance tests and validation against technical requirements:
a. C2-SENSE integration tests were defined as sets of Test Cases that relate to technical requirements to support validation of the results against technical requirements.
b. The test cases were arranged in “Integration scenarios” and each Integration scenario implemented one business case that was interesting for the end users. This allows us to pre-validate the C2-SENSE results by end users during the integration testing phase.
c. Furthermore, the C2-SENSE end-users (represented by Innova Puglia and Regione Puglia) established links between the WP7 “pilot micro-scenarios”, that was the basis (logical) building blocks for the C2-SENSE pilot application, and the WP5 “integration scenarios”. The idea behind this was that some of the integration scenarios were considered generalization of the pilot micro-scenarios and some may was covering the C2-SENSE functionality that cannot were demonstrated and validated in our pilot application.
The Figure 8 depicts the process the project adopted to define and improve the “integration scenarios”



Figure 8 Methodology of work



Figure 9 provides another perspective of the testing and validation process. An integration scenario is a small distributed application that is realized with C2-SENSE components and fulfils some specific user need (“business objective”). The integration scenarios covered all the objectives for the integration testing but they can also cover additional objectives that was important for the C2-SENSE end users users but that couldn’t be validated in the pilot application.

Figure 9 Testing and Validation process
This picture also serves as a reminder that C2-SENSE had two types of testing and validation, in WP5 and in WP7. WP7-testing specifically addressed the end users and WP5 addressed integration scenarios and WP7 micro scenarios. They were complementary, in the sense that each of them was testing a different set of assumptions:
• WP5 integration scenarios tested generic usability of the components as part of the framework.
• WP7 pilot micro-scenarios tested the usability of the C2-SENSE concepts, framework and components in a near-life pilot scenario
Validation of the result of the WP5 was quite complex because took into the account all type of requirements. Its process is depicted in Figure 10. Basically the validation of the use cases and of the User requirements derived by the elaboration of the evaluations of all results of the tests.

Figure 10 Evaluation and Validation process

The validation by the end users was performed through the evaluation of pilot application activities of the WP7. This type of evaluation was organized in order to consider multiple aspects of the pilot application itself. These were:
• Pilot Application functional requirement compliance: the objective of this evaluation was to measure the gap between the needs of the end users and the real possibilities provided by C2-SENSE tools.
• Evaluation Pilot Application Micro Scenario execution: The objective of this evaluation was to measure the quality of the implementation of the microscenario and the suitability and the usefulness of the proposed scenarios.
• Component evaluation by end users used in pilot application: The objective of this evaluation was to understand if the component used in the pilot application was useful for the end users
• Not functional Criteria. The objective of this type of evaluation was to identify if the NFR of the end-user was met and to identify the area of improvement of the C2-SENSE tool.
1.3.7. Testing and certification
Software testing is the principal validation technique where the system developers test the individual components making up the system by using simulated test data. Each component is tested independently, without other system components. Certification, on the other hand, means that someone apart from the developer checks whether a component meets its specifications and has the desired functionality. In other words, a component is tested and certified that it has reached an acceptable quality standard before it is made available for the users.
Interoperability of a software or service with other systems is one of the most important indicators for the quality of software. Systems communicate with each other through software interfaces (i.e. protocols and documents) for which there exist many standard specifications in different domains. These specifications, however, include many detailed requirements that might be missed easily or misinterpreted during implementation. This might cause companies to lose money, time and even customers when their software is unable to interoperate with other systems in some business processes. In this regard, certification of systems that are exchanging electronic documents between each other is crucial. Therefore, in C2-SENSE, have implemented a certification mechanism in order to test the interoperability and conformance of different types of emergency management systems against the specifications defined in the C2-SENSE Emergency Interoperability Profiles. The system has been implemented based on the principles and specifications defined in GITB initiative.
GITB project aims at developing a global testing framework, architecture and methodologies for state-of-the-art eBusiness Specifications and profiles covering all layers of the interoperability stack (organizational, semantic and technical interoperability). It promotes the reusability of testing resources and capabilities among different domains and standards. The work on GITB is motivated by the increasing need to support testing of eBusiness scenarios as a means of fostering standards adoption, achieving better compliance to standards and greater interoperability within and across the various industry, governmental and public sectors.
The GITB Testing Framework outlines a methodology (what should be tested, how the testing should happen, where the testing should be realized) and defines the actors and the concepts (such as the levels of testing, the difference between a Test Bed and a testing application, the test artefacts) in a testing domain. It defines the architecture shown below for modular and interoperable Test Beds, with a detailed description of their components and services. Furthermore, the schemas for the definition and execution of testing artefacts such as Test Scenarios, Test Presentation and Test Reporting are also provided. The architecture also contains a global Testing Resource Registry and Repository, where any testing application and/or testing resource can be published to the users, who need any type of testing.

According to GITB testing methodology, systems are certified in two testing steps: conformance testing and interoperability testing.
Conformance testing involves verifying whether a single implementation conforms to the underlying specifications. The testing is about checking the conformance of message contents to a document standard specified in the corresponding profile. Conformance Testing is defined as verifying an artefact (e.g. an EDXL SitRep message) against the rules defined in the specification. Interactive Conformance Testing involves direct interaction between Test Bed and System Under Test (SUT), combined with dynamic validation of SUT outputs (document validation). The document validation is delegated by the Test Suite engine to a Document Validator.

In C2-SENSE, conformance testing is realized through a collection of test cases each evaluating whether the captured messages satisfy the requirements, that is document validation. It includes only one system to test, which is System Under Test (SUT), and the other roles are played by GITB according to the test scenarios.
The test cases are presented to the users graphically in GITB Web page. When the execution is started, the results of the execution are displayed to the user graphically. The presentation of an example conformance test case is displayed in the figure below. As it can be seen in the figure, there are four steps:
• An EDXL-DE XML file containing the alert message in CAP format is uploaded to the system.
• The uploaded EDXL-DE XML file is validated against EDXL-DE XSD.
• The CAP XML extracted from EDXL-DE XML is validated against CAP Schematron.
• An acknowledgement is sent back to SUT

Interoperability testing includes more than one system, each playing a different role in a given scenario. It is about testing the systems’ ability to exchange information with each other by complying with the specifications defined in the profiles and to use the information that has been exchanged. Interoperability Testing is defined as the ability of two SUTs to interact with each other in compliance with the specification. This interaction usually involves data artefacts (e.g. messages) produced by one SUT and consumed by the other. Both SUTs should be configured individually and every SUT should play the role of one actor in Test Suite. While actors start to communicate with each other, GITB listens to the transactions between them.


In C2-SENSE, interoperability testing is realized as a process of verifying that two SUTs each playing a different role in a given scenario can interoperate with each other at one or more layers of the interoperability stack while conforming to the specifications defined in the profiles. This type of testing is executed by operating SUTs and capturing their exchanges.
The presentation of an example interoperability test case is displayed in the following figure. In interoperability test case execution, the system first waits for both SUTs to complete their configurations. In the configuration phase, each SUT chooses the actor that they will be acting in the scenario (e.g. Alert Sender or Alert Receiver). When the execution starts, receiver SUT waits for the sender SUT to send a message. Sender SUT sends the message to GITB, GITB validates the message and forwards it to receiver SUT. After the message is retrieved by the receiver SUT, it sends the acknowledgement message to GITB, GITB validates it and forwards to sender SUT. If validation fails at any step or a SUT does not send the desired message, GITB shows a detailed error report.


As it is mentioned already, in C2-SENSE, interoperability of systems is ensured by the Emergency Interoperability Profiles which define set of standard specifications to achieve specific goals. When the systems taking part in the emergency operations follow these specifications, they can cooperate and interoperate seamlessly. In C2-SENSE pilot application, however, the end-user organization legacy systems do not conform to the specifications of these profiles. In this regard, several Legacy Application Representatives (LARs) have been developed in C2-SENSE in order to make these systems profile compliant. As the aim is to test the conformance of systems to the emergency interoperability profiles and LARs connect end-user organization legacy systems to the C2-SENSE environment, tests have been conducted on LARs. The results showed that LARs, which contain Protocol Adapters, Data Integrators and Semantic Interoperability Suite, fully conform to the specifications of C2-SENSE Emergency Interoperability Profiles. Among 10 different cases, 8 of them passed the tests immediately. Only two cases where errors were found clearly demonstrate the usability of the C2-SENSE methodology: thanks to the testing mechanism, these errors were easily caught, identified and corrected. As a result, the whole system became fully interoperable and compliant with the interoperability profiles.


1.3.8. Pilot application

First of all the requirements of the C2-SENSE pilot application have been gathered by taking the current application landscape of end users into account. Then the detailed design of this pilot application has been finalized. Based on these design specifications, the deployment of this pilot application to real life settings has been achieved. The deployed pilot application has been tested and validated to establish whether the quantitative indicators for the potential impact of C2-SENSE have been achieved.
Context of the Pilot
The entities and their roles involved in an emergency event are different and heterogeneous. The envisaged flood emergency scenario involves multiple organizations having different roles and providing different services (e.g. police, medical care, rescue forces, firefighters, etc) and interacting vertically (i.e. with components of the same organization).
Next figure shows the institutions and actors involved in emergency situations. It illustrates the role of the parties involved as described above. Analyzing this figure shows that the Prefecture has a central role. This party coordinates the operations of emergency management. Furthermore, the Civil Protection plays a key role as it handles operations between SOIR and CFDs.
A CFD (Decentralized Functional Centre) in particular retrieves important information like rainfall data directly from the sensor system within the region. Finally, an increasingly important role is played by citizens. In fact, they become participants in a triple role:
first, an active role to inform the organizations responsible when an emergency situation occurs;
second, a passive role, which allows them to be informed in real time following the occurrence of an emergency situation in their area,
and third, the possibility of being easily located on the territory and therefore being properly tasked or informed in case they are needed.

C2-SENSE system overcomes this unsatisfying situation and provides interoperable tools (e.g. adapters, applicative modules, etc..) to the stakeholders involved in a pilot scenario, so we have called all these tools: C2-SENSE Pilot Application.


Institutions and actors involved in emergency situations

The date of execution of the Pilot Application was on May 4, 2017, in Puglia's Civil Protection premises, the main challenge has been the stakeholder's involvement and the interoperability with legacy applications.
Applicative modules called Legacy Application Representatives (LARs) has been implemented, they represent C2-SENSE interfaces to involved stakeholder systems in emergency management. Since the stakeholder's tools are a-priory not interoperable and each of them “speaks its own language”, the LARs foster the interoperability by connecting these applications to the C2-SENSE framework and provide necessary transformation to standard presentations that are used internally within the C2-SENSE’s.

As shown in the Gantt diagram below, Pilot Application deployment has been subdivided into the following main phases:

Roadmap to Pilot Application 2016 2017
1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6

PREPARATION
Definition of micro-scenarios
Definition of interaction with end-user legacy systems
Gathering of interfacing data
Definition of the tool execution environment
Definition of end-users pilot test environment
Profile configuration tool definition
Legacy Application Representative software development
Involvement formalization
INSTALLATION
Installation of end-users pilot test environment
Pre-test of Pilot Application
Training
EXECUTION
Agenda definition for test execution event
Execution of pilot test in selected scenario
Validation set-up




Preparation, divided into following steps:
• Definition of micro-scenarios: in this step pilot scenario is defined into some small micro scenarios which provide for interaction with the systems of the involved stakeholders.
• Definition of interaction with end-user legacy systems: in this step interactions with the end-user legacy system are detailed.
• Gathering of interfacing data: during this phase, InnovaPuglia has organized many meetings with stakeholders and in particular with Province and Prefecture of Foggia, the technical office of national Fire Department, and obviously Regional Civil Protection, in order to gather technical data concerning their legacy systems.
• Definition of the tool execution environment: in this phase has to be defined a complete operative environment to host the C2-SENSE developed tool. Profile tools c/o Regione Puglia premises; Collaboration Environment, Emergency Map tool, SLA Negotiation tools, etc. c/o partner premises.
• Definition of end-users pilot test environment
• Profile configuration tool definition: definition of the modality in which profile configuration tools will be used within the pilot scenario is described in detail.
• Legacy Application Representative software development: the involved partners have implemented applicative modules according to the provided specifications (see Chapter. 2).
• Involvement formalization: in this phase, the involvement of end-users is formalized in accordance with normal procedures for participation in test exercises. During this phase, InnovaPuglia and Regione Puglia organized some meetings in Civil Protection headquarters with all involved and interested stakeholders in order to present the main features of the C2-SENSE project. Defined Pilot Scenario is described following the stakeholder needs that were gathered in previous meetings, during the requirements specification phase.
Installation, divided into following steps:
• Installation of end-users pilot test environment: in this phase, the test environment installation will be implemented. The LARs, the C2-SENSE tools and real and simulated organization systems are installed.
• Pre-test of Pilot Application: in this phase, all implemented modules are tested individually and in integration tests according to pilot micro-scenarios.
• Training: in this step, the involved end-users learned how to use the tools to create and customize the profiles. Local stakeholders learn how to use the tools in a (simulated) realistic pilot scenario.
Execution, divided into following steps:
• Agenda definition for test execution event: at this phase, detailed agenda of the event "pilot exercise of C2-SENSE" is defined.
• Execution of pilot test in the selected scenario: at this step, a rainfall event of exceptional magnitude is simulated as defined by the pilot scenario. The test starts with execution and simulation of a rainfall event. All the involved stakeholders participate in the realization of the scenario.
• Validation set-up: this step is preliminary to the validation of Pilot Application.

First of all has been defined 10 micro scenarios in collaboration with Civil Protection of Regione Puglia starting from case studies based on previous emergency situations occurring in Puglia, using a flood scenario called a "Pilot Scenario". Microscenarios provide for use cases where interactions between the various entities and involved organizations are tested.
Defined micro scenarios are following:
MS01 – Sensor values display
MS02 – AdHoc sensor adding
MS03 – COC opening
MS04 – Volunteers Involvement
MS05 - Risk detection
MS06 – Internal civil protection communication
MS07 – Closure of main roads
MS8 – Alert message
MS09 – Rescue vehicle involvement
MS10 – Fire Department involvement
Next figure shows the final architecture of the Pilot Application

Final architecture of the Pilot Application
The Legacy Application Representatives (LARs) have been implemented to allow C2-SENSE interfacing with the information systems of local users that are involved in the experimentation. Each LAR has two main interfaces:
• On the one side, LAR interfaces directly with the system of the local stakeholder and therefore takes into account the standard used by this system, implementing features that allow interaction with it;
• On the other side, LAR interfaces with C2-SENSE framework and exchanges information with the C2ESB.
Between these two interfaces, LAR assures that the data is transformed to the right format and sent to the right system or stakeholder, in accordance with the workflow description from the relevant profiles. Each LAR, thus, allows bidirectional communications between C2-SENSE and the local user system with no or minimal changes to the local system and to the local operational procedures.

Legacy Applications Protocol Adapters developed and used for the Pilot application are following:

Adapters Protocols & Organizations concerned in C2Sense demonstrator
CAP/RSS RSS/ATOM & CAP
Fire Brigade
E-emailer SMTP
Prefecture
TRBoNet TCP/Proprietary
Volunteers
AOL ActOnLine proprietary
Municipality, CFD, SOIR
Facebook Facebook
Information to population
Twitter Twitter
Information to population
Rupar Wireless Web Services proprietary
Unique Emergency Number


C2-SENSE Interoperability Profiles are standard based specifications defining set of messages, documents, choreographies, business rules and constraints between emergency bodies. It eliminates the need for bilateral agreement between any two information exchange partners. This is achieved in three phases
• Phase 0 - Profile definition: the phase where C2-SENSE Interoperability Profiles are defined
• Phase 1 - Profile specialization: the phase where pilot application micro-scenarios are defined through Interoperability Profiles
• Phase 2 - Profile execution: the phase where pilot is run

For example, specialised Profile for MS10 (Fire Department involvement) is shown.
Before the acronyms are explained:
• COC is Municipality Control Room
• SOIR is Operating Room of Civil Protection
• EMT is Emergency Map Tool (Map tool to represent and manage information about emergency, provided by AIT)

Municipality discovers a big accident involving a fire on a big fuel station. Then they require a service to the Fire Department and inform SOIR (AOL). Fire Department accomplishes the request. SOIR is updated promptly. (C2-SENSE is involved to allow message exchange from/to fire army using CAP protocol and to update SOIR on ActOnLine system). SOIR and Fire department operators read the message and mark it as “read”. Fire department sends updates to COC and SOIR (AOL). The position of intervention is displayed on EMT.
COC discovers a big fire accident. Therefore, COC requires service from Fire Department and informs SOIR. Fire Department sends update information to COC and SOIR about the fire. Positions of intervention are displayed on EMT.

Action Actors Message Corresponding profile
COC require service from Fire Department COC, Fire Department require service from Fire Department Alert
COC informs SOIR COC, SOIR, EMT (SOIR) informs SOIR about the accident Alert
Fire Department sends update information to COC and SOIR about the fire Fire Department, COC, SOIR sends update information Situation Reporting



Specialised profile for MS10
•

1.3.9. Pilot validation and results

During the pilot application execution has been collected several information directly from the end users who was operating on the system or that was just observing the overall execution of the pilot application.
The information colleced was necessary to support:
1. The evaluation of the pilot application against the user requirements defined in D.7.1
2. The evaluation the pilot appplication execution according the evaluation/validation criteria defined once in D7.4 and then refined here in the sec. 2 of D7.5.
3. The validation of parts of D2.2 requirement which are relevant of the pilot application, as indicated by cross-referencing between D2.2 and D7.1 in D2.2
4. Define the improvement areas of the C2Sense Tool

After the pilot application exeution we draw the validation report of Table 1 that address the point 1,2,3 of the list of the above.

Table 1 Validation report of C2-SENSE pilot application

Validation criteria Result comment
The average of all user requirement compliance score is equal or greater than 3
The par. 4.1 of D 7.5 reports an average score of 3,39. Then user requirements are validated Exist some user requirement completely not addressed (see par. 4.1 of D 7.5)
Every funcitonal objective evaluation score of the micro scenario execution is equal or greater than 3
The functional objective evaluation of the micro-scenario execution got a score of 3.8 thus this perspective is validated Micro scenario execution had, basically, no problem (See par. 4.2.1 of D 7.5)
Every subjective evaluation report of the micro scenario execution average score is equal or greater than 3 All micro scenario was subjectively evaluated and validated. The audience filled a survey and every micro scenario got an average score greater than 3 See par. 4.2.2 of D 7.5 for details.
Every Component subjective evaluation average score is equal or greater than 3
All the component got a score greater than 3 according the subjective evaluation of the end-user perfomed by a survey. Thus the component are validated Objectively the end user had not so much time to get confident with the tools and the evaluation they did was not so deep. This fact must be taken into the account for the developing of the tools after the end of the project
The score of the Main Non-functional requirement is equal or greater than 3. All the user defined Not-Functional requirement got a score equal or greater than 3. See. Par 4.4 of D 7.5 for details.

Lastly with the pilot application execution we have determined what is necessary to improve on C2-SENSE components (objective n. 4). We evaluate a list of ISO-Not Functional Requirements and we found a set of characteristic that should be improved (see Table 2) on C2SENSE tools.

Table 2 Characteristics to be improved in C2-SENSE components

Characteristic Sub-Characteristic Description
Usability User Interface Aesthetics The degree to which a user interface enables pleasing and satisfying interaction for the user
User Error Protection The degree to which a system protects users against making errors
Reliability Maturity The degree to which a system meets needs for reliability under normal operation
Fault Tolerance The degree to which a system, product or component operates as intended despite the presence of hardware or software faults
Recoverability The degree to which, in the event of an interruption or a failure, a product or system can recover the data directly affected and re-establish the desired state of the system
Client Recoverability The degree to which in event of a problem on client side (agency C2-SYSTEM system) the solution can recover all the information lost by the client
Robustness The ability of a product to cope with errors during execution or the ability of an algorithm to continue to operate despite abnormalities in conditions, input, calculations, etc.
Security Confidentiality The degree to which a product or system ensures that data are accessible only to those authorized to have access
Integrity The probability that errors or attacks will not lead to access or damage to the state of the system, including data, code, etc
Non-repudiation The degree to which actions or events can be proven to have taken place, so that the events or actions cannot be repudiated later
Authenticity The degree to which the identity of a subject or resource can be proved to be the one claimed
Maintainability Manageability The degree to which the product facilitates efficient and effective management of its operations
Portability Internationalization The ability to change the system to deal with additional international conventions
Satisfaction Comfort The degree to which the user is satisfied with physical comfort

Was also possible to be more specific and to highlight the component that need to be improved after the project completion. (see Table 3)
Table 3 Component to be improved

Component
AnySen Sensor Adapter
Emergency Maps Tool (EMT),GIS Server,Limit Checker,Object Of Interest (OOI) Repository
C2 Enterprise Service Bus (C2ESB)
Data Integrator
Message Communication Platform (MCP)
Profile Topic Map (PTM)
IP Based Gateway
Emergency Ontology Creator Tool
Profile Definition and Specialization Tool (PDST)
Security and Privacy Tool
AOL LAR
CAP LAR
Email LAR
TRBONET LAR

The deliverable D7.5 contains all the details regarding this pilot application evaluation report.

Project Results:
1.3. A description of the main S&T results/foregrounds
1.3.1. Architecture
C2-SENSE Emergency Interoperability Framework has been initially designed as a Service Oriented system where all software components communicate using SOAP and the service orchestration is supported by dedicated framework service. In the course of the project, we have realised that the crisis management work is message-centric in nature and re-designed the framework as an event-based system, where all the framework elements are connected by an Enterprise Service Bus. This has resulted in some communication and messaging abstractions – most notably in the form of the Web Services protocol (enriched with relevant protocol adapters) and the use of the ESB technology, as a key middleware component for everything related to messaging and messaging analysis.
The functionalities of the individual framework components pertaining to different interoperability layers are illustrated in Figure 1.

Figure 1: C2-SENSE Framework
Starting with the (lowest) Physical Interoperability layer, the IP based gateway supports the near-hardware integration of the external components to the C2-SENSE framework and manages the physical connections between the networked applications and devices. A similar function is provided, specifically for sensors, by the AnySen adapter. Adapters from the Protocol Interoperability Layer support protocol-level integration of the legacy software systems and manage the end-to-end delivery of messages and documents.
Components from the Data/Object Model Interoperability Layer and the Semantic Information Interoperability Layer pick up from here and provide the necessary syntactic and semantic mapping of the messages exchanged. Components from the Knowledge Layer manage the creation of a common operational picture of the crisis situation and support the cross-organizational collaboration for joint decision making. Finally, the components from the Aligned Procedures and Operations Layer provide support for aligning the emergency procedures and operations and reaching of agreements between the organisations involved.
For end users and integrators, the software components from the Semantic, Data/Model and Protocol interoperability are never used stand alone. Instead, they merge into intelligent connectors, so-called Legacy Application Representatives (LARs). LARs are generated by Web Service Creator Tool and facilitate the connection between the C2-SENSE system and end-user systems. LARs handle this connection and provides communication among systems through an Enterprise Service Bus (ESB), which is not explicitly shown in the figure. Resulting simplified functional architecture of the C2-SENSE Emergency Interoperability Framework is shown in Figure 2.

Figure 2 C2-SENSE Framework in a higher level

1.3.2. Description of profiling approach
Interoperability is the ability of two or more systems to exchange data and to mutually understand the information which has been exchanged. In emergency management, different Command and Control (C2) Systems and Sensor Systems need to exchange information with each other for the effective management of disasters. Without standards and well-defined specifications, however, the interoperability of these systems can be quite challenging, technologically complex, time-consuming and therefore expensive. Although there are some commonly used standards and specifications in command and control, sensor and disaster management domains, there is no single specification on how to use these standards together when disparate systems need to interoperate. How can (disparate) systems (and users) exchange data, how can they communicate, and which rules should they follow? In other words, how is the challenge of lack of this crucial interoperability properly addressed? In order to solve this problem, in C2-SENSE, we provided the solution by using the profiling approach.
Profiling is a practical approach to achieve seamless interoperability among disparate systems. The profile concept aims to eliminate the need for a prior bilateral agreement between partners in an information exchange network by defining a standard set of messages/documents, choreographies, business rules and constraints. The profile compliant partners are able to exchange information and services among themselves. This means that when a new exchange partner joins the network, there is no need for an agreement as long as it conforms to a predefined profile. Considering the nature of disaster management, in which the responding organizations can change at runtime (especially during international intervention cases), these generic profiles provide much-needed coordination flexibility in order to deal with the unexpected circumstances and prevent a chaotic response.
Profiling has already been successfully used in domains such as eHealth through “Integrating the Healthcare Enterprise Profiles” and eProcurement through “CEN BII Profiles”. The conventional profiling approach addresses only the first three layers of the Interoperability Stack: the “Communication Layer” covers the transport and communication layer protocols; the “Document Layer” addresses the content format of the messages and documents exchanged among the applications, and the “Business Process Layer” addresses the choreography of the activities to be executed by the participants. For emergency management applications, on the other hand, organizational aspects such as policies, procedures, operations and strategies are no less important than technical aspects of interoperability. Hence, the profiling approach introduced in C2-SENSE addresses all the layers of the Interoperability Stack shown below. For each layer, all necessary messages/documents, choreographies, business rules or constraints are specified.

Based on the technical and organizational requirements, the profiles (C2-SENSE Emergency Interoperability Profiles) that were defined in the C2-SENSE project are grouped into three categories:
• Technical Interoperability Profiles
• Physical Interoperability Profiles
• Organizational Interoperability Profiles
Technical Interoperability is associated with hardware/software components, systems and platforms that enable machine-to-machine communication to take place. This kind of interoperability is often centred on (communication) protocols and the infrastructure needed for those protocols to operate. In this regard, Technical Interoperability Profiles are defined as technical specifications that enable information exchange among systems/platforms in a standard way. They concern about Protocol, Data/Object Model, Information and Knowledge Interoperability layers. In C2-SENSE 15 Technical Interoperability Profiles are defined. The list of Technical Interoperability Profiles with their brief description and link to full profile description online are presented in the following table.
Profile Description Online Link
Alert The Alert profile describes how alerts and notifications can be represented digitally and exchanged among all kinds of emergency information systems. It describes a series of activities for the exchange of effective public warning messages. https://service.ait.ac.at/c2-sense/content/alert

Audit Trail and Node Authentication (ATNA) Audit Trail and Node Authentication profiles describe the security environment assumed for the node such as user identification, authentication, authorization, access control etc. It establishes security measures to provide information confidentiality, data integrity and user accountability. https://service.ait.ac.at/c2-sense/content/audit-trail-and-node-authentication

Emergency Situation Map Emergency Situation Map profile describes how a user/organization is provided with a common operational picture of the emergency area using a real-time data and geographical maps. It describes how to get the data, maps and mash-ups. https://service.ait.ac.at/c2-sense/content/emergency-situation-map

Hospital Communication Hospital Communication profile describes how hospitals can communicate with each other and with other members of the emergency management team about the status, services and resources of the hospital. These include bed capacity and availability, emergency department status, available service coverage, and the status of hospital’s facility and operations. https://service.ait.ac.at/c2-sense/content/hospital-communication

Human to Human communication (H2H) This profile will be used to exchange any information that cannot be exchanged through any of the Interoperability Profiles. https://service.ait.ac.at/c2-sense/content/human-human-communication

Mission Plan Mission Plan profile describes which organization will perform which action in the event of an emergency according to country’s emergency plan and organizational structure. The mission plan is generated and distributed by the competent authority who is in charge of managing the emergency situation. https://service.ait.ac.at/c2-sense/content/mission-plan

Permission Permission profile describes how an organization (requester) can ask for permission to perform some specific action from an organization (responder) who is authorized to respond to the permission request. Responder can either give permission or decline it. https://service.ait.ac.at/c2-sense/content/permission

Resource Management Resource Management profile describes how organizations (resource consumer and resource supplier) can communicate about the allocation of resources across the emergency incident life-cycle. This includes preparedness, pre-staging of resources, initial and on-going response, recovery and demobilization/release of resources. https://service.ait.ac.at/c2-sense/content/resource-management

Scheduling Scheduling profile describes in which order the actions in the mission plan will be performed. It will be used in conjunction with Mission Plan Profile. https://service.ait.ac.at/c2-sense/content/scheduling

Sensor Management Sensor Management profile describes how organizations can configure sensors to gain observations from areas of interest. This is important across the whole emergency incident life-cycle, including preparedness, pre-staging of sensors, initial and on-going response, recovery and demobilization/release of sensors. https://service.ait.ac.at/c2-sense/content/sensor-management

Sensor Measurement Sensor Measurement profile describes how sensors transmit their measurements to the C2 Systems, where organizations can analyze the observations. This is important across the whole emergency incident life-cycle, including preparedness, initial and on-going response, recovery and demobilization/release of sensors. https://service.ait.ac.at/c2-sense/content/sensor-measurement

Situation Analysis Situation Analysis profile describes how a user or an organization is provided with a possibility to simulate the situation on the ground for a given set of data. The profile describes how to get the data, maps, mash-ups and simulation results. https://service.ait.ac.at/c2-sense/content/situation-analysis

Situation Reporting Situation Reporting profile describes how an organization (sender) can send situational reports to another one (receiver). It describes a series of activities for the transmission of timely available situational reports https://service.ait.ac.at/c2-sense/content/situation-reporting

Tracking of Citizens Tracking of Citizens profile describes how organizations can exchange emergency citizen and tracking information during evacuation or patient encounter through admission or release. It supports citizen tracking across the emergency medical services, as well as hospital evacuations and patient transfers, providing real-time information to responders, emergency management, coordinating organizations and care facilities in the chain of care and transport. https://service.ait.ac.at/c2-sense/content/tracking-citizens

User Authentication and Authorization (UAA) User Authentication and Authorization defines a means to establish one name per user that can then be used on all of the devices and software that participate in this integration profile. It greatly facilitates centralized user authentication management and provides users with the convenience and speed of a single sign-on. https://service.ait.ac.at/c2-sense/content/user-authentication-and-authorization


Data models and protocols relevant for each of the profiles are shown in the table below.
Profile Data/Object Model(s) Protocol
Alert EDXL CAP SOAP
Audit Trail and Node Authentication (ATNA) Proprietary based on RFC-3881 REST
Emergency Situation Map OGC WMS and OGC WFS SOAP
Hospital Communication EDXL HAVE SOAP
Human to Human Communication (H2H) Proprietary based on EDXL SOAP
Mission Plan Proprietary based on EDXL SOAP
Permission Proprietary based on EDXL SOAP
Resource Management EDXL RM SOAP
Scheduling Proprietary based on EDXL SOAP
Sensor Management OGC SWE SOAP
Sensor Measurement OGC SWE SOAP
Situation Analysis OGC WPS SOAP
Situation Reporting EDXL SitRep SOAP
Tracking of Citizens Proprietary based on EDXL TEP SOAP
User Authentication and Authorization (UAA) Proprietary and XACML REST

Physical Interoperability Profiles are the main part of Physical Interoperability Layer. They contain data and information about physical connection with the communication medium and specify the data acquisition procedure. Physical Interoperability Profiles match the interoperability definition and can successfully be used in Physical Interoperability Layer, as they allow connection of a large variety of devices with specified interface and protocol to systems such as C2-SENSE Framework.
Physical Interoperability Profiles are based on the XML data format. Its structure is universal for all the profiles. Universal structure of physical profile includes all important information about device and data to be collected from the communication medium. The profile is strictly adapted to the physical interface and protocol. Information included in proper field (for example communication specification) are unlimited, so basically every detail of configuration can be specified in the profile. In C2-SENSE, 3 Physical Interoperability Profiles have been developed and tested:
• GPRS modem, connected to the PC with RS232 interface and MODBUS RTU protocol
• Device for electrical parameters measurement
• 866MHz or 433 MHz Radio Transceivers
In these above-described cases, three adapters are created automatically and they are in charge of following readings:
• Adapter 1 (GPRS) – two temperature measurements, two relative humidity measurements, two rainfall measurements.
• Adapter 2 (Power meter) – Network voltage, network frequency, THD (Total Harmonic Distortion).
• Adapter 3 (Radio) – three temperature measurements, three relative humidity measurements.
Detailed technical information about Physical Interoperability Profiles are available at https://service.ait.ac.at/c2-sense/content/physical-profiles
Organizational Interoperability Profiles cover Aligned Operations and Procedures and Harmonized Strategy/Doctrines layers. They concern about cooperation among organizations at procedural or operational level. C2-SENSE Organizational Interoperability Profile template enables any organization involved in the crisis management to prepare and write new inter-organization agreements, which describe the nature of cooperation in everyday operations among them. The template is aligned with relevant international standard recommendations and applicable to all types and sizes of organizations that wish to prepare, maintain or improve their inter-organization partnering agreement and demonstrate conformity to other organization when arranging the initial dialogue with potential partners.
In C2-SENSE, two organizational profiles have been provided:
• Organizational profile for establishing partnering agreement
• Organizational profile for reviewing existing partnering agreements
The first profile provides a guideline on how to prepare and establish partnering arrangements, which are aligned to “ISO 22397:2014: Societal security – Guidelines for establishing partnering arrangements” and “ISO 22301:2012: Societal security – Business continuity management systems – Requirements”; while the second one enables organizations to make an audit of their agreements and review the conformity with aforementioned standards. Further information can be found at https://service.ait.ac.at/c2-sense/content/organisational-interoperability-profiles.
1.3.3. Technical interoperability and software development
The Physical layer, Protocol layer, Data/Object Model layer, Information layer and Knowledge layer relate to “Technical Interoperability” between software systems of the different organisations. Most of the C2-SENSE framework components are situated in the technical interoperability layers. Likewise, the tests and demonstration at the “demo day” on the 4th of May, 2017 at Bari (Puglia region, Italy) concentrated at testing the technical interoperability support of the C2-SENSE framework. The functions and elements that are pertinent to these five interoperability layers are described hereafter.
Physical Interoperability
The “Physical Interoperability” layer manages the physical connections between the networked applications and devices. Some generic physical interoperability profiles have been developed for implementing the most popular interfaces and protocols.
Because we made choice of IP exchanges inside of our C2-SENSE system, we had to develop an IP based Gateway (IPGW) to enable the exchange of data using prominent wired and wireless communication mediums generating dependent adapters on the basis of the physical profiles. This provides universal communication service over a heterogeneous physical network, even for the devices and applications that usually do not use TCP/IP or UDP/IP protocols, and allows us to physically interconnect external application or networks with C2-SENSE.
Main results of our work are relative to the IP Gateway (PIAP) with the physical interoperability profiles, and the sensor protocol interface AnySen (AIT), accompanied with Sensor Configuration and Sensor Measurements profile.
Physical layer has been customized to meet the Regione Puglia infrastructure requirements. It is based on multiple measurement points (nodes) communicating with IP Gateway. Then, it forwards the data to the base station. In Regione Puglia, it was possible to use GSM/GPRS and radio for the communication, and FTP to obtain data from the existing Puglia network.
The underlying idea of AnySen is to interface (m)any sensor(s) without the need for adapting and recompiling the software. This had been achieved by creating a highly flexible sensor protocol interface, which allows for the description of the sensor protocol with configuration files. AnySen only exposes high-level parameters (e.g. sampling rate) to users of the C2-SENSE framework (i.e. crisis manager), as defined in the “Sensor Configuration Profile”.
For the C2-SENSE project, AnySen has been refined to reach a high level of maturity in industrial projects, which proved the concept of a generic sensor driver, so that over 25 types of sensors could be integrated into a data acquisition system.
However, even though AnySen does support many sensor types, it did not support many platforms, because it was coded in C/C++. In order solve this problem, the driver was modernized and ported to Java in the C2-SENSE project.
Protocol Interoperability
The objective was to achieve the protocol interoperability of emergency applications/systems and sensors using heterogeneous protocols. In this respect, “Protocol interoperability” addresses the transport level protocols such as TCP/IP, HTTP, SOAP , REST or SMTP and is in charge of end-to-end delivery of messages.
Some different data format has been handled by the C2-SENSE system (XML, JSON, CSV, XLS) with different protocols (HTTP, SOAP, SMTP) and the said data integrators have been developed.
We used Web service protocols for the protocol interoperability layer by exposing the proprietary services of emergency applications and organizations as “Web services”.
Two protocol interoperability profiles have been defined, and the corresponding Protocol Adapters implemented: (1) Sensor Protocol Adapter and (2) Emergency Applications/Systems Protocol Adapter.
SAFRAN studied the feasibility and design of the legacy systems protocol adapters.
Communication among the components and services was based on the Enterprise Service Bus (ESB), which is developed by LUTECH.
Two software components have been implemented:
• Component Legacy Applications Protocol Adapters (SAFRAN) – The protocol adapter framework lets C2-SENSE systems exchange data with legacy applications that do not comply with protocols defined for C2-SENSE, as presented in Figure 3.


Adapters Protocol & Organization concerned in C2Sense demonstrator
CAP/RSS RSS/ATOM & CAP
Fire Brigade
E-mailer SMTP
Prefecture
TRBoNet TCP/Proprietary
Volunteers
AOL ActOnline proprietary
Municipality
Facebook Facebook
Information to population
Twitter Twitter
Information to population
Figure 3 : Protocol adapters versus organization (Legacy application)

• Component Enterprise Service Bus (Lutech) – The C2SESB component simplifies, through its WS-compliant interface, the interactions (i.e. messages exchange and delivery) between generic systems and the C2-SENSE service bus (see Figure 4)


Figure 4: C2-SENSE architecture with Legacy Applications Representatives and ESB
Data/Object Model Interoperability
Data/Object Model Interoperability Layer involves using the relevant content standards. Common standard interfaces allow data communication among the disparate systems.
The C2-SENSE consortium agreed that it would not be pertinent to have a standardized unique central data model to be imposed on every actor. Modern operability is more based on semantic mediation. For that reason, our data model has been message based and relied on existing standards like EDXL and OGC ones.
In the C2-SENSE Project, the functionality of applications has been exposed as Web services whose interfaces will conform to the related standards.
Thus, the goal was to define the data/object model and to develop the Web Service Creator Tool (WSCT) and the Data Integrator (DI); WSCT was used for building applications from defined profiles and protocol adapters, and DI was used by WSCT to integrate and translate messages at the syntactic level.
We developed a Web Service Creator Tool (WSCT) to generate “Legacy Application Representatives” (LARs) as web applications (also called web services). These LARs embed protocol adapters and expose web services conforming to C2-SENSE standards. They call the Data Integrator (Lutech) and/or the Semantic Interoperability Suite (SRDC) for message translation (syntactic and semantic interoperability).
Information Interoperability
Information Interoperability layer is about mapping dynamic information to each other. The goal was to develop information interoperability profiles as well as semantic mediation mechanisms to be able to harmonize information conforming to different but overlapping emergency standards.
The main steps of our development were:
• Develop Information Interoperability Profiles – Fifteen interoperability profiles with their full description have been defined,
• Explicate the semantics of different but overlapping electronic standards as ontologies,
• Provide semantic mediation among these ontologies,
• Describe the business and operational properties of services through the Universal Service Description Language (USDL),
• Develop Semantic Interoperability Suite.
Semantic Interoperability Suite has been defined through the three components, which have been studied and developed during the C2-Sense project by SRDC:
• Emergency Ontology Creator Tool
• Mapping Generator Tool,
• Semantic Mediator
Knowledge Interoperability
The goal was to establish a common operational picture of the crises situation and to provide support of collaboration for joint decision making. That has been done through the “Knowledge layer” in the C2-SENSE architecture. There were several tools to be developed in order to provide the functionality:
• Collaboration Environment - AIT
• Emergency Maps Tool (EMT) - AIT
• Sensor Management Tool – AIT
• Messaging/Communication Platform - LUTECH
• Registry of Emergency Web Services - PIAP
• Profile Monitoring Tool - SRDC
• Profile Definition Tool - SRDC
• Security and Privacy Tool - SRDC
• Profile Repository – PIAP
• LimitChecker – AIT
• Object of Interest (OOI) Repository - AIT
• GIS Server (depreciated) – AIT

All of these tools have been developed and participated in the integration environment provided by LUTECH.

1.3.4. Organizational Interoperability
Organizational interoperability is concerned with modelling business processes and helping these processes to cooperate and bringing about the collaboration of administrations that wish to exchange information and may have different internal structures and processes. Therefore it addresses the top four layers in the Interoperability Stack Aligned Procedures, Aligned Operations, Harmonized Strategy/Doctrines and High Level/Political Objectives. Organisational interoperability support in C2-SENSE consist of:
1) Harmonization of emergency organizations process with Service Level Agreements and Organizational Level Agreements support, with two main sub-topics:
• Service Level Agreement Specifications
o A survey/analysis of pre-existing standardization efforts in the digital SLA / OLA context, with a specific focus on the WS-agreement specification
• SLA / OLA Templates
o Ad-hoc documental templates have been created for the sake of simplifying the redaction of actual SLAs / OLAs documents between the organisations
These functions are supported by three software components:
• Component Profile Specialization Tool (PST)
o A business process modeller capable to describe the (business process) interactions between the C2-SENSE actors both visually and with BPMN-compliant descriptors
• Component Process Execution Engine (PEE)
o A BPMN executor integrated with the C2-SENSE environment, specifically targeted at the execution of the PST-generated profiles
• Component Service Level Agreement Negotiation Tool (SLANT)
o A digital catalogue for storing and activating Service Level Agreements; once a specific SLA is activated, SLANT can execute (external) enforcement processes should any SLA issues occur
2) Harmonized Strategy Doctrines and High-Level Objectives.
The most research activity was done to examine the public available deliverables of projects that are listed in EU Security Research Catalogue, relevant policies, and e.g. ISO standards in order to represent our recommendations to use the findings of analyzed projects, where we chose the most pertinent information for a particular issue. The research had positive results and we were able to find material that regulates following aspects:
• Procedural: this case treats the procedural issue that can occur and the relative procedural challenge.
• Cultural: here the topic is ‘how to cover the cultural misalignments among organisations’
• Ethical: recommendation that help organisations to talk about the ethics of their work
• Language: recommendation that help to deal with language misalignments among regions
• Law/legal: list of recommendations to solve legal and political misalignments.

3) Civil protection organizational and procedural interoperability profiles
This task provided a template for the writing of the Organizational Interoperability Profiles (OIPs) as well as the framework for assessing the existing organizational agreements that are aligned with this template and tested by analysing several existing agreements. OIPs cover Aligned Operations and Procedures and Harmonized Strategy/Doctrines layers of the interoperability stack. These layers address the cooperation among organisations at procedural or operational level.
This task concentrates on the analysis of existing international standards, encapsulating the relevant material from their recommendations and also focuses on the analysis of existing organizational agreements among civil protection sector. The analysed standards in this deliverable provide recommendations to organisation structure and how their internal procedures could be applied. The results of this work were used to demonstrate how misalignments in the procedures and agreements of different organisations can be recognised according to relevant standards.
The outcome of this task is specifically documented in report D4.3 “Civil protection organizational and procedural interoperability profiles”, which describes organisation interoperability profiles developed in WP4.
This deliverable provides two Organizational Interoperability Profiles:
The first profile can be used to create a template for formal documentation of cooperation agreements among organisations involved in the emergency domain while assuring that the agreements are complete, comparable and aligned with the analysed standards.
The second profile can be used to analyse several existing partnering agreements later on. The results of this analysis clearly illustrate the lack of alignment with the international standards and the need for better alignment of the organizational agreements across Europe.
C2-SENSE Organizational Interoperability Profile template enables any organisation involved in the crisis management to prepare and write new inter-organisation agreements, which describe the nature of cooperation in everyday operations among them. The template is aligned with relevant international standards recommendations and applicable to all types and sizes of organisations that wish to prepare, maintain or improve their inter-organisation partnering agreement and demonstrate conformity to other organisation when arranging the initial dialogue with potential partners.
Therefore, OIP ensures a degree of interoperability among organisations in planning, establishing, implementing, operating, monitoring, reviewing, maintaining operations, even in the situation, when their organisation's structures or internal procedures are different. This can help emergency organisations to recognize and resolve their cross-organizational interoperability issues.
This report results can be treated as an understandable roadmap of existing standards, which can help public authorities to understand the usage of standards and also can help standardization developers to provide useful standards, also can get major stakeholders and Public Authorities to understand the use of standards and apply them. The incorporation of the aforementioned recommendations will ensure that the defined organizational profiles are in line with the stakeholders’ needs and requirements.
The main objective was achieved by proposing the Organizational Interoperability Profiles, which are aligned with several international standards recommendations, therefore describe and illustrate the methodology that allows the end-user organisations to prepare their partnering agreements or organizational procedures in a formalized way.
1.3.5. Integration process
The purpose of the integration process is to deliver the virtual environment that is required for the testing, execution and management of all the software artefacts needed by C2-SENSE for its operations. The environment has thus been structured taking into account:
- the Consortium needs and requirements, documented preliminary as part of Work Package 2 (WP2 – User Requirement Analysis, System Analysis and Design) and Work Package 7 (WP7 – C2-SENSE Pilot Application Deployment);
- the best practices required to deliver and operate such kind of environments
The integration process covers activities from the planning and the architectural decisions that have been made to the resulting infrastructure and its actual organization.
Given the somehow deeply technical nature of the integration process, this paragraph documents some low-level information about the physical hardware hosting the Integration Environment as well as some functional details on the ways guest applications communicate between themselves and / or external systems.
Integration Environment
The original goal of the integration process was to deliver a virtual environment where Partners could deploy and manage with ease every single software application needed by C2-SENSE.
For this purpose, a hardware (hosting) infrastructure had to be created along with some necessary management tools and processes. The result had to support effectively all the Partners in their software development lifecycles: test, deploy, run, upgrade.
Alongside with the traditional challenges that integration solutions must face, C2-SENSE has some specific issues that stem from the nature of the Consortium and had to be taken into account while designing the actual Integration Environment. Most importantly:

- The absence of a unified technological stack, which translates into a potential proliferation of software dependencies and system requirements – thus creating a higher burden on maintaining the correct environment configuration with possibly evolving requirements, conflicting components, outdated libraries etc.
- The absence of a unified deployment process, which translates into the need for many specific rollout scripts or procedures that cannot be centralized effectively and that are difficult to document, evolve, be executed by different actors (like administrators or people involved in troubleshooting activities).
- The need to keep track of integration issues themselves, which are expected to arise during the early stages of the integration activities as well as during the normal execution (run) phase. Those may, e.g. be related to problems between hosted components and the environment (e.g. a wrong operative system version) or to the incompatibilities between different cooperating components (e.g. an unexpected response format sent out by a service producer).
Aware of the aforementioned C2-SENSE-specific issues and built on top of standard, modern practices about software delivery automation and infrastructure changes management, the proposed Integration Environment solution relies on two key concepts: hardware virtualization and software containerization.
Virtualization
The core concept behind virtualization is to run multiple and isolated instances of independent operative systems (guests) on top of a single, non-virtualized, operative system (host). Virtualization accomplishes this goal by means of a so-called, implementation-dependent hypervisor software layer. Using a virtualized guest system, any specific software component (an “application” according to the terminology used in Figure 5) can be run on a well-defined, isolated and ready-made system that can be deployed without integration and configuration needs in as many different environments as needed.

Figure 5 – How virtualization compares to standard application deployments
Virtualization brings in many advantages over traditional deployment techniques. At a very high level it is possible to group those benefits into 5 categories:
Partitioning
- Run multiple operating systems on one physical machine
- Divide system resources between virtual machines
Isolation
- Provide fault and security isolation at the hardware level
- Preserve performance with advanced resource controls
Encapsulation
- Save the entire state of a virtual machine to files
- Move and copy virtual machines as easily as moving and copying files
Hardware independence
- Provision or migrate any virtual machine to any physical server
Ease of deployment
- Since each VM represents an isolated and reproducible environment, application deployment can simply be a one-time aforethought
Other than that, hypervisor-integrated availability and fault tolerance protects the virtualized applications. Should a node or server ever fail, all its VMs are automatically restarted or continued on another machine, minimizing downtime and data losses.
Containerization
Application containerization is an operating system level virtualization method for deploying and running distributed applications without launching an entire virtual machine (VM) for each single component. Instead, multiple isolated systems are run on a centralized control host. The application containers hold the components such as files, environment variables and libraries necessary to run the desired software. Proponents of containerization point to gains in efficiency for memory, CPU and storage as key benefits of this approach compared to traditional virtualization: because application containers do not have the overhead required by VMs, it is possible to support many more containers on the same infrastructure (a concept sometimes referred to as “density”). This approach grants of course the same important benefits characterizing the virtualization: an application container can run on any guest system without requiring changes.

Figure 6 – How containerization compares to virtualization
Containerization builds on top of the advantages already seen for the virtualization technology (section 0), but reinterprets them from a slightly different, more operations-oriented, point of view:
Rapid application deployment
- containers include the minimal runtime requirements of the application, reducing their size and allowing them to be deployed quickly
Lightweight footprint and minimal overhead
- containers are typically very small, which facilitates rapid delivery and reduces the time to deploy new application containers
Portability across machines
- an application and all its dependencies can be bundled into a single container that is independent from the host version of the operative system kernel, platform distribution, or deployment model; it can thus be transferred and executed to another machine without compatibility issues
Version control and component reuse
- it is simple to track successive versions of a container, inspect differences, or roll-back to previous versions
Sharing and simplified maintenance
- it is possible, and convenient, to use a remote repository to share containers with others

While the key concepts of virtualization and containerization offer the building blocks to deliver an integration environment, there are still some components that need to be introduced in order to make it work effectively.
Requests routing and load balancing
Requests routing is a necessary part of an integration environment. Each deployed service still needs to be reachable from internal and / or external networks in order to make its own services accessible (and useful). This requirement can be fulfilled by assigning an externally visible network address to any relevant service. Such address, however, should not change over time – a requisite that is not simple, or even reasonable, to satisfy in an evolving environment where services may need to be tested, updated, moved to different sub-networks or temporarily brought offline for maintenance reasons etc. To overcome the issues associated with this kind of scenarios a reverse proxy is an extremely valuable solution that lets us to decouple and resolve public, immutable and documented addresses, to private, mutable ones.


Figure 7 – reverse proxy taking requests from the outside and forwarding them to actual servers inside the integration environment
For example, reverse proxies can operate when multiple web-servers must be accessible via a single public IP address. The web servers listen on different ports in the same machine, with the same local IP address or, possibly, on different machines and different local IP addresses altogether. The reverse proxy analyzes each incoming request and delivers it to the right server within the local area network.
Once a reverse proxy has been designed as the single access point of the environment, many other helpful functionalities can be enabled as needed, typically with few configuration changes. Among those that could be more interesting for the C2-SENSE project:
- Reverse proxies can hide the existence and characteristics of an origin server or servers and offer a layer of security against a broad range of attacks
- In the case of secure websites, a web server may not perform SSL encryption itself, but instead offloads the task to a reverse proxy that may be equipped with SSL acceleration hardware
- A reverse proxy can distribute the load from incoming requests to several servers, with each server serving its own application area

1.3.6. Validation process
To validate the results of the project we decided to use the entire Technical requirement (TR) as base for the whole process. We defined three possible ways to validate a TR:
• By architecture. The SW architecture itself allows determining whether that specific TR is addressed. No TR-specific testing for this type of requirement was needed but an accurate evaluation of the architecture.
• By component: This required that a C2-SENSE component is designed and implemented to cover one or more C2-SENSE TRs.
• By (integration) test cases: Some Technical Requirements was validated through the coordinated execution of a workflow executed by the integrations of components on a running architecture .
Based on this understanding, C2-SENSE has followed a pragmatic approach for test and validatin, which is defined as follows:
1. The architecture is re-checked in order to verify which TRs are validated by architecture.
2. At Component owner was asked to perform some component-level testing as part of the development.
3. The integration testing has been performed in task T5.3 were we mainly concentrated at defining and performing the acceptance tests and validation against technical requirements:
a. C2-SENSE integration tests were defined as sets of Test Cases that relate to technical requirements to support validation of the results against technical requirements.
b. The test cases were arranged in “Integration scenarios” and each Integration scenario implemented one business case that was interesting for the end users. This allows us to pre-validate the C2-SENSE results by end users during the integration testing phase.
c. Furthermore, the C2-SENSE end-users (represented by Innova Puglia and Regione Puglia) established links between the WP7 “pilot micro-scenarios”, that was the basis (logical) building blocks for the C2-SENSE pilot application, and the WP5 “integration scenarios”. The idea behind this was that some of the integration scenarios were considered generalization of the pilot micro-scenarios and some may was covering the C2-SENSE functionality that cannot were demonstrated and validated in our pilot application.
The Figure 8 depicts the process the project adopted to define and improve the “integration scenarios”



Figure 8 Methodology of work



Figure 9 provides another perspective of the testing and validation process. An integration scenario is a small distributed application that is realized with C2-SENSE components and fulfils some specific user need (“business objective”). The integration scenarios covered all the objectives for the integration testing but they can also cover additional objectives that was important for the C2-SENSE end users users but that couldn’t be validated in the pilot application.

Figure 9 Testing and Validation process
This picture also serves as a reminder that C2-SENSE had two types of testing and validation, in WP5 and in WP7. WP7-testing specifically addressed the end users and WP5 addressed integration scenarios and WP7 micro scenarios. They were complementary, in the sense that each of them was testing a different set of assumptions:
• WP5 integration scenarios tested generic usability of the components as part of the framework.
• WP7 pilot micro-scenarios tested the usability of the C2-SENSE concepts, framework and components in a near-life pilot scenario
Validation of the result of the WP5 was quite complex because took into the account all type of requirements. Its process is depicted in Figure 10. Basically the validation of the use cases and of the User requirements derived by the elaboration of the evaluations of all results of the tests.

Figure 10 Evaluation and Validation process

The validation by the end users was performed through the evaluation of pilot application activities of the WP7. This type of evaluation was organized in order to consider multiple aspects of the pilot application itself. These were:
• Pilot Application functional requirement compliance: the objective of this evaluation was to measure the gap between the needs of the end users and the real possibilities provided by C2-SENSE tools.
• Evaluation Pilot Application Micro Scenario execution: The objective of this evaluation was to measure the quality of the implementation of the microscenario and the suitability and the usefulness of the proposed scenarios.
• Component evaluation by end users used in pilot application: The objective of this evaluation was to understand if the component used in the pilot application was useful for the end users
• Not functional Criteria. The objective of this type of evaluation was to identify if the NFR of the end-user was met and to identify the area of improvement of the C2-SENSE tool.
1.3.7. Testing and certification
Software testing is the principal validation technique where the system developers test the individual components making up the system by using simulated test data. Each component is tested independently, without other system components. Certification, on the other hand, means that someone apart from the developer checks whether a component meets its specifications and has the desired functionality. In other words, a component is tested and certified that it has reached an acceptable quality standard before it is made available for the users.
Interoperability of a software or service with other systems is one of the most important indicators for the quality of software. Systems communicate with each other through software interfaces (i.e. protocols and documents) for which there exist many standard specifications in different domains. These specifications, however, include many detailed requirements that might be missed easily or misinterpreted during implementation. This might cause companies to lose money, time and even customers when their software is unable to interoperate with other systems in some business processes. In this regard, certification of systems that are exchanging electronic documents between each other is crucial. Therefore, in C2-SENSE, have implemented a certification mechanism in order to test the interoperability and conformance of different types of emergency management systems against the specifications defined in the C2-SENSE Emergency Interoperability Profiles. The system has been implemented based on the principles and specifications defined in GITB initiative.
GITB project aims at developing a global testing framework, architecture and methodologies for state-of-the-art eBusiness Specifications and profiles covering all layers of the interoperability stack (organizational, semantic and technical interoperability). It promotes the reusability of testing resources and capabilities among different domains and standards. The work on GITB is motivated by the increasing need to support testing of eBusiness scenarios as a means of fostering standards adoption, achieving better compliance to standards and greater interoperability within and across the various industry, governmental and public sectors.
The GITB Testing Framework outlines a methodology (what should be tested, how the testing should happen, where the testing should be realized) and defines the actors and the concepts (such as the levels of testing, the difference between a Test Bed and a testing application, the test artefacts) in a testing domain. It defines the architecture shown below for modular and interoperable Test Beds, with a detailed description of their components and services. Furthermore, the schemas for the definition and execution of testing artefacts such as Test Scenarios, Test Presentation and Test Reporting are also provided. The architecture also contains a global Testing Resource Registry and Repository, where any testing application and/or testing resource can be published to the users, who need any type of testing.

According to GITB testing methodology, systems are certified in two testing steps: conformance testing and interoperability testing.
Conformance testing involves verifying whether a single implementation conforms to the underlying specifications. The testing is about checking the conformance of message contents to a document standard specified in the corresponding profile. Conformance Testing is defined as verifying an artefact (e.g. an EDXL SitRep message) against the rules defined in the specification. Interactive Conformance Testing involves direct interaction between Test Bed and System Under Test (SUT), combined with dynamic validation of SUT outputs (document validation). The document validation is delegated by the Test Suite engine to a Document Validator.

In C2-SENSE, conformance testing is realized through a collection of test cases each evaluating whether the captured messages satisfy the requirements, that is document validation. It includes only one system to test, which is System Under Test (SUT), and the other roles are played by GITB according to the test scenarios.
The test cases are presented to the users graphically in GITB Web page. When the execution is started, the results of the execution are displayed to the user graphically. The presentation of an example conformance test case is displayed in the figure below. As it can be seen in the figure, there are four steps:
• An EDXL-DE XML file containing the alert message in CAP format is uploaded to the system.
• The uploaded EDXL-DE XML file is validated against EDXL-DE XSD.
• The CAP XML extracted from EDXL-DE XML is validated against CAP Schematron.
• An acknowledgement is sent back to SUT

Interoperability testing includes more than one system, each playing a different role in a given scenario. It is about testing the systems’ ability to exchange information with each other by complying with the specifications defined in the profiles and to use the information that has been exchanged. Interoperability Testing is defined as the ability of two SUTs to interact with each other in compliance with the specification. This interaction usually involves data artefacts (e.g. messages) produced by one SUT and consumed by the other. Both SUTs should be configured individually and every SUT should play the role of one actor in Test Suite. While actors start to communicate with each other, GITB listens to the transactions between them.


In C2-SENSE, interoperability testing is realized as a process of verifying that two SUTs each playing a different role in a given scenario can interoperate with each other at one or more layers of the interoperability stack while conforming to the specifications defined in the profiles. This type of testing is executed by operating SUTs and capturing their exchanges.
The presentation of an example interoperability test case is displayed in the following figure. In interoperability test case execution, the system first waits for both SUTs to complete their configurations. In the configuration phase, each SUT chooses the actor that they will be acting in the scenario (e.g. Alert Sender or Alert Receiver). When the execution starts, receiver SUT waits for the sender SUT to send a message. Sender SUT sends the message to GITB, GITB validates the message and forwards it to receiver SUT. After the message is retrieved by the receiver SUT, it sends the acknowledgement message to GITB, GITB validates it and forwards to sender SUT. If validation fails at any step or a SUT does not send the desired message, GITB shows a detailed error report.


As it is mentioned already, in C2-SENSE, interoperability of systems is ensured by the Emergency Interoperability Profiles which define set of standard specifications to achieve specific goals. When the systems taking part in the emergency operations follow these specifications, they can cooperate and interoperate seamlessly. In C2-SENSE pilot application, however, the end-user organization legacy systems do not conform to the specifications of these profiles. In this regard, several Legacy Application Representatives (LARs) have been developed in C2-SENSE in order to make these systems profile compliant. As the aim is to test the conformance of systems to the emergency interoperability profiles and LARs connect end-user organization legacy systems to the C2-SENSE environment, tests have been conducted on LARs. The results showed that LARs, which contain Protocol Adapters, Data Integrators and Semantic Interoperability Suite, fully conform to the specifications of C2-SENSE Emergency Interoperability Profiles. Among 10 different cases, 8 of them passed the tests immediately. Only two cases where errors were found clearly demonstrate the usability of the C2-SENSE methodology: thanks to the testing mechanism, these errors were easily caught, identified and corrected. As a result, the whole system became fully interoperable and compliant with the interoperability profiles.


1.3.8. Pilot application

First of all the requirements of the C2-SENSE pilot application have been gathered by taking the current application landscape of end users into account. Then the detailed design of this pilot application has been finalized. Based on these design specifications, the deployment of this pilot application to real life settings has been achieved. The deployed pilot application has been tested and validated to establish whether the quantitative indicators for the potential impact of C2-SENSE have been achieved.
Context of the Pilot
The entities and their roles involved in an emergency event are different and heterogeneous. The envisaged flood emergency scenario involves multiple organizations having different roles and providing different services (e.g. police, medical care, rescue forces, firefighters, etc) and interacting vertically (i.e. with components of the same organization).
Next figure shows the institutions and actors involved in emergency situations. It illustrates the role of the parties involved as described above. Analyzing this figure shows that the Prefecture has a central role. This party coordinates the operations of emergency management. Furthermore, the Civil Protection plays a key role as it handles operations between SOIR and CFDs.
A CFD (Decentralized Functional Centre) in particular retrieves important information like rainfall data directly from the sensor system within the region. Finally, an increasingly important role is played by citizens. In fact, they become participants in a triple role:
first, an active role to inform the organizations responsible when an emergency situation occurs;
second, a passive role, which allows them to be informed in real time following the occurrence of an emergency situation in their area,
and third, the possibility of being easily located on the territory and therefore being properly tasked or informed in case they are needed.

C2-SENSE system overcomes this unsatisfying situation and provides interoperable tools (e.g. adapters, applicative modules, etc..) to the stakeholders involved in a pilot scenario, so we have called all these tools: C2-SENSE Pilot Application.


Institutions and actors involved in emergency situations

The date of execution of the Pilot Application was on May 4, 2017, in Puglia's Civil Protection premises, the main challenge has been the stakeholder's involvement and the interoperability with legacy applications.
Applicative modules called Legacy Application Representatives (LARs) has been implemented, they represent C2-SENSE interfaces to involved stakeholder systems in emergency management. Since the stakeholder's tools are a-priory not interoperable and each of them “speaks its own language”, the LARs foster the interoperability by connecting these applications to the C2-SENSE framework and provide necessary transformation to standard presentations that are used internally within the C2-SENSE’s.

As shown in the Gantt diagram below, Pilot Application deployment has been subdivided into the following main phases:

Roadmap to Pilot Application 2016 2017
1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6

PREPARATION
Definition of micro-scenarios
Definition of interaction with end-user legacy systems
Gathering of interfacing data
Definition of the tool execution environment
Definition of end-users pilot test environment
Profile configuration tool definition
Legacy Application Representative software development
Involvement formalization
INSTALLATION
Installation of end-users pilot test environment
Pre-test of Pilot Application
Training
EXECUTION
Agenda definition for test execution event
Execution of pilot test in selected scenario
Validation set-up




Preparation, divided into following steps:
• Definition of micro-scenarios: in this step pilot scenario is defined into some small micro scenarios which provide for interaction with the systems of the involved stakeholders.
• Definition of interaction with end-user legacy systems: in this step interactions with the end-user legacy system are detailed.
• Gathering of interfacing data: during this phase, InnovaPuglia has organized many meetings with stakeholders and in particular with Province and Prefecture of Foggia, the technical office of national Fire Department, and obviously Regional Civil Protection, in order to gather technical data concerning their legacy systems.
• Definition of the tool execution environment: in this phase has to be defined a complete operative environment to host the C2-SENSE developed tool. Profile tools c/o Regione Puglia premises; Collaboration Environment, Emergency Map tool, SLA Negotiation tools, etc. c/o partner premises.
• Definition of end-users pilot test environment
• Profile configuration tool definition: definition of the modality in which profile configuration tools will be used within the pilot scenario is described in detail.
• Legacy Application Representative software development: the involved partners have implemented applicative modules according to the provided specifications (see Chapter. 2).
• Involvement formalization: in this phase, the involvement of end-users is formalized in accordance with normal procedures for participation in test exercises. During this phase, InnovaPuglia and Regione Puglia organized some meetings in Civil Protection headquarters with all involved and interested stakeholders in order to present the main features of the C2-SENSE project. Defined Pilot Scenario is described following the stakeholder needs that were gathered in previous meetings, during the requirements specification phase.
Installation, divided into following steps:
• Installation of end-users pilot test environment: in this phase, the test environment installation will be implemented. The LARs, the C2-SENSE tools and real and simulated organization systems are installed.
• Pre-test of Pilot Application: in this phase, all implemented modules are tested individually and in integration tests according to pilot micro-scenarios.
• Training: in this step, the involved end-users learned how to use the tools to create and customize the profiles. Local stakeholders learn how to use the tools in a (simulated) realistic pilot scenario.
Execution, divided into following steps:
• Agenda definition for test execution event: at this phase, detailed agenda of the event "pilot exercise of C2-SENSE" is defined.
• Execution of pilot test in the selected scenario: at this step, a rainfall event of exceptional magnitude is simulated as defined by the pilot scenario. The test starts with execution and simulation of a rainfall event. All the involved stakeholders participate in the realization of the scenario.
• Validation set-up: this step is preliminary to the validation of Pilot Application.

First of all has been defined 10 micro scenarios in collaboration with Civil Protection of Regione Puglia starting from case studies based on previous emergency situations occurring in Puglia, using a flood scenario called a "Pilot Scenario". Microscenarios provide for use cases where interactions between the various entities and involved organizations are tested.
Defined micro scenarios are following:
MS01 – Sensor values display
MS02 – AdHoc sensor adding
MS03 – COC opening
MS04 – Volunteers Involvement
MS05 - Risk detection
MS06 – Internal civil protection communication
MS07 – Closure of main roads
MS8 – Alert message
MS09 – Rescue vehicle involvement
MS10 – Fire Department involvement
Next figure shows the final architecture of the Pilot Application

Final architecture of the Pilot Application
The Legacy Application Representatives (LARs) have been implemented to allow C2-SENSE interfacing with the information systems of local users that are involved in the experimentation. Each LAR has two main interfaces:
• On the one side, LAR interfaces directly with the system of the local stakeholder and therefore takes into account the standard used by this system, implementing features that allow interaction with it;
• On the other side, LAR interfaces with C2-SENSE framework and exchanges information with the C2ESB.
Between these two interfaces, LAR assures that the data is transformed to the right format and sent to the right system or stakeholder, in accordance with the workflow description from the relevant profiles. Each LAR, thus, allows bidirectional communications between C2-SENSE and the local user system with no or minimal changes to the local system and to the local operational procedures.

Legacy Applications Protocol Adapters developed and used for the Pilot application are following:

Adapters Protocols & Organizations concerned in C2Sense demonstrator
CAP/RSS RSS/ATOM & CAP
Fire Brigade
E-emailer SMTP
Prefecture
TRBoNet TCP/Proprietary
Volunteers
AOL ActOnLine proprietary
Municipality, CFD, SOIR
Facebook Facebook
Information to population
Twitter Twitter
Information to population
Rupar Wireless Web Services proprietary
Unique Emergency Number


C2-SENSE Interoperability Profiles are standard based specifications defining set of messages, documents, choreographies, business rules and constraints between emergency bodies. It eliminates the need for bilateral agreement between any two information exchange partners. This is achieved in three phases
• Phase 0 - Profile definition: the phase where C2-SENSE Interoperability Profiles are defined
• Phase 1 - Profile specialization: the phase where pilot application micro-scenarios are defined through Interoperability Profiles
• Phase 2 - Profile execution: the phase where pilot is run

For example, specialised Profile for MS10 (Fire Department involvement) is shown.
Before the acronyms are explained:
• COC is Municipality Control Room
• SOIR is Operating Room of Civil Protection
• EMT is Emergency Map Tool (Map tool to represent and manage information about emergency, provided by AIT)

Municipality discovers a big accident involving a fire on a big fuel station. Then they require a service to the Fire Department and inform SOIR (AOL). Fire Department accomplishes the request. SOIR is updated promptly. (C2-SENSE is involved to allow message exchange from/to fire army using CAP protocol and to update SOIR on ActOnLine system). SOIR and Fire department operators read the message and mark it as “read”. Fire department sends updates to COC and SOIR (AOL). The position of intervention is displayed on EMT.
COC discovers a big fire accident. Therefore, COC requires service from Fire Department and informs SOIR. Fire Department sends update information to COC and SOIR about the fire. Positions of intervention are displayed on EMT.

Action Actors Message Corresponding profile
COC require service from Fire Department COC, Fire Department require service from Fire Department Alert
COC informs SOIR COC, SOIR, EMT (SOIR) informs SOIR about the accident Alert
Fire Department sends update information to COC and SOIR about the fire Fire Department, COC, SOIR sends update information Situation Reporting



Specialised profile for MS10
•

1.3.9. Pilot validation and results

During the pilot application execution has been collected several information directly from the end users who was operating on the system or that was just observing the overall execution of the pilot application.
The information colleced was necessary to support:
1. The evaluation of the pilot application against the user requirements defined in D.7.1
2. The evaluation the pilot appplication execution according the evaluation/validation criteria defined once in D7.4 and then refined here in the sec. 2 of D7.5.
3. The validation of parts of D2.2 requirement which are relevant of the pilot application, as indicated by cross-referencing between D2.2 and D7.1 in D2.2
4. Define the improvement areas of the C2Sense Tool

After the pilot application exeution we draw the validation report of Table 1 that address the point 1,2,3 of the list of the above.

Table 1 Validation report of C2-SENSE pilot application

Validation criteria Result comment
The average of all user requirement compliance score is equal or greater than 3
The par. 4.1 of D 7.5 reports an average score of 3,39. Then user requirements are validated Exist some user requirement completely not addressed (see par. 4.1 of D 7.5)
Every funcitonal objective evaluation score of the micro scenario execution is equal or greater than 3
The functional objective evaluation of the micro-scenario execution got a score of 3.8 thus this perspective is validated Micro scenario execution had, basically, no problem (See par. 4.2.1 of D 7.5)
Every subjective evaluation report of the micro scenario execution average score is equal or greater than 3 All micro scenario was subjectively evaluated and validated. The audience filled a survey and every micro scenario got an average score greater than 3 See par. 4.2.2 of D 7.5 for details.
Every Component subjective evaluation average score is equal or greater than 3
All the component got a score greater than 3 according the subjective evaluation of the end-user perfomed by a survey. Thus the component are validated Objectively the end user had not so much time to get confident with the tools and the evaluation they did was not so deep. This fact must be taken into the account for the developing of the tools after the end of the project
The score of the Main Non-functional requirement is equal or greater than 3. All the user defined Not-Functional requirement got a score equal or greater than 3. See. Par 4.4 of D 7.5 for details.

Lastly with the pilot application execution we have determined what is necessary to improve on C2-SENSE components (objective n. 4). We evaluate a list of ISO-Not Functional Requirements and we found a set of characteristic that should be improved (see Table 2) on C2SENSE tools.

Table 2 Characteristics to be improved in C2-SENSE components

Characteristic Sub-Characteristic Description
Usability User Interface Aesthetics The degree to which a user interface enables pleasing and satisfying interaction for the user
User Error Protection The degree to which a system protects users against making errors
Reliability Maturity The degree to which a system meets needs for reliability under normal operation
Fault Tolerance The degree to which a system, product or component operates as intended despite the presence of hardware or software faults
Recoverability The degree to which, in the event of an interruption or a failure, a product or system can recover the data directly affected and re-establish the desired state of the system
Client Recoverability The degree to which in event of a problem on client side (agency C2-SYSTEM system) the solution can recover all the information lost by the client
Robustness The ability of a product to cope with errors during execution or the ability of an algorithm to continue to operate despite abnormalities in conditions, input, calculations, etc.
Security Confidentiality The degree to which a product or system ensures that data are accessible only to those authorized to have access
Integrity The probability that errors or attacks will not lead to access or damage to the state of the system, including data, code, etc
Non-repudiation The degree to which actions or events can be proven to have taken place, so that the events or actions cannot be repudiated later
Authenticity The degree to which the identity of a subject or resource can be proved to be the one claimed
Maintainability Manageability The degree to which the product facilitates efficient and effective management of its operations
Portability Internationalization The ability to change the system to deal with additional international conventions
Satisfaction Comfort The degree to which the user is satisfied with physical comfort

Was also possible to be more specific and to highlight the component that need to be improved after the project completion. (see Table 3)
Table 3 Component to be improved

Component
AnySen Sensor Adapter
Emergency Maps Tool (EMT),GIS Server,Limit Checker,Object Of Interest (OOI) Repository
C2 Enterprise Service Bus (C2ESB)
Data Integrator
Message Communication Platform (MCP)
Profile Topic Map (PTM)
IP Based Gateway
Emergency Ontology Creator Tool
Profile Definition and Specialization Tool (PDST)
Security and Privacy Tool
AOL LAR
CAP LAR
Email LAR
TRBONET LAR

The deliverable D7.5 contains all the details regarding this pilot application evaluation report.

Potential Impact:
1.4. The potential impact

Throughout the project duration, the exploitation activities of the project Consortium cover the assessment of the market, assessment of the related technological developments and the business potential especially by the industrial partners. This guarantees an immediate feedback not only on the project work but also on the dissemination plan, which describes the overall exploitation of the project by the C2-SENSE consortium. Such an operational model is essential for a software development project on the cutting edge of the technology in acting on a fast changing environment.
In parallel the Consortium has tried to cluster exploitation results in homogenous groups which could drive our exploitation considerations:
a. A Methodological / Technological Consultancy Package (METH) will allow C2-SENSE partners to approach the target market of Public Administrations and other bodies engaged in the governance and management of emergencies and crises situations. Awareness of needs, challenges and requirements as well as evidence of how C2-SENSE was able to solve it are the key Unique Selling Points of this value Proposition. This package is practically the C2-SENSE business card which needs to be carefully complemented by the results and benefits achieved during our experimentation and by proper dissemination and communication means, such as leaflets, brochures, posters and multimedia material;
b. An Open Source ICT Package (OSS) will form the horizontal platform on which to build specific Emergency management solutions. This OS platform will complement and extend existing larger scale OSS initiatives such as FIWARE community and foundation (www.fiware.org recently formed during the Mobile World Congress and counting thousands of developers) and IOT Open Platform repository (http://open-platforms.eu/). First components and tools of this package have already been identified over time. The exploitation strategy of these OS components is to make them integral part of bigger OS initiatives and to create a broad ecosystem of developers around them. For instance, in FIWARE we already had the project Safecity and a very interesting use case about emergency management in the tunnel joining Arlanda airport and Stockholm. We contacted some of the Safecity partners (e.g. Telecom Italia, AIT, VTT, Everis) to check how C2-SENSE open source solutions could extend the current portfolio of FIWARE components in this domain. Regarding instead the IOT Open Platform community (preliminarily contacted through ISMB Turin who is leading the ALMANAC project and the Cluster Activity Chain #3 about pilots), we already have cases related to explosives and hazardous gases management as well as Earthquake and Landslides prevention and emergency management.
c. A C2-SENSE ICT Solutions Package (C2-SENSE) will form the vertical part of our ICT results and include as background several proprietary tools and components brought by our beneficiaries. This package can be considered as the ICT backbone of our Value Proposition to PAs and C2 centers. Different business models will be operated according to the exploitation models of the C2-SENSE ICT solution providers (e.g. SRDC, Lutech, Regola, Safran) which are now preliminarily sketched in the individual exploitation plan sections. Cloud-enabled aaS models seem however the most suitable way to attract a large number of Emergency Management practitioners without heavy investments in infrastructure and ICT licenses.
d. A C2-SENSE Pilot Showcase Package (PILOT) forms our leading-by-example Value proposition. In this package with the final field experimentations and lessons learned, we collected all the material necessary to give evidence of the tangible and intangible positive effects derived from the adoption of C2-SENSE. A well-founded generalization method is developed in order to be able to estimate social and business benefits in other domains and contexts than those addressed by our Apulian experimentation. In this respect, it is of fundamental relevance to be in touch with users’ communities starting from the Countries represented by C2-SENSE partners: France (North-West EU) Italy (South-West EU) Turkey (South-East EU) Poland (East EU) Austria (Central EU) and expanding them to other EU Countries.

The following paragraphs describe the impact of exploitation activities carried out by each partner of the Consortium, using the above cluster exploitation homogenous groups: METH, OSS, C2-SENSE, PILOT:
1.4.1. Safran Electronics and Defence
The first ideas for the exploitation were the following:
- Work perforrrmed within C2-SENSE project in order to define the user’s requirement show the new needs from end-users, relative to the improvement of the technology or new security threats in relation to news or trends. Safran is going to work in these new areas, alone or in cooperation with relevant partners
- Finally, as interoperability is one of the key factors for the future competitive industry, participation in future standardization activities in this field will be strongly considered and the experts allocated to the C2-SENSE project will continue to support those tasks.
The first item is the more promising and will be the subject of a deepening. The French Ministry of Interior has contacted Safran in October 2017. The Ministry intends to set up a unified information system of fire and rescue services and civil security through a project started in 2018. The Ministry was interested to know more about the technologies and standards developed inside the project C2-SENSE.
The following paragraphs describe specific exploitation assets:
1.4.1.1. Safran - METH ASSET #1
Follow-up of EU SEQUANA 2016: Paris has been traumatized by the huge flood in 1910. We fear the consequences of such a flood if it occurs today. So very regularly exercises are organized at the level of the city itself or suburb departments or the full region. In March 2016 a big exercise at the State level (co-funded with EU) has been organized. The State is also organized into seven defence and safety zones, which are capable of managing crisis situations that are beyond the capability of the departments.
The Paris Defense and Safety Zone covers the whole of the Ile-de-France. The Prefect of Police, who is also the Prefect of the Zone, is supported by a Secretary General; the Secretary-General of the Defense and Safety Zone (Secrétariat Général de la Zone de Défense et de Sécurité - SGZDS) performs missions relating to civil and economic safety and the security of sectors of vital importance in the zone.
The SGZDS plans and optimizes the public authorities' response to crisis situations, focusing on four main areas:
• Coordination of action by public services and private operators;
• Processing and feedback of information;
• Management of operational methods through the involvement of zonal or extra-zonal resources, to support the local departments;
• Government communication for crises beyond the capability of the local department.
Within these missions, the SGZDS is responsible for organizing the zonal exercises. Sequana is one of these.
After the exercise, several improvement axes have been demonstrated. Even if some ideas have been emitted it is necessary to study the implications of the changes. Safran intends to participate to the global analysis and has already taken the contacts with the Prefecture of Police to be informed and bring added value with solutions that could be derived from C2-SENSE.
1.4.1.2. Safran - METH ASSET #2
Presentation of C2-SENSE progress to French authorities:
After the contacts initiated through the follow-up of SEQUANA exercise, Prefecture of Police and fire brigades were interested in the global approach of C2-SENSE. The principle of such a presentation has been validated and Safran will use the video made during the pilot application to show concretely the benefits of this type product in order to define something adequate to the specific needs including the existing equipment.
1.4.1.3. Safran - OSS ASSET #1
C2 for the citizen:
Today everybody owns a smartphone. Based on existing tools and open-source software an application could be easily built in order to be able to quickly give orders to the people in case of emergency. This application could be connected to a system like C2-SENSE using a GSM/3G/4G/5G existing in development infrastructure. This kind of application has already been introduced at experimental level in USA (trough DHS Department of Homeland security and FEMA Federal Emergency Management Agency). After Paris 2015 attacks, France has also developed some applications in order to inform the public. Safran has some existing bricks (from defence domain) that could be used for civilian C2.
The economical approach of this type of application has still to be investigated, the first application developed after Paris attacks being not a success.
1.4.1.4. Safran - OSS ASSET #2
On-field emergency communication bubble:
When a big disaster occurs communication means (earthquakes, floods, fires...) can be out of service for quite a lot of time. The debriefing with first responders (fire brigades) shows the need for a wideband communication network that could be set up in a brief time allowing restoring autonomous communications means between responders. At this time only voice communications can be used. This high-speed communication bubble should be based on existing / in development technologies to be accessible in terms of cost for first responders having a limited budget. This solution is based on a product developed for military purposes but based on civilian technologies.

1.4.1.5. Safran - C2-SENSE ASSET #1
Flood modelling tools:
Flood modelling tools are existing for years. However, the last flood in Paris (June 2016) shows that the information given to the citizen about the height of water was wrong. This was due to not working sensors that gave some false inputs to the models but also a change in the nature of the soils: for example, trees who were no more existing close to Paris but also far from Paris in the tributaries of the Seine, or the humidity of the soils before the start of the flood. This high humidity prevents the soil to absorb the rain. For all these reasons prediction of the flood (height and timing) was wrong. Of course the type of model has to take into account the geographical data (mountains, ...) behaviour of the rivers, weather forecast, in order to improve the future systems based on C2-SENSE.
1.4.1.6. Safran - C2-SENSE ASSET #2
Emergency Planing and real-time re-planing tool
C2-SENSE is a very interesting concept of interoperability of heterogeneous systems. However, C2-SENSE is a reactive tool that should increase the speed of the exchange between existing and future systems. A way to improve this concept is to add a planner tool with real-time re-planning capabilities allowing adjusting the resources to the evolution of the situation. Safran has already experimented this concept on the battlefield, through a tool called ORTAC.
1.4.1.7. Safran - C2-SENSE ASSET #3
Adaptation to the new SEVESO regulations:
Recent attacks (2015-2016) in all Europe show that every site can be considerate as “sensible”. Among these sites, some of them remain more sensible than other due to the consequences for the citizen if an attack occurs. At this time protection of SEVESO sites is very low. Existing SEVESO regulations try to limit the consequences of an accidental explosion but the protection against an intrusion is not really mentioned. Safran is participating in France into a working group to define what could be this protection. Even if part of this protection will be physical, interoperability issues exist. So lessons learned from C2-SENSE are very useful. French authorities in charge of security raised the idea of building a H2020 topic. If possible Safran will push the relevant ideas from C2-SENSE. So, it could be also a possibility of a joined cooperation.
1.4.2. Lutech SpA
1.4.2.1. Lutech - METH ASSET #1
The profile management methodology introduced in C2-SENSE is the key module that allows experimenting and different approaches to integrate modules and enrich the process with additional intermediate steps.
Profiling the users involved in a crisis management tool helps to create tailored and automated services that can be integrated in the current infrastructure.
Lutech started by adding new workflow extensions and new modules to act as sub-processes in order to have new components architecturally pluggable to other systems. Such modules can be easily re-used in other C2 ICT scenarios.
The main module is the he communication channel, named Enterprise Service Bus (ESB) and the Profile Engine (PE), mainly developed by Lutech, which has been successfully integrated in other projects and is still increasing the efficiency in managing data exchange between actors, that is the interoperability.
As of now, the security group in Lutech has made extensive use of the idea behind the ESB as well as the Cognitive computing team, which uses ESB-like module to efficiently manage superfast processes handling huge amount of data.
1.4.2.2. Lutech - METH ASSET #2
C2-SENSE project introduced technologies that allowed Lutech to acquire knowledge to be actualized in solutions based on security and emergency management frameworks and help supporting customers in addressing their needs.
Lutech’s goal is to continue the activities in this field, exploiting the technologies proposed because of the great importance in defining the way crisis management processes are addressed.
The profile engine represents the clue. It represents a standard and flexible way to orchestrate communications among actors (i.e. fire brigades, civil protection agencies etc.), and can help by providing a support to the decision making process.
In this case the main stakeholders are public agencies and companies already working in such specific field, which could find interesting ideas to improve the efficiency of the techniques used for interoperability and information exchange
1.4.2.3. Lutech - OSS ASSET #1
The Enterprise Service Bus (ESB) is the module Lutech has fully developed in order to build a communication channel able to manage heterogeneous messages sent by several sources. It is based on Apache Kafka, an open source component distributed within the Apache License 2.0 therefore it is possible to exploit it accordingly (towards SENSE IoT solutions), and extend it with additional modules in order to optimize and adapt some features to the specific context. The scalability is a real plus that has been seriously taken under consideration in foreseeing the future of the ESB module and its applications.
Starting from Kafka, Lutech is starting integrating additional open source tools capable to perform stream analysis in order to almost online data analysis, like Apache Storm and Apache Flink, in order to produce predictive analytics results for further investigation and exploitation also in crisis management scenarios.
1.4.2.4. Lutech - OSS ASSET #2
The Alfresco Activiti framework is the open source tool used in the implementation of the profile engine. It is very famous in the community also because of its easiness in modelling process workflows. In this case it has been used for defining the sequence of tasks to be executed by the specific actor. It is easily integrated in the architecture and is highly configurable throughout the BPMN language, which provides a standardized way to describe activities and flows. This module can be easily extended within the C2-SENSE project by defining specialized processes that are triggered using any of the available interoperability technologies (web services, alerting, etc.) in a specific step.
The idea is to leverage this approach in other contexts where the customer requires reliable mechanisms for managing processes with the chance to customize behaviours and extensions. A follow up on this has been to use such approach to design complex roles with specific features like: super user able to access some shared documentation and its review management process.
1.4.2.5. Lutech - C2-SENSE ASSET #1
The C2-SENSE application enriches common emergency systems functionalities with semantically enriched Web Services using Web service protocols for the protocol level interoperability.
The crucial point is that in this field there are a lot of legacy applications provided from a lot of different organizations that rely on their own protocols for exchanging messages: this could cause delays coordinating operations during a crisis because of the needs to integrate and understand the communication itself.
The Apache Kafka has been used to overcome this limitations and introducing a layer for standardizing and for sharing information. Another fundamental component of this layer are the Data Integrators also developed by Lutech, that is in charge to receive, convert and send messages that are in a not compliant format. Those components with others constitute the Enterprise Service Bus and the Messaging and Communication Platform in C2-SENSE.
Lutech has many different customers who could use the depicted technologies in different sectors.
Thanks to the result of this task, Lutech will also be able to integrate them in its proprietary projects like L-TMS and wHospital as well as in Data Analytics projects that require high-throughput performances and infrastructures.
1.4.2.6. Lutech - C2-SENSE ASSET #2
One of the main targets of C2-SENSE is to have an Aligned Procedures and Operations layer used to make familiar each emergency partner with each other’s processes and to align their operations. In this layer, the concept of profiling is fundamental. Profiling Approach is an analysis to clarify actors and their peculiarities, actions, relationship about entities and interactions involved in a specific context. Profiling is typically executed progressively at various levels and profiles of each level provide a more detailed vision of the general context. A profile can describe an actor (for example an end-user) and its interactions with other actors. The profiles are coded in a machine-readable format that specific software can interpret and execute to support interactions that profiles represent. It is important to have an engine that is in charge to execute those profiles.
Lutech has developed a Profile Execution Engine that has as a main task to execute profiles. In this layer it is also fundamental the negotiation of the Service Level Agreement, that are a formal contract regarding services within different organizations. The process of negotiation will be supported by the SLA Negotiation Tools developed by Lutech.
The profile execution engine is also under improvement since it can be easily adapted to projects involving similar tasks based on user profiling and task management.
Lutech developed a lot of projects based on profiles execution (BPMN) through the support of strong partnerships with the main firms of Workflow Management World.
1.4.2.7. Lutech - C2-SENSE ASSET #3
The integration of all components is a crucial aspect in Lutech’s activity. Lutech is a “system integrator” and has a lot of experience in performing such task in the best way.
Modules are usually developed starting from previously defined interfaces based on well accepted standards.
A way to facilitate the integration is by providing software like Maven that has an Apache License.
Lutech will also provide a repository with SVN, for collecting the different version of the software parts. It will create the architecture for combining all the produced software because it has itself a lot of experience in software integrations.
1.4.3. Austrian Institute of Technology GmbH (AIT)
Internally the C2-SENSE project enhanced the development of AIT technologies in the field of integration of Sensor Technology (also related to Sensor Web Enablement and Semantic Web Technologies), which are focused on crisis and disaster management, into a new direction building on new findings of C2-SENSE framework.
C2-SENSE enhanced our tools and technologies through the possibility of interoperability and evaluation providing a better understanding of them.
This means further that externally, the enhancement of our systems will positively influence our market leadership in Austria as the combination of our systems with C2-SENSE brings added value to our customers (mainly authorities, who will have to work cross-administration borders) and will bring up new customers from other domains.
AIT is a strategic research partner having a strong link to the market especially to regional, national governments as well as to mayor Austrian Cities.
As mentioned in D8.1 (a) AIT has a strong interest to exploit its research developments to regional and national governments as well as to provide enabling technology to SMEs in Austria.
AIT intends to strengthen their actual business and foster its future ones mainly through the following activities:
• Preparedness for upcoming technologies by participation in the C2-SENSE and other research projects
• Commercialization of C2-SENSE (technology)
• Consulting for decision makers using C2-SENSE results
• Resource integrator for C2-SENSE
• Enhance AIT’s scientific reputation through conferences and papers
• Apply C2-SENSE results to the AIT customers to increase market effectiveness (e.g. performance, cost reductions, enabling technology)

Thus AIT contacted during the course of the second period of the project for further business opportunities the following institutions and organizations.
On National Level we contacted and/or invited:
• Umweltbundesamt (Austrian Environmental Protection Agency): Jürgen Schneider (Head of Sales) and Günter Pfaff (IT-Solutions)
On Regional Level we contacted and/or invited:
• Province of Upper Austria (Environmental Protection Agency / Dept. Air Monitoring): Elisabeth Danninger
• Province of Lower Austria (Environmental Protection Agency / Dept. Air Monitoring): Elisabeth Scheicher
• Province of Burgenland (Environmental Protection Agency / Dept. Air Quality Monitoring): Franz Bauer
AIT presented C2-SENSE results to related civil protection organizations of major cities in Austria: For example, for the
• City of Vienna, Magistrat 68
(https://www.wien.gv.at/menschen/sicherheit/feuerwehr/katastrophenschutz/) which is responsible for FireBrigades and Civil Protection (e.g. related to floods, storms, heavy rainfalls, etc.)
1.4.3.1. AIT - METH ASSET #2
The assets gained by the development, specification and documentation of the C2-SENSE user and technical requirements as well as the C2-SENSE architecture design are made available for the public via the C2-SENSE web portal. The knowledge assets gained through the requirements and architectural definition process can be provided by AIT as well as involved C2-SENSE partners. Therefor a type of business consultancy agreement (if needed) will be defined.
1.4.3.2. AIT - OSS ASSET #1
EMT and OOI is software associated to the (FIWARE) Wirecloud and is provided as open source under Affero General Public License version 3 (AGPL v3): due to that, the software development done on the base of Wirecloud will be Open Source, and in this way exploited accordingly.
Sensor Management Tool is a development of AIT. It will be provided as open source by AIT. For the time being the licensing model has not been defined yet.
1.4.3.3. AIT - C2-SENSE ASSET #1: Interoperability - Maps and OOI Knowledge
The EMT (Emergency Maps Tool) and OOI (Object of Interest) is built in a modular way and also as stand-alone module, which can be easily adapted to the end-users needs. It provides relevant information in one application to allow a proper decision making on a crises event. EMT provides a quick overview about all actual incoming and outgoing messages as well as various measurement values (of different sensor types).
Currently it is only as prototype available but AIT intends to provide it beyond the project as a front end for decision making in the crises and disaster management field, collaborating with the above mentioned SMEs but also with C2-SENSE partners if needs arise.
The Object of Interest (OOI) database is tightly connected to the EMT and stores all information relevant to be displayed in the EMT, i.e. all resources integrated in the framework, which are all messages (including alarms) sent over the C2-SENSE system as well as all measurement values (from sensor) relevant for decision making.
The development of EMT and OOI was solely done by AIT.
1.4.3.4. AIT - C2-SENSE ASSET #2
The sensor protocol adapter allows connecting sensor (via the ESB and OOI) into a monitoring and decision making system. In C2-SENSE the so-called AnySen will be used to connect ad-hoc sensors into the C2-SENSE framework. This adapter supports various protocols for different sensors. It is suitable for various environmental domains. The development of AnySen was solely done by AIT.
1.4.3.5. AIT - C2-SENSE ASSET #3
Interoperability - Maps Knowledge - Frequentis AG
Frequentis AG is a leading provider of command and control centre solutions for the police, ambulance and fire & rescue services. AIT is cooperation with Frequentis in different projects. AIT discusses with Frequentis introduce C2-SENSE results (like Emergency Maps Tool and Object of Interest repository) in further (research) projects. Contact: Christian Falchberger/Thomas Seltsam.
Christian Hassmann – Enviornmental Monitoring
(http://www.hassmann-cc.com/) Hassmann Company is planning, installing, extending, maintaining, operating and integrating existing installations into a regional, national or international monitoring network(s) is always done within with a close study and in close co-operation the client: AIT in cooperating with Hassmann in Indonesia. AIT will have the possibility to exploit C2-SENSE as a whole but also only selective C2-SENSE tools into the East-Asia region. AIT will contact Hassmann to examine together exploitation possibilities and markets related to the objectives of C2-SENSE in Asia.
Commercialization #2 (Sensor Protocol Adapter)
Sensor integration belongs to the core business of AIT. The sensor protocol adapter allows to connect sensor (various types: from air, water, soil, meteo and others) into a monitoring and decision making system. In C2-SENSE the so-called AnySen will be used to connect ad-hoc sensors into the C2-SENSE framework. This adapter supports various protocols for different sensors as mentioned before it is suitable for various environmental domains. It has already a high Technology Readiness Level so a commercialization could start early after the project ends.
The development of AnySen was solely done by AIT.
Consulting for decision makers #1 (Red Cross)
AIT has a long connection to the Red Cross and collaborated in some national security projects, related to crowd sourcing and –tasking as well as volunteer management in Austria. Thus we have a well-established connection to the Austrian Red Cross, especially to the chief-commander of Austria Gerry Foitik.
AIT already introduced to the Austrian Red Cross the Emergency Maps Tool for decision making and provided pro-actively consulting assistance.
Consulting for decision makers #2 (Landeswarnzentralen/Fire Brigades)
AIT has connection to the Landeswarnzentralen including FireBrigades in the Provinces and in cities like the City of Vienna. Some of them involved as project partners in other EC funded projects, where also AIT is partner. For example, Landeswarnzentrale of Styria (in the INKA a national security project). Contact point (in Styria): Günter Hohenberger
AIT already introduced to some of the Landeswarnzentralen (and related organizations) in different Austrian Provinces the principles of decision making related to the Emergency Maps Tool in a Command and Control environment and if needed provide further consulting assistance for the integration of resources.
Resource integrator
Generally spoken, AIT acts as integrator and provides knowledge to external resource integrators when needed (externally or internal).
But related to C2-SENSE AIT will provide knowledge gained through and beyond the course of the project to system integrators and/or end-users related to local and dedicated resource integration, which means integration of e.g. remote or legacy systems, sensors, or senor networks, maps, information, reports, messages into the framework of C2-SENSE or directly into the Decision Support tool (i.e. EMT and the Object of Interest (OOI) Database).

1.4.4. Software Research, Development and Consultancy Ltd. (SRDC)
SRDC already has a customer base in Turkey including State Planning Organization, Turkish Coast Guards, the Ministry of Health (MoH), Revenue Administration of Turkey, the Ministry of Finance (MoF) thanks to its extensive Research and Technical Development (RTD) work on the interoperability solutions. C2-SENSE project has given SRDC the opportunity to extend its customer base thanks to the tools and profiles that have been developed in the project life-time.
In this regard, SRDC followed an exploitation strategy on corresponding tools and profiles which is explained in the subsections below.
1.4.4.1. SRDC - OSS ASSET #1
One of the main responsibilities of SRDC in C2-SENSE project was to provide information interoperability for emergency organizations. SRDC provided the solution by introducing a Semantic Interoperability Suite, where SRDC extended its SemanticMDR (Semantic Metadata Registry) Tool to C2-SENSE purposes. In the second half of the project, SRDC successfully achieved to sell the Semantic MDR tool which is part of C2-SENSE Semantic Interoperability Suite to Turkish State Meteorological Service (MGM). Specific instances of the system are currently installed on MGM servers to collect all the information inside MGM in a flexible data model and then make them conformant to or interoperable with world-wide used content model standards. After the successful installation, the system performed reliable performance, as a result MGM have signed a consultancy agreement with SRDC. Currently, IT department of MGM is upgrading their server infrastructure with the latest technology under the supervision of SRDC. Finally, SRDC and MGM have signed a third agreement on the development of mobile applications of Turkish Meteorological Service. SRDC developed the mobile applications from scratch in iOS and Android environments. In these applications, SRDC used the Alert profile of C2-SENSE in order to send meteorological alerts to the citizens of Turkey. The applications can be seen at
https://itunes.apple.com/tr/app/hava-durumu-meteoroloji/id509200200?mt=8
https://play.google.com/store/apps/details?id=tr.gov.mgm.meteorolojihavadurumu
1.4.4.2. SRDC - OSS ASSET #1
In C2-SENSE, SRDC focused on the layer of specific interoperability profiles which have been consolidated and integrated into C2-SENSE Emergency Interoperability Profiles. Such profiles were grouped in categories depending on their purpose and usage, presented into conferences and technical committees and considered as a concrete point to pursue additional research results. SRDC aimed to exploit these profiles together with the Profile Definition and Specialization Tool (PDST). In this regard, SRDC made contact with HL7 on User Authentication and Authorization (UAA) and Audit Trail and Node Authentication (ATNA) profiles; OASIS on the all C2-SENSE profiles utilizing EDXL standards and PDST, CEN on migration of CEN BII profiles to PDST for easier management and automatic Word generation.
SRDC will also intensify its exploitation strategy towards certification and testing of emergency management systems. In this respect, SRDC will improve the market of its TestBATN™ conformance and interoperability testing tool. TestBATN was already used in several domains such as eHealth. In WP6 of C2-SENSE, SRDC has successfully extended this tool for emergency management domain. SRDC now aims to present this mechanism as well to standardization organizations mentioned above. If accepted, SRDC aims to get fee per test case. In this regard, SRDC has created business model that is 100 EUR for registration and 5 EUR for each test case, for the testing of emergency systems on the conformance of them to EDXL and OGC standards as well as the C2-SENSE profiles.
Aselsan is the largest company in Turkey that produces tactical military radios and defense electronic systems for the Turkish Armed Forces. They also serve to Turkish Coast Guard Command. SRDC got an appointment with Aselsan to present the achievements of C2-SENSE project and discuss about possible usage of some parts, especially the profiling and sensor related stuff, with Aselsan. The aim is first to sign a consultancy agreement and then extend it further.
1.4.5. Sezione Protezione Civile Regione Puglia
Civil Protection Department of Regione Puglia intends to update its warning system protocols aimed to improve the identification of territorial risks, in order to protect the population, thanks to the contribution provided by the experience of the C2sense project.
1.4.6. InnovaPuglia SpA
Due to the institutional role InnovaPuglia has provided ICT solutions to Apulian public administrations and operators as well as in assuring their connectivity and interoperability toward national agencies and administrations. The C2-SENSE project had specific relevance for assessing and evaluate new technologies and solutions that can, at the same time, increase the Public Administration Capacity building and contribute to improve digital services, in particular those devoted to support the Protezione Civile regional department and the regional health stakeholders (118 Emergency Centre, regional Health System and structures, etc.). InnovaPuglia, therefore, plans to improve the already implemented services with new functionalities arising from the research activities carried out on interoperability frameworks for mission-oriented security systems, especially for features related to the use of international standards for information management in emergency situations and for interoperability services. With this purpose InnovaPuglia has paid particular attention keep being involved in both, the definition of standard-based interoperability profiles and operating procedures based on novel technological solutions, guidelines and recommendations, as well as in their validation in a real world context.
To the periodically organized emergency drills held in the Apulia region has provided useful input and a relevant test bed for the C2-SENSE project and enabled InnovaPuglia, with the other regional operative stakeholders involved in the project (e.g. Protezione Civile Regione Puglia) to acquire all relevant information for an exploitation of the project results within its ICT services and infrastructure.

1.4.7. Industrial Research Institute for Automation and Measurements (PIAP)
PIAP will make usage of C2-SENSE results towards Polish ICT services in national and regional level to support their implementation. The institute will use the technological results gained as a baseline for further research and PIAP will increase the specific multimodal urban transport domain knowledge, to be exploited in cooperation with Civil Protection Institutions in Poland.
The exploitation type differs on the achieved research result and on the exploitation activity.
Some of activities could use direct technical improvements and usually have a direct impact within a short time frame, while others influence research results with a long term impact on the further research directions and networking community to derive strategic guidelines.
PIAP is an industrial partner, hence it exploits technical improvements internally. A company uses the acquired know-how to shorten turn-around times from the project results to produce new version, for example to reduce time–to-market and improve its business position or to outperform competitors through the quality of immediately forthcoming new products.
PIAP is focusing its exploitation activities on improving their current operation and position in existing markets, and on the creation of and preparation for new markets, with the intention to obtain a leadership position.
Complementary to activities written above PIAP will exploit project results among the scientific community through different curriculum programmes namely:
1. Warsaw University of Technology (WUT) at Mechatronics Faculty – by performing student’s evaluation of the system capabilities and engaging them in contribution in testing the developed system. This will be done under “Intelligent Measurement Devices” – a new course in the Electronic Measurement Systems specialization on engineering degree. During this course, students gain comprehensive skills: knowledge about the intelligent sensors, measurements devices and systems operation rules.
2. Warsaw University of Life Sciences. Division of Hydrology and Water Resources - by performing student’s evaluation of the system capabilities and engaging them in contribution in testing the developed system. This will be done under environmental engineering curriculum programme.
3. Liaisons with International Organization for Standardization: One of the organisational profile, which was provided under deliverable D4.3 “Civil protection organisational and procedural interoperability profiles” was a guideline on how to prepare and establishing partnering arrangements, which is aligned to “ISO 22397:2014 - Societal security — Guidelines for establishing partnering arrangements” and “ISO 22301:2012: Societal security — Business continuity management systems — Requirements” and includes requirements from Mandate M/487 to Establish Security Standards. PIAP will contact ISO Technical Committee ISO/TC 223 and share the results, by proposing new ideas and improvements to future iteration of “Guidelines for establishing partnering arrangements”, which can be included in ISO 223## Standards family.
Results of C2-SENSE project in academic community and academic partners will continue to gain increased visibility and improve research of teaching processes. This academic exploitation of strategic guidelines, naturally, has a longer time horizon. The future research agenda will be prepared based on the results achieved by C2-SENSE, and potential problems that have to be solved will be identified, in order to strengthen the project impact. The long run result of the efforts of the academic partners will be to promote the approaches project results in the mainstream of teaching in areas of electronic measurements and environmental engineering in higher education environment.
1.4.7.1. PIAP - C2-SENSE ASSET #1
PIAP main role will be maintenance and support of developed communication network infrastructure and networked devices under physical layer. Moreover, though its role in implementation of C2-SENSE acquired technology and knowledge will be used for enhancing and extending existing product portfolio.
1.4.8. Regola S.r.l
Regola is a producer of C2 System mainly focused on the Emergency Medical Response but it is growing towards the management of critical domain like Fire, Police and civil protection. These fields were object of minor product development but nowadays Regola is ready to take deal with these important domains.
Our market is mainly European and Italian specifically but is going to be worldwide thanks to strong partnership with USA and Austrian company.
Interoperability it’s an important challenge for us. Every customer has specific and complex needs that require a proper answer.
C2-SENSE is a project with several categories of outcomes, and, according to the Regola’s vision, the most important ones are those listed below:
• The KnowHow: it’s possible to extend the DOW analysis identifying several area of interest:
- KnowHow from the real user of the Pilot application: The C2-SENSE Pilot application is a great opportunity for Regola to improve the knowledge on the Civil Protection Field. The C2-SENSE Pilot application is a complex application mainly build on the civil protection world
- Integration profile: The integration profile approach in Emergency is something new in IT literature. The integration profile approach is extremely powerful (we know and use IHE integration profile) and it’s the correct approach to design complex integration solution among different organization/system. Regola will re-use this approach in implementing the new solution to the customer worldwide.
- KnowHow from the organizations: the harmonization activity of WP 4 it’s a great opportunity to study and learn many procedural and organizational aspects. This specific knowhow will be used by Regola to increase the awareness of the domain where its products are sold and used.
• The partnership: The project is a great opportunity for a PMI like Regola to meet new partner for future collaborations with research centers like AIT, SRDC or PIAP. Typically, it’s quite hard for a PMI to have contacts with such reality, for this reason this point is a worth Regola will exploit in the future with B2B meeting.
• The technology: C2-SENSE consortium will produce a set of tools that are able to ease the problem of the technical interoperability among organizations. These project outcomes can be successfully applied in all the Regola’s client perspectives as a standard-based platform to enhance communication and cooperation of field operators and the operative organizations. Ensuring permanent communication among all operative central’s systems
Detailed exploitation action per outcome and typology:
Outcome Exploitation strategy
Know-How • Internal Training: The C2-SENSE project approach of the ‘integration profile’ into the emergency domain will be object of internal training to all SW and Solution Architect.
• New Product Requirement. At the end of the project will be produced the list of the application requirement Regola will implement on one or more product. This new requirement will be shared also with InnovaPuglia and Regione Puglia The requirement will be inserted in the product roadmap .
• Participation to new call of H2020 project where C2-SENSE outcome can be reused and extended.
Partnership • Regola will try to have private initiative with other partner in order to investigate for future collaboration. Knowhow reuse, reselling or commercial partnerships are possibility that will be interesting to analyze.
Technology Regola will evaluate if the tool developed by the C2-SENSE consortium can be used on the client in respect of their needs and budget. The outcome of the project will be illustrated to our largest client that are: 118 Piemonte, EMS Lithuania.

1.4.8.1. Regola - METH ASSET #1
State of the art is a resource to better understand the world around. Regola will reuse such resource to take awareness of technology and solution not currently deployed on our client.
1.4.8.2. Regola - METH ASSET #2
The technological solution of C2-Sense will be taken into the account in case of large integration project that involve cross-force organizations of emergency management
1.4.8.3. Regola - OSS ASSET #1
Regola will take awareness of the C2-SENSE solution and its component in order to propose solutions on large integration project
1.4.8.4. Regola - OSS ASSET #2
Regola will take awareness of the C2-SENSE technical solution and its component in order to propose solutions on large integration project. About the procedural solution (deliverable 4.2 and 4.3) Regola will use such material to support emergency managers. These deliverables will be taken into the account to better contextualize the usage of some Regola’s products or to propose better organizational solution to our customer.
1.4.8.5. Regola - C2-SENSE ASSET #2
Regola will take awareness of the C2-SENSE solution and its component in order to propose solutions on large integration project.
1.4.8.6. Regola - C2-SENSE ASSET #1
Regola will take awareness of the C2-SENSE solution and its component in order to propose solutions on large integration project
1.4.8.7. Regola - C2-SENSE ASSET #3
Regola will take awareness of the C2-SENSE solution and its component in order to propose solutions on large integration project
1.4.8.8. Regola - PILOT ASSET #1
• During the pilot application execution Regola improved his KnowHow on the emergency management domain and gained the following top level requirement to be included in its product development: Agency need to exchange formal communication that need to be tracked.
• An agency shall formally take in to the account a communication. During the pilot execution was definitely verified that is possible to build a communication system among agencies based on strong formal commitment of communication.
• Agency need to be notified when a recipient took into the account a specific message. This facilitates the awareness that the agencies are aligned.
• Multi-channel integration. Still exist agency or organization that cannot update its technological equipment for cost or regulation difficult to apply. Cooperation with email and CAP channel are very useful or even mandatory in some region (like Italy)
• Is correct to let every agency to be free with the definition of the event. Every agency manages a territory with specific liabilities. In a ‘hub-spoke’ organization the ‘event cannot be defined by the hub because his view is completely different from the spoke. We verified this during the pilot application execution where the hub (Regione Puglia) had different view of the spoke (municipality). The hub should be promptly notified of all relevant information by the spokes.
• It is correct the idea to bind together: message (text), data on map, external resource (file). This dataset is the minimum set of data to be exchanged atomically in the emergency management.
• Security: End users are really sensible about the data security being sent from an agency to another. There should be a technological solution that guarantees that a message can be viewed only by certain agencies and not others. Moreover, this requirement instructs us also that is possible to identify different level of ‘security’ of a message to be taken into the account only by specific role within an organization.

1.4.8.9. Regola - PILOT ASSET #2
During the pilot application execution was used only ActOnLine, a product of Regola. End users reported the product was really interesting but need to be improved on some specific characteristic. This is for us an important asset to be exploited in the future. The characteristic to be improved was:
• Number of information reported. Users need a customizable data set. The best would be a custom data set defined on an event base
• Polygon on the geo-localized data attached to a message: Is absolutely necessary to draw polygons on a map and attach them to the message
• Better feedback of the technical processing of a message. During the pilot application execution happened a message forwarding was delayed because of the performance of some internal C2-SENSE component. The ActOnline has not a ‘monitor’ the message exchange that, if present, will help to promptly identify where is a technical problem.
• Possibility to simple TAG any communication or message. This will let to inspect the archive with less rigidity in comparison of the ‘classic’ event base search that is still useful.
The other Regola product planned to be used during the pilot (Nowtice, Nue112) was not used. This was a change of the plan we had. For this reason, we weren’t able to collect feedbacks from the end users about these two products.

List of Websites:
1.5. Dissemination channels:
The C2-SENSE public website presents general project information, scientific publications done during the project, news about the project, events organized and public deliverables.
This is the main dissemination channel: http://c2-sense.eu/
C2-SENSE is also present through social channels:
FaceBook : https://www.facebook.com/c2sense/
Twitter: https://twitter.com/c2_sense
Youtube: https://www.youtube.com/channel/UCz_TSufkrGond97X3naxw_Q
LinkedIn: www.linkedin.com/in/c2-sense
SlideShare: http://www.slideshare.net/C2SENSE

Powiązane dokumenty

• C2-SENSE final_publishable_summary