Final Report Summary - IDIRA (Interoperability of data and procedures in large-scale multinational disaster response actions)
Executive Summary:
1.1 Executive summary
The IDIRA project conceptualized, developed, demonstrated and assessed approaches to facilitate coordination of large-scale disaster situations by improved interoperability. Several layers have been considered: from physical communication over semantic information interoperability up to the information interoperability on the application layer.
Main focus has been to provide a common operational picture for all stakeholders involved. A system for the exchange of the most relevant information during crises aftermath - among them information on incidents, alerts, resources, missing persons and urgent needs - has been designed and implemented. IDIRA helps to overcome language barriers and achieve technical interoperability.
Data exchange is based on standards as EDXL-RM, EDXL-SitRep and EDXL-CAP which are well known. It has been shown, that existing legacy command and control systems can easily be adopted to facilitate these standards. Semantical interoperability is achieved by using TSO codes. Further expert system can be connected to the developed mobile command and control structure, e.g. for the provision of simulation results to commanders on the scene. Basic tools for decision support (reachability, routing, load-balancing etc.), incident and resource management and the ad-hoc import of geographic data; contact data and sensor data are integrated. Communication hardware has been developed to provide ad-hoc broad-band connectivity within affected regions.
Situational awareness of foreign forces coming in the affected area is supported with a new tool that allows for efficient generation of reports describing the region, the situation and assigned tasks. The in-situ assessment of the needs families or households in general have is supported by a newly implemented toolbox.
The system development was undertaken as a close cooperation between end-users from various fields including firefighting, medical rescue, disaster relief organisations, defence and civil-military organizations, cooperating industrial partners, academia and research & development organisations.
Training and evaluation have served as the connecting elements between stakeholders and allowed for identification of improvement potential. Throughout the project, the developed solutions where systematically evaluated by the end-users concerning their potential to improve the effectiveness and efficiency of management of large-scale crises. After small-scale tests and training, the IDIRA system has been deployed and demonstrated in three large-scale exercises with scenarios related to pandemic, flood, earthquake and fire.
The End-User Advisory Board was an auxiliary body targeting on accompanying and facilitating the development of IDIRA throughout the whole project span of four years and constantly checked the tools developed from an end-user perspective. It was mainly formed by civil protection actors (such as authorities, agencies, international organizations, NGOs, responding units and single experts) not involved in the IDIRA consortium.
End-users concluded, that IDIRA provides a common working environment and useful tools for sharing information. Its deployment creates a high benefit in the management of large-scale disaster situations. The important precondition is that relevant information is made available and shared.
Due to European research funding, it was possible to undertake the needed research & development and demonstration efforts in a multi-national way. For a full exploration of the potential of interoperability in crises management, further activities related to research & development, standardisation and demonstration are needed, together with appropriated funding.
Project Context and Objectives:
1.2 Project context and main objectives
The starting point of IDIRA was the situation of periodically occurring large scale disasters in Europe, such as floods, forest fires, and earthquakes. Beginning from a certain extent, which can differ between regions and dependent on the impact, the response actions are based on multi-national and cross-organizational cooperation. One of the main questions in this context was, how to manage the efforts contributed by different countries/organizations effectively.
The IDIRA vison consisted of three basic elements:
• All acting organisations share a common operational picture.
• Linguistic and technical communication barriers must not constrain an effective resource management.
• Structures and procedures of information interchange are compatible.
Thus, the basic IDIRA ideas were to provide
• Infrastructure for central servers and services, ad hoc wireless communication, and a common operational picture,
• Guidelines for validation and adaptation of existing processes, description of successful rules and procedures, harmonization and standardization.
A special focus was on the development and demonstration of solutions that improve interoperability, among them:
• Exchange information about resources, incidents, observations, alerts, needs, missing persons etc.
• Access real-time simulations (fire propagation, release of chemicals, evacuation etc.)
• Exchange of messages in foreign languages
• Integrate and interpret sensor data
Additionally to the improvement of interoperability, technologies were developed related to:
• self-sufficient data and voice communication,
• Decision support,
• Donation management and
• Early situational awareness.
These technologies had to be evaluated in terms of usefulness for the management of large-scale crises. Guidelines for successful introduction of such solutions and for harmonisation of structures and procedures in crisis management were developed
The project started in 2011 with a systematic analysis of use cases and requirements. From the beginning end-users were involved.
As soon, as use cases and requirements were manifested (deliverables D1.1 D1.2 D1.3 and D2.1) the technical development team started drafting an expandable software architecture on the basis of well-known standards and approaches. A first draft of the IT architecture was concluded by the project team in August 2012 (deliverable D2.2). This architecture enables the forces involved in management of large-scale crises to coordinate their efforts. On the basis of this, first prototypical applications as well as the background technologies were developed. A first demonstration took place at the first project review meeting in Dresden in November 2012 which convinced end-users of the underlying concept and the prospective benefits. The technical development was then organised in iterative loops.
The End-User Advisory Board was officially inaugurated in an early phase of the project. Throughout the project, small-scale and large scale training exercises were organised and the developed solutions were demonstrated and tested. After successful testing of the components in small-scale exercises concerning correct functioning, they were deployed in large-scale exercises. Thereby, the IDIRA system and its components where evaluated regarding their usefulness and usability for management of large-scale crises.
During such training, the feedback from the end-users was gathered by means of survey instruments. These feedback was then considered in the following development cycle.
In the last step of the project, conclusions regarding technical harmonisation and procedures were collected, documented and aggregated by the entire project team.
Project Results:
1.3 Main results
1.3.1 General architecture and used data standards
The basic concept of the IDIRA architecture are:
• Loose coupling of components,
• Service-oriented architecture,
• Principles of modularity, extensibility and possibility to integrate external tools and data in a common, interoperable environment,
• Use of existing standards to ensure seamless data exchange and, as a consequence, to realise interoperability.
Different deployment scenarios are possible for such service oriented architectures. These include cloud-based solutions as well as the deployment of local infrastructures. The solution adopted in IDIRA considers a combined approach, with a cloud-based infrastructure, always online and always able to get relevant information from external systems, as well as a portable solution, deployable on the disaster site (as an additional EU Civil Protection module for example). This portable and locally deployable solution, represented by the MICS itself, is intended to cope especially with situations, where the traditional networking infrastructures are not available, mainly because they are destroyed or damaged.
With interoperability the most important focus of the project, the IDIRA system architecture has been built on very specific design and development principles, aimed at making it possible to communicate with existing, external legacy systems, as well as the integration of the different IDIRA tools and heterogeneous types of data coming from disparate sources.
Such design and development principles can be summarised in the choice of architectural patterns for ensuring loose-coupling of components, in a clear distinction between internal services and services used to enable the communication with external systems, and in the adoption of a modular implementation approach, which allows different functionalities to be plugged in or unplugged as needed.
Besides the choice of the above mentioned principles, the key enabler for the IDIRA interoperable architecture was, with no doubt, the choice to find and use the most suitable standards to consume or provide specific types of information.
For addressing the syntactical interoperability aspects, two main elements have been considered:
• The data model design in IDIRA was carried out taking into account specific actual or de-facto standard data formats to be used for representing each different type of information: in practical terms, this means that the different data structures used internally, are mapped as much as possible to the corresponding data formats, to be used for handling information that are exchanged or integrated from external systems. Hence, information on incidents, resources and tasks, as well as information on sensors, or results from external simulation systems, can be easily integrated and then processed within IDIRA
• The software interfaces and protocols for the communication with external systems, have always considered the use of open and not-proprietary, and standard whenever possible, communication interfaces
The use of standards for achieving interoperability at a semantic level has also been considered: although not the specific focus of the project, a possible approach has been implemented, which takes into account, as part of the IDIRA data model, the use of a common taxonomy, i.e. a shared dictionary of terms and definitions for emergency related information.
The final solutions adopted in IDIRA for implementing the above mentioned principles, will be presented in the following sub-sections by tackling the aspects listed below:
• Formal (actual) or informal (de-facto) standards used in IDIRA, together with their scope and the reasons at the basis of their choice
• Specific cases where the use of standards was not possible, and the reasons for this (e.g. missing standards for a given domain or information type)
By taking into account the different types of information and communication scenarios relevant during disaster management, we can distinguish between:
• Information areas where suitable actual or de-facto standards have been adopted for information exchange
• Information areas where non-standard solutions have been adopted, simply because standardised ways of sharing certain types of information are not available yet
Information exchange in IDIRA is mainly based on the following technological solutions:
• Communication technologies
o SOAP Web Services for synchronous communication between software components, both internally and with external systems
o REST web services,
o Publish-Subscribe mechanisms for internal, asynchronous communication between software components
o ATOM and RSS feeds for communication with external systems
o OGC WMS/WFS standards for integration of geographic layers and retrieval of geospatial data from multiple sources on the Internet
o OGC SOS standard for the integration of sensors measurements
• Data formats
o EDXL family of standards for the integration of alerts, incidents, tasks and resources related information
o OGC SensorML and O&M for what concerns integration of sensor data, observations and measurements by sensors
o PFIF for the synchronisation on information on missing persons between IDIRA Missing Person Tracing components, and external Missing Person Tracing systems
o Shapefiles and OSM XML formats for storing physical features such as roads or buildings in a geospatial vector data format
o OGC SLD to provide styling or visualisation of the map data
For all formats, standards and de-facto standards used in IDIRA the identified gaps or areas of improvement were classified using the following main categories:
• Missing fields of information in the available (standard or not) data formats
• Limits & inefficiencies
• Missing standards
• Harmonisation needs
By “Missing fields of information” we refer to situations where a given available data structure does not provide all the fields of information that could be needed in a real emergency situation. “Limits & inefficiencies” refers to situations where the use of certain capabilities was not found efficient, or put in evidence some drawbacks, while “Missing standards” highlights specific information exchange scenarios, domains or integration needs, for which well defined, not proprietary data structures are not available yet. Finally, with the term “harmonisation needs” we refer to the cases in which the use of specific approaches for information exchange could be made more efficient, by harmonising the way the information is organised and provided. The details and also the recommendations for improvements can be found in the publicly deliverable D7.3.
1.3.2 The IDIRA Modules: Components and examples for the demonstration of interoperability
In this section those components are listed and briefly described, which were developed, enhanced and/or used in IDIRA in order to test or to demonstrate the interoperability approaches proposed by the project. Some more details can be found in the mentioned deliverables and in the public report 8.5.
It was not the intention of IDIRA to elaborate highly sophisticated graphical user interfaces for the field or staff commanders or to enhance specific existing models or tools. Rather, all effort spent for the IDIRA modules was focused on the implementation and evaluation of existing standards to achieve interoperability. It is not easy to make interfaces and interoperability visible. That’s why some of the background software solutions of the project partners were used as a kind of counterpart of the general architecture and the IDIRA COP, i.e. as components to show, how the IDIRA approach is working, and to investigate, which steps are needed to make any similar systems interoperable following the IDIRA recommendations. Some of the visualisation tools were particularly needed to allow testing by and training of users.
1.3.2.1 Mobile Integrated Command and Control Structure (MICS)
The IDIRA MICS is a self-contained, system that can be transported to a disaster site. It can also be installed and operated when internet connections are broken or not available. The MICS unit can be a container with the MICS rack (Server), with PCs (work places for tactical users), Communication Field Relays (COFRs) and Wireless Gateways, and Tablets (for operational users in the field).
Complementary to the MICS - that is a physical entity (hardware plus installed software) - the Fixed Infrastructure is a service that can run anywhere (cloud computing) and is continuously updated. When the MICS is deployed, the relevant databases are copied from the Fixed Infrastructure to the MICS, so that the MICS is up to date.
The MICS server has installed the entire required software environment together with the configured IDIRA modules. When the MICS is deployed, only the databases need to be updated from the Fixed Infrastructure and following the MICS can be shipped. The MICS server rack contains two Windows servers, an uninterrupted power supply, a network switch and a router. Some subsystems are encapsulated in virtual machines using Ubuntu Linux.
A switch is equipped in the MICS to interconnect the two servers and clients for accessing the COP. Server 1 uses the Windows operating system and provides the COP and the database. In addition to this machine, three virtual Ubuntu machines are running, where two are reserved for further usage and one is running the Asterisk server for IDIRA voice communication. Server 2 uses the Windows operating system and acts as fall back for Server 1. The three Ubuntu virtual machines are used for dedicated services and databases. More details on the MICS are explained in Deliverable D5.5 and D7.2.
1.3.2.2 Wireless Gateway
A working broadband communication network is needed to use the IDIRA system within a disaster area. In the case of a break-down of public internet infrastructure, a private mesh net can be established, using the IDIRA Communication Field Relays (COFRs), Wireless Gateways (WGWs), Mobile Broadband Extender (MBE) and Mobile Broadband Multiplexer (MBM). This hardware can supply WLAN coverage at the hot spots of the response activities.
The MICS will be shipped with WGWs, COFRs and MBMs to establish an independent communication network between on-site field commanders and the MICS. The WGWs can be mounted on any pre-existing infrastructure or on poles provided with the MICS. It is used to establish links between different on-site operations and provides WLAN connectivity for the field commanders. The WGWs form an ad-hoc meshed backbone network in the operational area. Further it provides a local wireless cloud via an Omni antenna.
1.3.2.3 Communication Field Relay
The Communication Field Relay (COFR) is installed together with the WGW. The COFR could offer offline functionality, and allows connecting different uplink technologies and PCs or networks of field units to the communication network. The COFR prototype is shown in Figure 4. The functional blocks are shown in Figure 5. More details about the WGW and COFR can be found in IDIRA deliverable D3.1.
1.3.2.4 Mobile Broadband Extender
The Mobile Broadband Extender (MBE) provides a 3G uplink in areas where only a weak 3G signal is present that would not allow using the 3G network with out-of-stock hardware. The MBE consists of a rotatable 3G antenna. The antenna is automatically aligned towards the 3G pole with the highest signal strength. The self-alignment is controlled by an embedded computer. The MBE provides a LAN interface to connect end devices of the first responders to the provided Mobile Broadband Multiplexer (MBM). Compared to the MBE, the MBM combines three rotatable 3G antennas into one casing. This allows using three independent networks from three different 3G providers. These networks can be combined to increase the bandwidth of the Internet connection. Further, the connection is very stable as if one or two provider fail the Internet connection is still operational. The MBM uses the Multipath TCP protocol in combination with a VPN tunnel to combine the connectivity of the three providers towards one common connection.
1.3.2.5 Voice communication (WebTalk)
Direct communication between the different responders and with the tactical commander is essential in a crisis situation. The usual communication channels (digital/analogue radio, mobile phones) are sometimes not suitable in an international disaster response situation due to incompatible radio protocols or missing or damaged radio infrastructure. The IDIRA Voice Communication subsystem is intended to bridge the communication gap between IDIRA users in these cases. IDIRA uses internet connections or the WGW/COFR network for voice and data communication.
The IDIRA Voice Communication subsystem enables Voice over Internet Protocol (VoIP) communication, instant messaging and phone conferencing between IDIRA users (Tablet clients and Web client). Every item created in IDIRA (e.g. observation, incident, resource) references to the item’s owner and allows contacting him directly. Using instant messages, a link to the item is automatically inserted and directly leads to the map position and details of the object.
The technical solution consists of a SIP server (Asterisk) managing the connection handling and the instant messaging, a GUI component (WebTalk) for the user interaction and the Web-RTC features built-in in the browser (Google Chrome) of the Web GUI. The Tablet client uses a native SIP client providing almost the same features and using the same server interfaces.
A detailed documentation of the Voice Communication Subsystem is provided in deliverable D3.3.
1.3.2.6 IDIRA Common Operational Picture (COP)
The COP subsystem provides a comprehensive picture of the current situation in a geographical context. It enables an up-to-date situational awareness for all involved units and real-time communication between the tactical and operational level.
Information from various external sources (e.g. published data, data prepared in the fixed infrastructure, sensor data, alerts and resource messages from linked C&C systems), and information created within IDIRA (observations, incidents, resource needs and offers, outcome from other IDIRA subsystems) can be visualized in layers on top of the map. Every user can compile a combination of information layers according to the actual needs. Details of the items depicted as icons in the map layers can be displayed, and information items owned by IDIRA COP can also be presented and filtered in list form. The layers can be configured during the set-up of an IDIRA instance (MICS), according to the available data sources and the nature of the disaster. Every layer is represented by a plug-in that manages the access and presentation of specific information and that is loaded during logging-in. The COP Web GUI is intended for tactical users in a control center, and for operational commanders using a PC with a stable network connection.
For operational users in the field, using a tablet, a native Android App is available. The IDIRA COP native client provides core functionality to IDIRA operational users - even while offline (no communication to IDIRA servers). Additionally, support functions are available, such as routing, initiating communication to other participants during an incident (using IDIRA Voice Communication subsystem) and sensor data gathering. The client periodically updates its local database with updated data from the server. The server logs any changes to the database in its “history_log” table. In the offline mode, all core functions are available, including map based browsing, and even posting of new information. In the case a server connection is available, this information is requested by the client periodically. If any changes are found, any affected data are synchronized with the server. The same is true for information gathered on the client (resource requests, observations). This is stored on the device until a server connection is available, and then sent to the IDIRA server
1.3.2.7 Incident and Resource Management
The IDIRA Incident & Resource Management subsystem is an integral part of the COP and comprises the handling of alerts and observations, the tracking of incidents and the definition of tasks for incident remedy. Resources in IDIRA are handled on a tactical level. Resource information can either be maintained by users in the IDIRA GUI, or shared and updated with connected C&C systems by exchanging EDXL RM messages.
An Alert is a message sent to IDIRA that requires prompt reaction by the tactical commander. Alerts are posted as CAP messages by connected systems like C&C or sensor integration systems, public alerting systems or messages generated by social media monitoring. Observations are reports on a situation (in EDXL SitRep format) that IDIRA users post on the Tablet or Web GUI.
Needs are formal requests for resources, posted by an operational user. The request is primarily addressed to the tactical commander but also visible to all other IDIRA users that can react by offering their capabilities.
Offers are resources in the field that may resolve needs. Offers can be posted via the GUI or automatically updated by connected C&C systems.
An Incident in IDIRA is an adverse event that causes destruction and/or requires response activities. Incident objects are created by the tactical user in COP, summarizing alerts, observations and needs from the field that concern a single event. That reduces the complexity of the common operational picture (one incident icon replaces several alert/observation/need icons). The single messages behind an incident can be displayed in the incident details. In addition, attributes can be added to the incident (e.g. event type, severity, status, etc.), and the event is tracked via the incident.
Tasks are missions to remedy an incident. They are assigned by the tactical commander to organisational units that perform the task autonomously and report the task status back to the tactical commander.
1.3.2.8 Multinational Resource Management (MRM)
In order to foster relief item exchange between organisations, the subsystem Multinational Resource Management has been developed. It consists of two parts: A Relief Item Catalogue and the web-platform IdiraMRM to request and exchange relief items. The Relief Item Catalogue is a web-based application that utilises a three-dimensional taxonomy to categorise relief items at a very fine-grained level.
The catalogue generates a specific relief item identification code, usable for organisations in their own applications and services. To this end, the catalogue is also exposed as a web service, providing the possibility to access the catalogue’s taxonomy in a machine-readable form.
The catalogue is used by IdiraMRM, a web platform for organisations to request and offer relief items in order to exchange them among each other on demand. An organisation in need of specific relief items can create a request on the platform, specifying the amount and location where the items are needed. Other organisations can respond to the request by offering their items to their specific conditions. In order to support organisations to find matching offers or needs, an intelligent algorithm is employed to automatically compare both entities. Matching offers or needs are subsequently recommended to the respective organisation. Figure 14 shows a screenshot of offers and needs registered on the web platform. Please refer for an extensive explanation of the IDIRA MRM subsystem to Deliverable D5.4.
1.3.2.9 Missing Person Tracing (MPT)
The IDIRA MPT system comprises a suite of tools, developed to support the registration of missed or found persons and the matching between different repositories.
The IDIRA Missing Person Tracing (MPT) web application is a registry for storing and interchanging data of missing persons, compliant with the PFIF specification (PFIF is an established open standard to exchange information on missing person). The registry is autonomous and can be synchronized with other PFIF compliant registries (current version 1.4). The missing person entries can be exported in RSS or XML format. The application is built on Java/GWT (Google Web Toolkit) and the twitter Bootstrap framework. The database of the application is PostgreSQL with the PostGIS extension in order to have GIS-enabled statistics.
Most of these features correspond to separate pages and are shown as links in the top navigation bar. The user can navigate to these pages from there. Through the registry and search pages, the users can go through the existing data and perform complex functions of filtering and searching of it.
In the registry page, the user is able to view in table format the registered persons with photo-thumbnails, a summary of the inserted note(s) and more details of the last inserted note. The displayed persons can be filtered using full name, first name, last name and the source of the record.
The aim of the MPT Android Application was to provide a fast and easy way to collect the information about missing persons in the field. The result is a wizard styled application that asks the user in several steps about the available information regarding the missing person. After the insertion of the data, a PFIF file is created and sent to the MPT Web application. The management of the MPT repository is not within the scope of the app - please use the MPT Web application for this.
Furthermore, a converter for one of the existing person tracing system (“Xenios” used by DKR-SN) was developed. It converts backup files of the system into the PFIF format, so that the data can be imported into the MPT-Web-App. An extensive explanation of the missing person tracing system can be found in D4.4.
1.3.2.10 Donation management
The aim of the Donation Management System is to help organisations to assess the damage in the affected area and to collect applications for donations from the affected people to plan their donation campaigns and thus contribute to a fair distribution of the collected donations.
This software assists the crises managers to plan and supervise the damage and needs assessment teams. These teams are visiting affected houses and persons, to collect information about the level of damage and help the people filling in applications for donations. For this work, the teams will be provided with tablet computers. The tablet software helps the teams to process their routes and provides the application in electronic form.
The assessment teams see the already completed sections (green) and the sections that are still requiring input data. This application is part of the fixed infrastructure or the MICS and can be distributed from there to the mobile devices of the assessment teams. The data gathered during the in-situ assessment is automatically transferred to the back-end system.
For further processing, all applications are editable and manageable with the central management app. Furthermore it provides the software an overview on all donations and a statistic on processed routes and applications.
Please see Deliverable D5.4 for an extensive presentation of the Donation Management suite .
1.3.2.11 Structured communication
Structured communication is an approach to address the need of multilingual information exchange, without requiring participants to have knowledge of the language of the addressee of the text. The structured communication is suitable for standard relief situations, such as situational reports on incidents, requests for cross-border assistance and aid offers. The approach uses pre-defined form elements and is flexible and extensible.
The Structured Communication tool is based on stateless client-server architecture with a RESTful API for information exchange. The form processing and translation capabilities are provided by a server side component. A client side component is divided into Editor GUI, Translation GUI and CAP Management UI and provides the functionality for altering and creating of forms. The structured communication supports common HTML5 form elements with predefined values like checkboxes or drop down fields.
The client functionality for the use of the system is divided into two functional UI components. The “translation UI” component to search for forms, fill in data and send the translated outcome to a web browser window or to an email address. The “form editor UI” component to Create, Read, Update and Delete (CRUD) the available forms as well as translate and sort the forms. Both components can be accessed over the same web based interface.
The web based user interface especially the form editor is optimised for desktop users. The Translation UI is useable on tablet size mobile devices (7” to 10” screen size). The translation functionality is also integrated in the IDIRA COP. From the IDIRA COP the user can access the structured communication tool and all available forms from the Toolset menu, e.g. using the “Observation” menu item. Please refer to D4.3 for further explanation of this subsystem.
1.3.2.12 Early Situational Awareness (ESA)
The ESA subsystem provides information on the current situation, regional and national characteristics and other useful topics. This information can be requested before the arrival and deployment in the affected area as well as during the operations in the field.
ESA uses mechanisms to classify and filter the information requested by the end users. For this purpose, IDIRA developed a back end web service that provides document classification and filtering mechanisms. This service was applied during the generation of the PDF report to include the filtered and classified information. Regarding the classification process, the service classifies (tags) different EDXL documents into pre-defined categories. Such categories are built taking into account the types of information that is commonly included in the EDXL format. In this context, an OWL (2) ontology is used to model the terminology. For the filtering, the engine performs a two-layer filtering of data by using a reasoning module that consists of an ontology reasoner and a rule engine. The reasoner is capable of managing the underlying ontological model, while the rule engine provides certain rule-based policies for the information filtering. The rule policies are expressed in terms of SWRL rules. In the first layer of filtering, the information is processed based on the role of the IDIRA user. Each role is aligned and connected with certain types of information (categories) that could be accessed (e.g. based on the access rights policy of each particular organisation). The relevance is defined through the conjunctive rules included in the ontology. Therefore, this layer allows IDIRA users to receive information conform to their roles and access rights.
The ESA toolset (see the following figure) has been integrated directly within the IDIRA COP. For each ESA report, different blocks with specific content can be selected by the user, e.g. a situation map, points of entry, disaster/incident/task descriptions, contact information, regional information. For the situation map, the user can choose map layers showing critical infrastructure or other background geo data. The selected data appears in the report which is provided in PDF format. This report can be downloaded as a file and viewed on any mobile device or shared via e-mail.
1.3.2.13 Exchange with legacy systems
IDIRA uses EDXL (Emergency Data Exchange Language) for the communication with external legacy systems (e.g. C&C systems) used by organizations which cooperate in disasters management, and to get information from existing alerting and disaster information systems (e.g. GDACS). This is achieved by means of the developed Inbound and Outbound Interoperability services, described at a conceptual level in the IDIRA architecture deliverable (D2.2) and from a detailed software design and perspective in the deliverable D4.1. Of course, it is supposed that external systems are able to provide, or consume the generated information using these standards, in order to interoperate with IDIRA.
All EDXL messages can be used alone or sent as payload of the EDXL-DE (distribution element) message structure, especially if particular distribution information or addressing mechanisms need to be used. Besides providing elements to specify the originator of the message (e.g. sender ID, sender role), and the distribution type (e.g. Actual, Exercise, etc), the EDXL-DE message structure contains elements that can be used when particular routing or addressing decisions should be taken.
EDXL derivatives have been successfully used for information exchange on Incidents (EDXL-CAP), Resources and Tasks (EDXL-RM) and for providing Situation Reports (EDXL-SitRep). During the IDIRA project three C&C systems were connected exemplary to IDIRA: Engage (by Satways), Jixel (by IES) and MobiKat (by Fraunhofer).
1.3.2.14 Sensor data integration
In large scale disaster operations, there is often a lack of information about the situation in the field. Sensor information can bring great benefit to the situational awareness allowing the commanders to take faster and better decisions. However, even if sensors have been deployed in the area of interest, the integration and the interpretation of raw sensor data remains a challenge due to the heterogeneity in the communication protocols and not standardized data formats. Also, sensors usually provide huge amounts of raw data that cannot provide intuitive deductions nor can be processed in real-time.
Following the IDIRA concept of interoperability, the Sensor Data Integration subsystem leverages open standards (e.g. OGC Sensor Observation Service) allowing the interoperable integration of sensor data sources. In the context of IDIRA and according to their deployment characteristics, the already integrated sensor data sources can be divided into two categories:
• IDIRA sensor systems (e.g. Davis Weather Station Wireless Vantage Pro2, sensordrones)
• external sensor data providers (e.g. Wedaal, Pegel online, wunderground service)
A detailed description and examples of how external sensor data sources can be integrated into IDIRA are provided in deliverables D3.1 and D3.4.
For the interpretation and transformation of raw sensor data into meaningful information and the effective presentation of it, the Sensor Data Integration subsystem consists of several back-end components plus a number of user interfaces. The Sensor Fusion Engine (SFE) is the core back-end component that has been developed. It is responsible for the knowledge discovery of raw sensor data and the alerting mechanism based on complex processing workflows. The sensor experts use the SFE management tools in order to monitor the input sensor data streams, define sensor data fusion applications and manage their lifecycle.
The sensor plugin in COP enables end users of the IDIRA system to access sensor related information in an intuitive and user-friendly format. Using this plugin, sensor data sources are visualized on maps and sensor measurements are presented through charts. Also, a basic filtering tool has been developed providing search capabilities of sensor measurements.
Similar to the concept of sensor inbound interoperability, the Sensor Data Integration subsystem provides also the Sensor Outbound Service, which is responsible for making integrated sensor data available to external systems.
1.3.2.15 Ad-hoc data integration
IDIRA facilitates the straightforward integration of the following external data, among them:
• data on health care facilities
• data for estimation of earth quake impacts
• OpenStreetMap (OSM, used as base map in the COP)
• general vector data
• contact data
• real-time locations of mobile operators
For these data categories, specific tools for processing, transformation and import into the main databases were implemented. The details on the integration mechanisms are presented in detail in deliverable D3.2.
1.3.2.16 Integration of Twitter-messages
A Twitter Inbound Service has been implemented to get alerts and warnings from Twitter channels. The service enriches the IDIRA services for interoperable Inbound / Outbound information exchange with external systems, with the aim to improve situation awareness of first responders before, in the immediate aftermath of a disaster, and at any time during the response phase.
The Twitter Inbound Service can be split into three main conceptual components:
1. A Twitter Interface component, in charge of retrieving new tweets from connected External Twitter Sources, using the Twitter Streaming API interface,
2. A Tweets Converter component, in charge of converting received tweets into standard EDXL-CAP messages, using predefined mapping and conversion rules and
3. A Storage Interface component, which represents the actual interface with the downstream IDIRA components for EDXL-CAP storing and handling.
Incoming tweets from configured Twitter accounts are converted into standard EDXL-CAP messages, to be consumed by downstream IDIRA components and, ultimately, by the end users through the COP GUI. Generated EDXL-CAP messages are also published as ATOM feeds by the Outbound EDXL Service of IDIRA, so that they can be consumed by interoperating external legacy systems.
The use of the Twitter Inbound Service prototype has been verified by connecting it to Twitter profiles of existing monitoring and alerting sources, namely GDACS and INGV, the Italian National Institute of Geophysics and Volcanology. Both sources are committed to the provision of earthquake related alerts. The service has been designed and implemented in such a way that it can be easily generalised for use with any kind of Twitter alerting sources.
The Twitter Inbound Service has been integrated, as proof of concept for the use of alerts coming from social media during emergencies, in the earthquake scenario run during the last large scale exercise of the project, in Greece. More details on the twitter Inbound Service are reported in Deliverable D4.5 (Concept and exemplary implementation of twitter inbound service).
1.3.2.17 EXODUS driven evacuation simulation
The EXODUS evacuation simulation tool is a rule based micro simulation tool capable of simulating the evacuation process of big populations from large and complex environments. In the IDIRA project, buildingEXODUS, which is a version of the EXODUS simulation tool specifically designed to model building evacuations, was adapted to model large scale urban and rural evacuation scenarios. This adapted version of EXODUS is called urbanEXODUS.
Various enhancements were made to enable urbanEXODUS to model large scale urban and rural areas. Those key enhancements are as follows:
• urbanEXODUS accepts geospatial vector data from OSM to generate a virtual representation of the affected region, defining in this way the area to evacuate.
• Urban travel speeds were adopted.
• The software was optimised to perform faster than in real time.
A web service was developed for urbanEXODUS to provide an easily accessible secure web interface (Evacuation Simulation Expert GUI), depicted in Figure 25. It supports SOAP and RESTful queries (a common network protocol respectively a programming paradigm for distributed systems) for the specification of simulation inputs, the execution of run simulations remotely on the server and for viewing simulation outputs in the IDIRA COP.
urbanEXODUS was also integrated with the COP and the chemical substance release simulation (ChemSim) model to provide interoperability between other disaster management components. This integration was achieved by utilising open standards (OGC WMS & WFS). It was thus made possible to integrate external sources of data within the evacuation simulation tool utilising the aforementioned open standards. The integration with the COP allowed the COP users to specify closed and inaccessible areas via the COP. The integration with the chemical simulation tool allows the import of the areas affected by chemicals as hazards within the evacuation simulation tool.
1.3.2.18 Chemical substance release simulation
Chemical Substance Release Simulation (ChemSim) is a web-based prediction tool targeted at operational and tactical commanders, supported by command and control centre staff. ChemSim provides simulation capabilities of potential release of chemical substance, including instantaneous and continuous release scenarios, BLEVE (boiling liquid expanding vapor explosion), JetFire and PoolFire effects. ChemSim integrated 2D visualisation enables effective and comprehensive interpretation of the hazard situation and provides also detailed animates of the cloud movement in time. The tool has multilingual capabilities, uses common dictionaries and typology to overcome the language barrier.
ChemSim platform provides a set of RESTfull web services, utilizing OGC WMS and WFS standards and enabling ad-hoc integration with GIS tools and third party applications. ChemSim integration into the COP is provided by a specialized plugin, enabling both visualisation of the scenario locations as well as display of the scenario parameters and its results. Within the IDIRA project, ChemSim was also integrated with the Exodus simulation platform, now providing no-go zone boundaries in case of potential evacuation.
1.3.2.19 Forest fire propagation simulator
The Forest Fire propagation simulator is an expert tool which is used in a web-based environment to forecast the possible movements of a fire-front based initially on single or multiple ignition points. The Fire Simulator engine requires fuel data for the area for the calculations to work. The simulation engine takes previous outputs and current weather information to provide the fire front position in the next time step. Due to the nature of the tool, a map was incorporated to allow experts to select the ignition points and visualize the output at each time step. Each output is saved in the simulator for later retrieval. The same output can be published to the COP. The simulator provides the IDIRA commanders with added decision support in the case of fire of where to place resources, indicators for future no-go areas for evacuation etc.
1.3.2.20 Road network based decision support tools
The multi-criteria routing service computes routes that fulfil specific requirements given by field commanders and vehicle operators. The service is based on a Postgres spatial database which contains the necessary information for the area under examination. Spatial information is handled by spatial commands. The PGRouting framework provides an efficient solution for the calculation of the shortest and the k-shortest paths between two points. In general, the functionality provided includes the following:
• K-shortest paths. The user selects the number of the desired paths and the system responds with depicting the paths on the screen. Information related to guidance instructions, the length of the route and so on is available in the provided interface.
• Simplest path. The system selects the simplest path among a set of paths. Actually, the simplest path is that including the smallest number of turns and junctions. Hence, this path could be selected to simplify travelling.
• K-simplest paths. It provides k paths that are rated as the simplest among the available solutions. The number k is chosen by the user in the provided interface.
1.3.2.21 Load balancing
Considering a finite number of resources available for handling post-emergency situations, as hospitals, rescue teams, etc. IDIRA provides a predictive scheme for optimising the load for each available resource. On the basis of the knowledge about all previous decisions of all users, the underlying model provides decision support to avoid congestion.
Each resource has specific characteristics retrieved by the underlying database management system like the resource location. For hospitals, the available number of beds for each triage category and for specific departments are crucial. The resources are going to be utilized by specific entities. For instance, entities could be injured persons. Each entity also has specific characteristics that will affect their distribution into the available resources. One important characteristic is the location of the entity. Patients may need specific treatments. These needs of patients are to be taken into account during distribution into the available hospitals.
In the adopted algorithm, for each entity, initially, a number of predictors, are selected. Accordingly, the appropriate resources are chosen. The resources selection depends on two parameters. The first is related to the distance between the resource and the entity based on the coordinates of the entity and the resource, respectively. If the distance is below a threshold, the resource is judged to be appropriate for the entity. The second parameter is related to the similarity between entities and resource characteristics. The similarity is calculated by a specific function that results in an estimate of the similarity for each characteristic of the entity and resources. We consider two types for characteristic values: a) numerical, b) nominal.
1.3.2.22 Reachability Optimized Positioning
For first responders the ability to communicate to each other is essential. The Reachability Optimized Positioning (ROP) tool brings together the tactical needs and the ability to communicate. It allows taking into account tactical aspects, as well as communication aspects when defining the best position of a commander in the field. ROP provides a simulation based model where communication is possible, and where potential positions for a Wireless Gateway could be located. Together with the information from the incidents, an optimal position for the field commanders can be defined, where on the one hand he can fulfil the tactical needs on site, and is able to communicate with other field commanders and tactical or strategic commanders. The simulation is based on a digital elevation and a digital surface model to predict the reachability of a Wireless Gateway. ROP allows viewing previous simulation results and triggering a new simulation at a specific position.
1.3.2.23 Optimal resource allocation
The optimal resource allocation service was developed for the optimal placement of resources before a disaster happens. Combining the features of resources, such as speed, and geographical characteristics of an AoI (Area of Interest), an optimal allocation is determined according to user requirements. A number of resources are available to be allocated in a specific area. The discussed resources are of specific type (e.g. ambulances). It is considered that the road network of the area has an orthogonal shape. The result of the proposed model is the optimal placement for each resource in order to meet pre-defined conditions. Resources of different types could be placed in different positions, covering different regions. The data required by the proposed model are spatial data that are stored in a spatial database. Spatial data define an objective view of the area.
Every resource has specific characteristics that affect the area it will cover. The following information is taken into account: a) Resource Type (e.g. vehicle, building, team), b) Crew or Personnel (it depends on the resource type), c) Maximum Speed, d) Maximum travel distance, e) Current location. For moving resources (i.e. vehicles and rescue teams), there is a maximum allowed response time. This means that the location of such resources should be optimal in order to respond in the minimum time. The information taken into consideration for the examined area is the following: a) Amenity type (e.g. schools, fuel stations, fire stations, hospitals, forests), b) area type (e.g. city, village, hamlet), c) roads and road segment characteristics (e.g. length, lanes number, one-way, maximum allowed speed), d) road type (e.g. highway, primary, secondary, tertiary or track).
The proposed approach is based on the so called Particle Swarm Optimization (PSO) algorithm. The steps of the proposed method are the following:
• At first, the area is split into a number of cells creating a grid.
• Second, a specific weight for every cell according to the underlying spatial information is defined.
• Third, the PSO algorithm is used for finding the best location of each resource in order to achieve the maximum coverage.
1.3.3 The operational capacity
The IDIRA solutions were tested and evaluated using specific scenarios (pandemic, flood, fire and earthquake) inside Europe. In the final stage of the project, it was discussed amongst the technical team and representatives of the user groups, whether the approach would be feasible for generalisation. A discussion of some of those aspects can be found in D7.1
Regarding the scenario, it was common understanding that the IDIRA approach is not restricted to any specific type of disaster, even though IT systems are generally highly dependent from electric power supply. As long as this precondition is available with a sufficient reliability at any relevant place of operation, it would work.
More important than the scenario question is the need to integrate the proposed interoperability concepts into the day-by-day business, i.e. into the command and control systems used by fire and rescue services and their operation centers. It is crucial to have the capability and the functions always available to let the operators learn how to deal with it (not only technical how to connect knowledge, but also regarding role models or user rights management). Only following this approach it would be likely that the framework concept would also work in disaster situations.
Although no specific performance assessment procedure was made within the project, it can be said that the IDIRA concept (applying existing standards and following an up-to-date software architectural design) is fully scalable regarding the number of users and organisations as well as regarding the regional extent of the situation and the number of incidents.
There should be a fixed information space infrastructure, preferably distributed over several countries in order to achieve reliability. This infrastructure would regularly gather basic data, such as geographical maps, resource information, roles and rights of organisations and users and meta-data for systems potentially to be connected in case of an event. An up-to-date server infrastructure will be able to handle any needed amount of data traffic that can be expected. Regarding the mobile infrastructure, it is assumed that a MICS-like component would be able to act as data hub for events on a regional level, e.g. comparable with flood events in the German Saxony region, earthquakes like in Italy or Greece, or forest fires. In case of a large affected area, it is expected that more than one MICS module could be used.
The IDIRA MICS concept aims at supporting multi-organisational and cross-national disaster responses. The response time for this kind of actions is rather days than minutes or few hours in normal emergency situations. If one thinks of the MICS concept as part of an existing, or as core of a new standardized EUCP or ERU module, it can be expected that the equipment and personnel would need at least several hours before starting to operate in the field. Considering this, two implications might be concluded: First, each country should have established a fixed information space infrastructure connected with the daily-in-use command and control systems at a safe place in order to be able to provide the needed regional data as soon as possible. Second, the number of mobile MICS components should be high enough to limit the transport time needed before deployment.
1.3.4 Recommendations
The recommendations derived from the IDIRA efforts can be found in the deliverables D7.1 D7.2 and D7.3. The recommendations address different targets, actors and channels:
• User organisations: It became obvious that the usage of the IDIRA system does neither impede existing procedures, nor the structures, which are proven to be effective in crises response actions. The system developed by this project supports any kind of large-scale scenario and is flexible to be deployed by any organisation. Legal aspects of exchanging data and the willingness of organisations to participate were considered to be the most important preconditions for deploying IDIRA-like systems. It was decided that currently and also within the near future the use of tablets should be considered only for the level of field unit commanders and higher, because the communication and task assignment on the scene is anticipated to be oral and personal, now and in the future. A further conclusion is that intensive training and education is needed to prepare responders and leaders for the usage of IT systems. The successful realization of training requires thorough planning and preparation. Two aspects are of foremost importance: the clear definition of the exercise scenario, and the familiarization of users with the equipment and the available software. Users on whatever level working with the system need to clearly understand the use and limits of the system’s modules. To ensure an efficient, rapid and flexible response, a special training programme for the users should be offered. The target group of project users is wide, including many different categories of experts, personnel involved in civil protection, and staff with a specific fields of responsibility.
• Policy decision makers on national and European level: As each European member state has not just its own organizational structure, but also cultural and administrative arrangements, the scope of the EU in crisis management should be designed to get the member states to a common understanding.
• Technical developers: MICS-compliant ICT systems are systems that are just compliant with the rules (namely, used standards and communication interfaces) which enable the possibility to exchange information with the IDIRA MICS or between each other, or provide functionalities similar to the ones provided by the MICS. Basic principles are architectural and design principles such as the SOA approach and loose-coupling of components, principles of modularity, extensibility and possibility to integrate external tools and data in a common, interoperable environment, and the use of a standards to ensure seamless data exchange and, as a consequence, to realise interoperability. Different deployment scenarios are possible for such service oriented architectures. These include cloud-based solutions, as well as the deployment of local infrastructures. The solution adopted in IDIRA considers a combined approach, with a cloud-based infrastructure, always online and always able to get relevant information from connected external systems, as well as a portable solution, deployable on the disaster site (as an additional EU Civil Protection module for example). This portable and locally deployable solution, represented by the MICS itself, is intended to cope with situations, where the traditional networking infrastructures are not available, mainly because they are destroyed or damaged.
• Public authorities responsible for tendering IT systems for purchase to deal with disaster response, command and control, and operation centers: Request an architecture and the interfaces to be used to be compliant with the IDIRA concept, whenever introducing a new software in the fire, rescue or civil protection domain.
• Standardization groups (e.g. for EDXL, PFIF, OSM, TSO): IDIRA has identified gaps regarding the standardization. In new versions of standardization documents, the recommendations provided by IDIRA should be considered.
1.3.5 Code of conduct for data sharing
The outcome of IDIRA was externally evaluated regarding the use of data and data privacy. Two recommendations were concluded in that external report:
• A code of conduct should be established to regulate the collection and use of personal data in emergency response situations such as those considered by IDIRA.
• Training in the use of the code of conduct should form a central part of training platforms like those of IDIRA.
In January 2012, the European Commission proposed a comprehensive reform of the European Data Protection legislation, which currently consists of the 1995 EU Data Protection Directive. Such a reform would be needed to strengthen online privacy rights in view of recent technological developments, but also to harmonize the implementation of the 1995 rules by the 27 Member States. To eliminate such varied implementation in the future, the Commission is proposing a single law for the entire EU, namely the Regulation on the protection of individuals with regard to the processing of personal data and on the free movement of such data (or, as it will also be known, the General Data Protection Regulation). Contrary to the legislative instrument of 1995, this Regulation will be directly applicable in all Member States and will not need separate national implementing measures (e.g. national data protection laws). The proposal does not draw any distinction between the rules applicable to the public or the private sector, for instance. The General Data Protection Regulation will be applicable to entities processing personal data, irrespective of their legal form. If the new General Data Protection Regulation is adopted as proposed, it will update and modernize the principles enshrined in the 1995 Data Protection Directive to guarantee privacy rights in the future.
The draft Data Protection Directive and Regulation could have potential adverse impacts on humanitarian activities within the EU, as well as in third countries or international organizations.
There are significant obstacles, which certain provisions of the Proposed Regulation would cause on certain humanitarian activities, requiring the collection, processing and transfer of data gathered by the different actors during and after a humanitarian crises and catastrophes.
• Lawfulness of processing and processing of special categories of personal data (Arts. 5-9 of the Proposed Regulation):
o The provisions concerning lawfulness of the processing itself, and of the content of personal data (including forensic data), could potentially block an important portion of key activities being carried out in humanitarian crises.
o They would also involve significant obstacles to the implementation of activities carried out by different acting organizations in humanitarian crises, such as tracing of missing persons, identification of human remains, tracing the families of the deceased and handing over to them human remains.
• Transfer of personal data to third countries or international organizations (Arts. 40-44 of the Proposed Regulation): The prohibition on transfers covered in the “Transfer of Personal Data to Third Countries or International Organizations” section of the Proposed Regulation could severely undermine the humanitarian activities, in particular, all the work carried out with the purpose of tracing missing persons and/or restoring family links in humanitarian crises.
The new EU regulation and existing Data Protection legislation require that authorities and organizations take effective measures of compliance. Authorities and organizations need to be sure that effective measures of compliance are taken by all actors processing personal data.
In a multinational disaster, third country nationals are also likely to be involved, be it as disaster response actors or as part of the affected population. In such cases, there might be a need to transfer personal data outside the EU. Therefore, a Code of conduct on personal data processing is seen as a key measure. The appropriate safeguards referred shall be provided for, in particular, by: “[…] standard data protection clauses adopted by the Commission (…); or […] an approved code of conduct […]”. Details on Code of Conducts can be found in Arts. 38 “Codes of Conduct” of the proposed regulation: “[…] code of conduct shall contain mechanisms for monitoring and ensuring compliance with it by the controllers or processors which undertake to apply it, without prejudice to the duties and powers of the supervisory authority […]”.
It is not very realistic to assume that all actors in a multinational disaster would have such a code of conduct. This lack would imply that there is no legally binding instrument and monitoring mechanism in place at all. Thus, Article 44 of the proposed regulation “Derogations for specific situation” plays an important role for IDIRA and its users:
“In the absence of an adequacy decision […], or of appropriate safeguards […], a transfer or a category of transfers […] may take place only on condition that:
(a) the subject of the data gathered has consented to the proposed transfer,[…]; or […]
(d) the transfer is necessary for important reasons of (…) public interest; or […]
(f) the transfer is necessary in order to protect the vital interests of the subject of the data gathered or of other persons […]; or […]
(h) the transfer which is not of large scale or frequent, is necessary for the purposes of legitimate interests pursued by the controller or the processor and where the controller or processor has assessed all the circumstances surrounding the data transfer operation or the set of data transfer operations and, where necessary, based on this assessment adduced suitable safeguards with respect to the protection of personal data;”
In order to meet the requirements of the proposed EU data protection regulation, a reference framework, a soft-version of a code of conduct, should be established, which the users of IDIRA-like systems need to comply with. Conformance of requirements could be met by Data Processing Code of Conduct of the respective actor or an agreement according to the reference framework of IDIRA.
Regarding the implementation of this concept in the context of interoperable IT systems for disaster response management the following steps are envisioned:
• In many of the European countries it is standard that the personnel and the commanding officers of rescue organisations and civil protection authorities are introduced to and pledged obeying the data privacy regulations and the standards for keeping specific classified data undisclosed. Thus, the general process of implementing and training a code of conduct is already in place. It only has to be enhanced taking into account possible large amounts of data and the risk of their abuse. The relevant national authorities have to define, which data under which circumstances may be shared with which third parties. This action is driven by politics and it can be expected that bi-lateral agreements between cooperating countries would be the fastest way to achieve a certain level of willingness to share relevant data.
• All software tools connected to a shared information space should contain and display the code of conduct as part or as supplement of the End-User Licence Agreement. Additionally, before activating appropriate inbound or outbound functionalities it would be requested that the user is explicitly informed of the risk and the restrictions regarding use or forwarding of data, and that he or she is obliged to confirm by an appropriate action.
• All activation and deactivation actions must be stored in a logging system, in order to be able to retrace modifications.
• There must be a process between all connected software systems that allows authentication, encryption and other common security mechanisms.
• From a practical point of view, many of the relevant acting personnel in the civil protection and disaster response domain might not be completely aware of the effects, chances and risks using shared digital information spaces amongst different organisations. It is concluded that the general knowledge about IT networks, data clouds, social media etc. has to be strengthened in the course of the training of the end-users, because without that any code of conduct would not have the intended impact.
1.3.6 Key conclusions from the final end-user advisory board meeting
Most important for the application and implementation of the MICS concept is a common understanding by all of the actors, when it comes to joint deployment. As each European member state has not just its own organizational structure, but also culture and administrative differences, the scope of the EU in crisis management should therefore be to get the member states to a common understanding. Common training activities within the framework of the EU Civil Protection Mechanism is just a starting point and has to be broadened.
To bring an IDIRA-like module into the field, it needs a group of specialists readily available and trained in deploying it and erecting the infrastructure in the field. The training of the staff should also include some training of trainers as the technical team may also have to instruct others on how the system works. The staff also needs to have basic logistic skills as the handout and the return of the tablet PC needs to be organized. If the MICS is the only system deployed and all the units rely on it, a failure is mission-critical because there won’t be any redundancy.
The end-user, independently from his or her level, needs some training – at least to get an idea of the possibilities and also the limitations of the provided tools. This training should be provided before a deployment. A regular repetition seems useful.
In general, users felt that the system and its components were ready to be deployed and reasonable user-friendly. Though some surrounding conditions described in the following passages can make access for users easier:
• Strategic/tactical level commanders: The various tools integrated in the system require properly trained staff to work with them. Crisis managers working with the system may not be aware of all the functions of the system. Or even worse, they are aware of the functions but cannot access them, because of being blocked by their commanding activities. To overcome this problem it would be better to have a specialist operating the COP frontend, while the crisis manager can concentrate on the inherent tasks. This concept to support the crisis manager by a certain number of specialised and dedicated personnel is quite normal in most staff structures, i.e. the full bandwidth of tools can only be used if the situation officer and/or the IT officer (or their subordinated persons) are able to use them.
• Operational level commanders: In exercises users felt confident with the system and considered that the prototypes on the tablet were easy to use and intuitive. Users on the operational level suggested to have a kind of communication officer to take over communication with the COP as information provided needs filtering. That way the commander of the tactical unit would have the opportunity to fulfil her or his commanding role and would have access to the information provided by the system. Another issue not directly found as a lesson learnt, but discussed in one of the interviews is the time line: Especially search and rescue units should be on-site within six hours. The probability of the MICS being deployed within this time frame is relatively low.
The participants of the end-user advisory board meeting appreciated the fact that the foreground of IDIRA is going to be used in the running FP7 and upcoming H2020 projects, as well as in some of the products of the members of the technical team.
It was particularly seen positively that IDIRA has used existing standards and has shown which steps in legacy systems and in future software projects have to be taken to be compliant with the IDIRA concept, and consequently to be interoperable. It is up to the end-users now to consider the recommendations in the process of tendering and purchasing new IT products for command and control in the day-by-day and disaster response business. The responsibility for organisational interoperability and the will to share data was seen at the level of political decision making.
Potential Impact:
1.4 Impact
1.4.1 General conclusions
The IDIRA project has contributed to strengthen the command and control capabilities throughout all the phases of the crisis management process:
• Prevention: In this phase IDIRA modules or approaches can contribute indirectly. Especially the integration of external expert systems like evacuation simulation, forest fire prediction and chemical pollution simulation into a common operational picture supports early situational awareness, that – in some cases can prevent or mitigate sever impacts caused by accidents or incidents.
• Preparedness: Command and control structures are highly important to manage disaster response actions effectively and efficiently. IDIRA provides a comprehensive concept (MICS) to improve the capabilities of those command and control structures regarding the provision with data and information. Additionally, a set of recommendations how plan and to proceed IT-specific training for the commanding personnel was elaborated and published.
• Response: Most of the IT-related recommendations, such as proposed standards for data transfer and information integration, address tool that more or less are connected with the concept of a common operational picture (COP), which is the core element of joint response actions. This information hub is able to provide decision support and resource systems with the needed data, and to share this data with other involved actors.
• Recovery: IDIRA has also shown, how modules like donation management or international resource management can be integrated within the MICS concept.
This also included efforts to combine simulation of response actions in the field and in the command and control centers with training of newly developed IT solutions or features. The findings and recommendations can be considered in all upcoming IT-focused projects.
One notable impact of IDIRA was the significant improvement of the bilateral understanding between the two domains civil protection/disaster management on the one hand side and software development/IT system integration on the other hand.
The IDIRA concept is designed for multi-organizational cooperation in multi-national contexts. It is difficult to specify the magnitude of the events IDIRA-MICS will be able to cope with. Basically, the IDIRA concept is expected to be able to cope with big disasters of any scale, providing a common working environment and the tools for publishing information, working on this information and consuming information. For this to be possible, the important precondition is that relevant information is made available, coming from connected external systems or ad-hoc integrated (e.g. disaster related information, maps, and so on). This precondition is normally well satisfied in some countries, for example across Europe, and a bit less in others, leading additional issues to be dealt with.
We think that the way the IDIRA architecture has been conceived can ensure the sustainability of the technological results after the end of the project. The IDIRA architecture is based on the SOA (Service Oriented Architecture) paradigm, and on a modular integration of different software components. A set of core services ensure data persistence, message based communication between components, taxonomy handling and handling of geographical layers. Around these core components, specific Interoperability services are designed and implemented for ensuring the connection with external systems, while a plugin based approach is adopted to integrate all the other services within the COP. This approach ensure that enhancements that imply the integration of new technologies can be applied in a modular way, without affecting the whole architecture. Just to stay within the example of the connection of IDIRA to social media, as explained previously a new service has been developed: this is just part of the Interoperability services set, and can be enabled/disabled without affecting or having to act on the rest of the services. Of course, further technical considerations could be made in case, for example, the social media service will be extended to the possibility to get data from manifold social media sources, including data coming from normal citizens’ social's accounts therefore adding new issues such as, for example, the need to filter and verify the accuracy of the information. But still, to support this kind of scenarios and deal with emergent approaches in disaster management, improvements could be needed only to specific services, e.g. by adding specific filtering and data mining capabilities.
1.4.2 Co-operation with other projects/programs
In the final phase of IDIRA, contacts were made with representatives of other projects dealing with interoperability and taxonomy issues. IDIRA partner IES, as WP4 leader and responsible of the tasks on standardization in WP7, participated to a specific meeting of the projects funded under the topic SEC-2012.5.1-1 (Analysis and identification of security systems and data set used by first responders and police authorities) of the last FP7 Security Call. The four projects (EPISECC, SECINCORE, SECTOR and REDIRNET) are all researching on topics relevant for IDIRA. In particular, the coordinated efforts on the definition of a common taxonomy for data sharing between emergency services fits well with the features of the system developed in IDIRA. The meeting was hosted by CISCO in Paris (France) on 24th November 2014 and outlined the areas where the efforts of the four projects will be coordinated. The experience gained in IDIRA was shared and included as a reference for the “Task Forces” on Taxonomy and on Standardization.
Particularly at the final End-user Advisory Board Meeting representatives from the following FP7 projects were present to learn about the outcome of IDIRA and how it can be used in the context of their specific work: EMERGENT, SALUS, SECINCORE, DRIVER, and EPISECC.
The main outcomes of IDIRA – MICS Architectural Reference and COP prototype, and Recommendations for harmonization & standardization – will be re-used in further FP7 projects DRIVER and EPISECC by the participating partners FRQ, IES and ORK-HQ.
Several IDIRA partners participate in the activities of the CRISMA project, as partners as well as observers in the course of the planned exercise. CNVVF will leverage on the IDIRA outcomes using them as basis for the interoperability features and standards to be included into the activities to be carried out within the projects AF3 (Advanced Forest Fire Fighting – FP7 SEC-2013.4.1-6) and NEXES (NEXt generation Emergency Services - selected for funding in the framework of the H2020-DRS-19-2014).
1.4.3 Dissemination
In the course of the project more than 50 presentations on workshops or conferences were done. All of them were dedicated to specific stakeholders from the domains of crisis management, software development or communication technology, respectively. Additional several videos were produced and were made publicly available. Together with a summarizing leaflet the deliverables with public dissemination status are available on the project home page www.idira.eu in order to be available for ongoing and upcoming projects and for those tendering or developing IT solutions for the crisis management domain.
1.4.4 Outlook
Based on the IDIRA partners’ experience, the use of standards and open technologies for information exchange has proven to be an effective approach for interoperability. Particularly, the IDIRA MICS has been designed as an information hub, providing Inbound and Outbound interfaces, and the rules to share specific information types by using suitable, standard data formats, together with a Web-based and modular environment for the interoperable integration of external data and tools. Therefore an integrated set of tools and a common information space were realised, to be used in cooperative, multinational disaster management scenarios. There is, surely, potential for further improvements in the adoption of specific standards, as well as the possibility to propose new ones: project’s partners intend to disseminate such findings, by bringing the IDIRA results, as far as standardisation and harmonisation topics are concerned, to the attention of existing standardisation bodies and communities. Finally, relevant showcases, concerning the connection and interoperable integration of existing systems and data with the IDIRA MICS have been realised during the project. This demonstrates how interoperability by adapting existing systems, following the model and guidelines proposed in IDIRA, can be realised in practice with a sustainable effort.
The community of technical developers has gotten a certain set of standards and a general architectural design that allows for producing interoperable software systems following simple rules designed by IDIRA. Those active in the field of standardization can now refer to specific proposals how to improve or enhance existing standards and can consider the need for new standards.
Public authorities and end-user organisations are now in the position to define the requirements for new software products or new versions of existing ones in order to make them compliant to the IDIRA MICS concept. It is of particular importance, that each of the proposed standards can be implemented and applied solitarily, i.e. it is not necessary to build the whole and complex IDIRA system once again before being interoperable. Rather, it would be sufficient, if step-by-step the used systems evolve towards interoperable components.
For policy decision makers, two main fields of action still remain. First, the willingness to share specific data amongst organisations and countries must be part of a common understanding and contracts including a certain code of conduct, at least on bilateral level. Without that, any technical solution solely stays a theoretical option. Second, independently from the question how much data is shared with whom, the technical implementation will be based on interfaces and specific architectures. If politics does not support the development and use of open standards, such as proposed by IDIRA, then the authorities will become (or stay) dependent of single, regionally dominating, private companies. This has obvious negative implications for the costs and for the flexibility regarding the use of IT systems in large-scale multi-national and multi-organisational disaster response actions.
List of Websites:
1.5 Contact data
Project web page (hosted by Fraunhofer IVI): www.idira.eu
List of participating organisations and their individual roles in the project:
• Fraunhofer Institute for Transportation and Infrastructure Systems, Germany: Coordinator; WP 5 leader (Interoperable Management); WP 8 leader (Administration); Technical developments
• Salzburg Research Forschungsgesellschaft m.b.H. Austria: WP 3 leader (Interoperable Communication)
• Frequentis AG, Austria: WP 2 leader (General architecture)
• Brimatech Services GmbH, Austria: WP 1 leader (State of the art); gathering feedback from user groups
• National And Kapodistrian University of Athens, Greece: Technical developments
• Organismos Antiseismikou Sxediasmoukai Prostasias (OASP) (EPPO: Earthquake Planning And Protection Organization), Greece: End-user
• Deutsches Rotes Kreuz Landesverband Sachsen e.V. Germany: End-user
• University of Greenwich, UK: Technical developments
• Intelligence for Environment and Security SRL (IES Solutions SRL), Italy: Technical coordinator; WP 4 leader (Information and data interoperability); Technical developments
• Österreichisches Rotes Kreuz, Austria: WP 6 leader (Training and exercises); End-user
• Ministry Of National Defence, Greece: WP 7 leader (Recommendations); End-user
• Ministero Dell'interno, Italy: End-user
• SATWAYS - Proionta Kai Ypiresies Tilematikis Diktyakon Kai Tilepikinoniakon Efarmogon Etairia Periorismenis Efthinis Epe, Greece: Technical developments
• TLP SPOL SRO, Czech Republic: Technical developments
• World Agency of Planetary Monitoring and Earthquake Risk Reduction, now International Centre for Earth Silulation , Switzerland: Technical developments
• OLYMPIAKI: Anaptixiaki Etairia Peripherias Ditikis Ellados Anonimi Etairia Ota, Greece: End-user
• KEMEA: Center for Security Studies, Greece: End-user
1.1 Executive summary
The IDIRA project conceptualized, developed, demonstrated and assessed approaches to facilitate coordination of large-scale disaster situations by improved interoperability. Several layers have been considered: from physical communication over semantic information interoperability up to the information interoperability on the application layer.
Main focus has been to provide a common operational picture for all stakeholders involved. A system for the exchange of the most relevant information during crises aftermath - among them information on incidents, alerts, resources, missing persons and urgent needs - has been designed and implemented. IDIRA helps to overcome language barriers and achieve technical interoperability.
Data exchange is based on standards as EDXL-RM, EDXL-SitRep and EDXL-CAP which are well known. It has been shown, that existing legacy command and control systems can easily be adopted to facilitate these standards. Semantical interoperability is achieved by using TSO codes. Further expert system can be connected to the developed mobile command and control structure, e.g. for the provision of simulation results to commanders on the scene. Basic tools for decision support (reachability, routing, load-balancing etc.), incident and resource management and the ad-hoc import of geographic data; contact data and sensor data are integrated. Communication hardware has been developed to provide ad-hoc broad-band connectivity within affected regions.
Situational awareness of foreign forces coming in the affected area is supported with a new tool that allows for efficient generation of reports describing the region, the situation and assigned tasks. The in-situ assessment of the needs families or households in general have is supported by a newly implemented toolbox.
The system development was undertaken as a close cooperation between end-users from various fields including firefighting, medical rescue, disaster relief organisations, defence and civil-military organizations, cooperating industrial partners, academia and research & development organisations.
Training and evaluation have served as the connecting elements between stakeholders and allowed for identification of improvement potential. Throughout the project, the developed solutions where systematically evaluated by the end-users concerning their potential to improve the effectiveness and efficiency of management of large-scale crises. After small-scale tests and training, the IDIRA system has been deployed and demonstrated in three large-scale exercises with scenarios related to pandemic, flood, earthquake and fire.
The End-User Advisory Board was an auxiliary body targeting on accompanying and facilitating the development of IDIRA throughout the whole project span of four years and constantly checked the tools developed from an end-user perspective. It was mainly formed by civil protection actors (such as authorities, agencies, international organizations, NGOs, responding units and single experts) not involved in the IDIRA consortium.
End-users concluded, that IDIRA provides a common working environment and useful tools for sharing information. Its deployment creates a high benefit in the management of large-scale disaster situations. The important precondition is that relevant information is made available and shared.
Due to European research funding, it was possible to undertake the needed research & development and demonstration efforts in a multi-national way. For a full exploration of the potential of interoperability in crises management, further activities related to research & development, standardisation and demonstration are needed, together with appropriated funding.
Project Context and Objectives:
1.2 Project context and main objectives
The starting point of IDIRA was the situation of periodically occurring large scale disasters in Europe, such as floods, forest fires, and earthquakes. Beginning from a certain extent, which can differ between regions and dependent on the impact, the response actions are based on multi-national and cross-organizational cooperation. One of the main questions in this context was, how to manage the efforts contributed by different countries/organizations effectively.
The IDIRA vison consisted of three basic elements:
• All acting organisations share a common operational picture.
• Linguistic and technical communication barriers must not constrain an effective resource management.
• Structures and procedures of information interchange are compatible.
Thus, the basic IDIRA ideas were to provide
• Infrastructure for central servers and services, ad hoc wireless communication, and a common operational picture,
• Guidelines for validation and adaptation of existing processes, description of successful rules and procedures, harmonization and standardization.
A special focus was on the development and demonstration of solutions that improve interoperability, among them:
• Exchange information about resources, incidents, observations, alerts, needs, missing persons etc.
• Access real-time simulations (fire propagation, release of chemicals, evacuation etc.)
• Exchange of messages in foreign languages
• Integrate and interpret sensor data
Additionally to the improvement of interoperability, technologies were developed related to:
• self-sufficient data and voice communication,
• Decision support,
• Donation management and
• Early situational awareness.
These technologies had to be evaluated in terms of usefulness for the management of large-scale crises. Guidelines for successful introduction of such solutions and for harmonisation of structures and procedures in crisis management were developed
The project started in 2011 with a systematic analysis of use cases and requirements. From the beginning end-users were involved.
As soon, as use cases and requirements were manifested (deliverables D1.1 D1.2 D1.3 and D2.1) the technical development team started drafting an expandable software architecture on the basis of well-known standards and approaches. A first draft of the IT architecture was concluded by the project team in August 2012 (deliverable D2.2). This architecture enables the forces involved in management of large-scale crises to coordinate their efforts. On the basis of this, first prototypical applications as well as the background technologies were developed. A first demonstration took place at the first project review meeting in Dresden in November 2012 which convinced end-users of the underlying concept and the prospective benefits. The technical development was then organised in iterative loops.
The End-User Advisory Board was officially inaugurated in an early phase of the project. Throughout the project, small-scale and large scale training exercises were organised and the developed solutions were demonstrated and tested. After successful testing of the components in small-scale exercises concerning correct functioning, they were deployed in large-scale exercises. Thereby, the IDIRA system and its components where evaluated regarding their usefulness and usability for management of large-scale crises.
During such training, the feedback from the end-users was gathered by means of survey instruments. These feedback was then considered in the following development cycle.
In the last step of the project, conclusions regarding technical harmonisation and procedures were collected, documented and aggregated by the entire project team.
Project Results:
1.3 Main results
1.3.1 General architecture and used data standards
The basic concept of the IDIRA architecture are:
• Loose coupling of components,
• Service-oriented architecture,
• Principles of modularity, extensibility and possibility to integrate external tools and data in a common, interoperable environment,
• Use of existing standards to ensure seamless data exchange and, as a consequence, to realise interoperability.
Different deployment scenarios are possible for such service oriented architectures. These include cloud-based solutions as well as the deployment of local infrastructures. The solution adopted in IDIRA considers a combined approach, with a cloud-based infrastructure, always online and always able to get relevant information from external systems, as well as a portable solution, deployable on the disaster site (as an additional EU Civil Protection module for example). This portable and locally deployable solution, represented by the MICS itself, is intended to cope especially with situations, where the traditional networking infrastructures are not available, mainly because they are destroyed or damaged.
With interoperability the most important focus of the project, the IDIRA system architecture has been built on very specific design and development principles, aimed at making it possible to communicate with existing, external legacy systems, as well as the integration of the different IDIRA tools and heterogeneous types of data coming from disparate sources.
Such design and development principles can be summarised in the choice of architectural patterns for ensuring loose-coupling of components, in a clear distinction between internal services and services used to enable the communication with external systems, and in the adoption of a modular implementation approach, which allows different functionalities to be plugged in or unplugged as needed.
Besides the choice of the above mentioned principles, the key enabler for the IDIRA interoperable architecture was, with no doubt, the choice to find and use the most suitable standards to consume or provide specific types of information.
For addressing the syntactical interoperability aspects, two main elements have been considered:
• The data model design in IDIRA was carried out taking into account specific actual or de-facto standard data formats to be used for representing each different type of information: in practical terms, this means that the different data structures used internally, are mapped as much as possible to the corresponding data formats, to be used for handling information that are exchanged or integrated from external systems. Hence, information on incidents, resources and tasks, as well as information on sensors, or results from external simulation systems, can be easily integrated and then processed within IDIRA
• The software interfaces and protocols for the communication with external systems, have always considered the use of open and not-proprietary, and standard whenever possible, communication interfaces
The use of standards for achieving interoperability at a semantic level has also been considered: although not the specific focus of the project, a possible approach has been implemented, which takes into account, as part of the IDIRA data model, the use of a common taxonomy, i.e. a shared dictionary of terms and definitions for emergency related information.
The final solutions adopted in IDIRA for implementing the above mentioned principles, will be presented in the following sub-sections by tackling the aspects listed below:
• Formal (actual) or informal (de-facto) standards used in IDIRA, together with their scope and the reasons at the basis of their choice
• Specific cases where the use of standards was not possible, and the reasons for this (e.g. missing standards for a given domain or information type)
By taking into account the different types of information and communication scenarios relevant during disaster management, we can distinguish between:
• Information areas where suitable actual or de-facto standards have been adopted for information exchange
• Information areas where non-standard solutions have been adopted, simply because standardised ways of sharing certain types of information are not available yet
Information exchange in IDIRA is mainly based on the following technological solutions:
• Communication technologies
o SOAP Web Services for synchronous communication between software components, both internally and with external systems
o REST web services,
o Publish-Subscribe mechanisms for internal, asynchronous communication between software components
o ATOM and RSS feeds for communication with external systems
o OGC WMS/WFS standards for integration of geographic layers and retrieval of geospatial data from multiple sources on the Internet
o OGC SOS standard for the integration of sensors measurements
• Data formats
o EDXL family of standards for the integration of alerts, incidents, tasks and resources related information
o OGC SensorML and O&M for what concerns integration of sensor data, observations and measurements by sensors
o PFIF for the synchronisation on information on missing persons between IDIRA Missing Person Tracing components, and external Missing Person Tracing systems
o Shapefiles and OSM XML formats for storing physical features such as roads or buildings in a geospatial vector data format
o OGC SLD to provide styling or visualisation of the map data
For all formats, standards and de-facto standards used in IDIRA the identified gaps or areas of improvement were classified using the following main categories:
• Missing fields of information in the available (standard or not) data formats
• Limits & inefficiencies
• Missing standards
• Harmonisation needs
By “Missing fields of information” we refer to situations where a given available data structure does not provide all the fields of information that could be needed in a real emergency situation. “Limits & inefficiencies” refers to situations where the use of certain capabilities was not found efficient, or put in evidence some drawbacks, while “Missing standards” highlights specific information exchange scenarios, domains or integration needs, for which well defined, not proprietary data structures are not available yet. Finally, with the term “harmonisation needs” we refer to the cases in which the use of specific approaches for information exchange could be made more efficient, by harmonising the way the information is organised and provided. The details and also the recommendations for improvements can be found in the publicly deliverable D7.3.
1.3.2 The IDIRA Modules: Components and examples for the demonstration of interoperability
In this section those components are listed and briefly described, which were developed, enhanced and/or used in IDIRA in order to test or to demonstrate the interoperability approaches proposed by the project. Some more details can be found in the mentioned deliverables and in the public report 8.5.
It was not the intention of IDIRA to elaborate highly sophisticated graphical user interfaces for the field or staff commanders or to enhance specific existing models or tools. Rather, all effort spent for the IDIRA modules was focused on the implementation and evaluation of existing standards to achieve interoperability. It is not easy to make interfaces and interoperability visible. That’s why some of the background software solutions of the project partners were used as a kind of counterpart of the general architecture and the IDIRA COP, i.e. as components to show, how the IDIRA approach is working, and to investigate, which steps are needed to make any similar systems interoperable following the IDIRA recommendations. Some of the visualisation tools were particularly needed to allow testing by and training of users.
1.3.2.1 Mobile Integrated Command and Control Structure (MICS)
The IDIRA MICS is a self-contained, system that can be transported to a disaster site. It can also be installed and operated when internet connections are broken or not available. The MICS unit can be a container with the MICS rack (Server), with PCs (work places for tactical users), Communication Field Relays (COFRs) and Wireless Gateways, and Tablets (for operational users in the field).
Complementary to the MICS - that is a physical entity (hardware plus installed software) - the Fixed Infrastructure is a service that can run anywhere (cloud computing) and is continuously updated. When the MICS is deployed, the relevant databases are copied from the Fixed Infrastructure to the MICS, so that the MICS is up to date.
The MICS server has installed the entire required software environment together with the configured IDIRA modules. When the MICS is deployed, only the databases need to be updated from the Fixed Infrastructure and following the MICS can be shipped. The MICS server rack contains two Windows servers, an uninterrupted power supply, a network switch and a router. Some subsystems are encapsulated in virtual machines using Ubuntu Linux.
A switch is equipped in the MICS to interconnect the two servers and clients for accessing the COP. Server 1 uses the Windows operating system and provides the COP and the database. In addition to this machine, three virtual Ubuntu machines are running, where two are reserved for further usage and one is running the Asterisk server for IDIRA voice communication. Server 2 uses the Windows operating system and acts as fall back for Server 1. The three Ubuntu virtual machines are used for dedicated services and databases. More details on the MICS are explained in Deliverable D5.5 and D7.2.
1.3.2.2 Wireless Gateway
A working broadband communication network is needed to use the IDIRA system within a disaster area. In the case of a break-down of public internet infrastructure, a private mesh net can be established, using the IDIRA Communication Field Relays (COFRs), Wireless Gateways (WGWs), Mobile Broadband Extender (MBE) and Mobile Broadband Multiplexer (MBM). This hardware can supply WLAN coverage at the hot spots of the response activities.
The MICS will be shipped with WGWs, COFRs and MBMs to establish an independent communication network between on-site field commanders and the MICS. The WGWs can be mounted on any pre-existing infrastructure or on poles provided with the MICS. It is used to establish links between different on-site operations and provides WLAN connectivity for the field commanders. The WGWs form an ad-hoc meshed backbone network in the operational area. Further it provides a local wireless cloud via an Omni antenna.
1.3.2.3 Communication Field Relay
The Communication Field Relay (COFR) is installed together with the WGW. The COFR could offer offline functionality, and allows connecting different uplink technologies and PCs or networks of field units to the communication network. The COFR prototype is shown in Figure 4. The functional blocks are shown in Figure 5. More details about the WGW and COFR can be found in IDIRA deliverable D3.1.
1.3.2.4 Mobile Broadband Extender
The Mobile Broadband Extender (MBE) provides a 3G uplink in areas where only a weak 3G signal is present that would not allow using the 3G network with out-of-stock hardware. The MBE consists of a rotatable 3G antenna. The antenna is automatically aligned towards the 3G pole with the highest signal strength. The self-alignment is controlled by an embedded computer. The MBE provides a LAN interface to connect end devices of the first responders to the provided Mobile Broadband Multiplexer (MBM). Compared to the MBE, the MBM combines three rotatable 3G antennas into one casing. This allows using three independent networks from three different 3G providers. These networks can be combined to increase the bandwidth of the Internet connection. Further, the connection is very stable as if one or two provider fail the Internet connection is still operational. The MBM uses the Multipath TCP protocol in combination with a VPN tunnel to combine the connectivity of the three providers towards one common connection.
1.3.2.5 Voice communication (WebTalk)
Direct communication between the different responders and with the tactical commander is essential in a crisis situation. The usual communication channels (digital/analogue radio, mobile phones) are sometimes not suitable in an international disaster response situation due to incompatible radio protocols or missing or damaged radio infrastructure. The IDIRA Voice Communication subsystem is intended to bridge the communication gap between IDIRA users in these cases. IDIRA uses internet connections or the WGW/COFR network for voice and data communication.
The IDIRA Voice Communication subsystem enables Voice over Internet Protocol (VoIP) communication, instant messaging and phone conferencing between IDIRA users (Tablet clients and Web client). Every item created in IDIRA (e.g. observation, incident, resource) references to the item’s owner and allows contacting him directly. Using instant messages, a link to the item is automatically inserted and directly leads to the map position and details of the object.
The technical solution consists of a SIP server (Asterisk) managing the connection handling and the instant messaging, a GUI component (WebTalk) for the user interaction and the Web-RTC features built-in in the browser (Google Chrome) of the Web GUI. The Tablet client uses a native SIP client providing almost the same features and using the same server interfaces.
A detailed documentation of the Voice Communication Subsystem is provided in deliverable D3.3.
1.3.2.6 IDIRA Common Operational Picture (COP)
The COP subsystem provides a comprehensive picture of the current situation in a geographical context. It enables an up-to-date situational awareness for all involved units and real-time communication between the tactical and operational level.
Information from various external sources (e.g. published data, data prepared in the fixed infrastructure, sensor data, alerts and resource messages from linked C&C systems), and information created within IDIRA (observations, incidents, resource needs and offers, outcome from other IDIRA subsystems) can be visualized in layers on top of the map. Every user can compile a combination of information layers according to the actual needs. Details of the items depicted as icons in the map layers can be displayed, and information items owned by IDIRA COP can also be presented and filtered in list form. The layers can be configured during the set-up of an IDIRA instance (MICS), according to the available data sources and the nature of the disaster. Every layer is represented by a plug-in that manages the access and presentation of specific information and that is loaded during logging-in. The COP Web GUI is intended for tactical users in a control center, and for operational commanders using a PC with a stable network connection.
For operational users in the field, using a tablet, a native Android App is available. The IDIRA COP native client provides core functionality to IDIRA operational users - even while offline (no communication to IDIRA servers). Additionally, support functions are available, such as routing, initiating communication to other participants during an incident (using IDIRA Voice Communication subsystem) and sensor data gathering. The client periodically updates its local database with updated data from the server. The server logs any changes to the database in its “history_log” table. In the offline mode, all core functions are available, including map based browsing, and even posting of new information. In the case a server connection is available, this information is requested by the client periodically. If any changes are found, any affected data are synchronized with the server. The same is true for information gathered on the client (resource requests, observations). This is stored on the device until a server connection is available, and then sent to the IDIRA server
1.3.2.7 Incident and Resource Management
The IDIRA Incident & Resource Management subsystem is an integral part of the COP and comprises the handling of alerts and observations, the tracking of incidents and the definition of tasks for incident remedy. Resources in IDIRA are handled on a tactical level. Resource information can either be maintained by users in the IDIRA GUI, or shared and updated with connected C&C systems by exchanging EDXL RM messages.
An Alert is a message sent to IDIRA that requires prompt reaction by the tactical commander. Alerts are posted as CAP messages by connected systems like C&C or sensor integration systems, public alerting systems or messages generated by social media monitoring. Observations are reports on a situation (in EDXL SitRep format) that IDIRA users post on the Tablet or Web GUI.
Needs are formal requests for resources, posted by an operational user. The request is primarily addressed to the tactical commander but also visible to all other IDIRA users that can react by offering their capabilities.
Offers are resources in the field that may resolve needs. Offers can be posted via the GUI or automatically updated by connected C&C systems.
An Incident in IDIRA is an adverse event that causes destruction and/or requires response activities. Incident objects are created by the tactical user in COP, summarizing alerts, observations and needs from the field that concern a single event. That reduces the complexity of the common operational picture (one incident icon replaces several alert/observation/need icons). The single messages behind an incident can be displayed in the incident details. In addition, attributes can be added to the incident (e.g. event type, severity, status, etc.), and the event is tracked via the incident.
Tasks are missions to remedy an incident. They are assigned by the tactical commander to organisational units that perform the task autonomously and report the task status back to the tactical commander.
1.3.2.8 Multinational Resource Management (MRM)
In order to foster relief item exchange between organisations, the subsystem Multinational Resource Management has been developed. It consists of two parts: A Relief Item Catalogue and the web-platform IdiraMRM to request and exchange relief items. The Relief Item Catalogue is a web-based application that utilises a three-dimensional taxonomy to categorise relief items at a very fine-grained level.
The catalogue generates a specific relief item identification code, usable for organisations in their own applications and services. To this end, the catalogue is also exposed as a web service, providing the possibility to access the catalogue’s taxonomy in a machine-readable form.
The catalogue is used by IdiraMRM, a web platform for organisations to request and offer relief items in order to exchange them among each other on demand. An organisation in need of specific relief items can create a request on the platform, specifying the amount and location where the items are needed. Other organisations can respond to the request by offering their items to their specific conditions. In order to support organisations to find matching offers or needs, an intelligent algorithm is employed to automatically compare both entities. Matching offers or needs are subsequently recommended to the respective organisation. Figure 14 shows a screenshot of offers and needs registered on the web platform. Please refer for an extensive explanation of the IDIRA MRM subsystem to Deliverable D5.4.
1.3.2.9 Missing Person Tracing (MPT)
The IDIRA MPT system comprises a suite of tools, developed to support the registration of missed or found persons and the matching between different repositories.
The IDIRA Missing Person Tracing (MPT) web application is a registry for storing and interchanging data of missing persons, compliant with the PFIF specification (PFIF is an established open standard to exchange information on missing person). The registry is autonomous and can be synchronized with other PFIF compliant registries (current version 1.4). The missing person entries can be exported in RSS or XML format. The application is built on Java/GWT (Google Web Toolkit) and the twitter Bootstrap framework. The database of the application is PostgreSQL with the PostGIS extension in order to have GIS-enabled statistics.
Most of these features correspond to separate pages and are shown as links in the top navigation bar. The user can navigate to these pages from there. Through the registry and search pages, the users can go through the existing data and perform complex functions of filtering and searching of it.
In the registry page, the user is able to view in table format the registered persons with photo-thumbnails, a summary of the inserted note(s) and more details of the last inserted note. The displayed persons can be filtered using full name, first name, last name and the source of the record.
The aim of the MPT Android Application was to provide a fast and easy way to collect the information about missing persons in the field. The result is a wizard styled application that asks the user in several steps about the available information regarding the missing person. After the insertion of the data, a PFIF file is created and sent to the MPT Web application. The management of the MPT repository is not within the scope of the app - please use the MPT Web application for this.
Furthermore, a converter for one of the existing person tracing system (“Xenios” used by DKR-SN) was developed. It converts backup files of the system into the PFIF format, so that the data can be imported into the MPT-Web-App. An extensive explanation of the missing person tracing system can be found in D4.4.
1.3.2.10 Donation management
The aim of the Donation Management System is to help organisations to assess the damage in the affected area and to collect applications for donations from the affected people to plan their donation campaigns and thus contribute to a fair distribution of the collected donations.
This software assists the crises managers to plan and supervise the damage and needs assessment teams. These teams are visiting affected houses and persons, to collect information about the level of damage and help the people filling in applications for donations. For this work, the teams will be provided with tablet computers. The tablet software helps the teams to process their routes and provides the application in electronic form.
The assessment teams see the already completed sections (green) and the sections that are still requiring input data. This application is part of the fixed infrastructure or the MICS and can be distributed from there to the mobile devices of the assessment teams. The data gathered during the in-situ assessment is automatically transferred to the back-end system.
For further processing, all applications are editable and manageable with the central management app. Furthermore it provides the software an overview on all donations and a statistic on processed routes and applications.
Please see Deliverable D5.4 for an extensive presentation of the Donation Management suite .
1.3.2.11 Structured communication
Structured communication is an approach to address the need of multilingual information exchange, without requiring participants to have knowledge of the language of the addressee of the text. The structured communication is suitable for standard relief situations, such as situational reports on incidents, requests for cross-border assistance and aid offers. The approach uses pre-defined form elements and is flexible and extensible.
The Structured Communication tool is based on stateless client-server architecture with a RESTful API for information exchange. The form processing and translation capabilities are provided by a server side component. A client side component is divided into Editor GUI, Translation GUI and CAP Management UI and provides the functionality for altering and creating of forms. The structured communication supports common HTML5 form elements with predefined values like checkboxes or drop down fields.
The client functionality for the use of the system is divided into two functional UI components. The “translation UI” component to search for forms, fill in data and send the translated outcome to a web browser window or to an email address. The “form editor UI” component to Create, Read, Update and Delete (CRUD) the available forms as well as translate and sort the forms. Both components can be accessed over the same web based interface.
The web based user interface especially the form editor is optimised for desktop users. The Translation UI is useable on tablet size mobile devices (7” to 10” screen size). The translation functionality is also integrated in the IDIRA COP. From the IDIRA COP the user can access the structured communication tool and all available forms from the Toolset menu, e.g. using the “Observation” menu item. Please refer to D4.3 for further explanation of this subsystem.
1.3.2.12 Early Situational Awareness (ESA)
The ESA subsystem provides information on the current situation, regional and national characteristics and other useful topics. This information can be requested before the arrival and deployment in the affected area as well as during the operations in the field.
ESA uses mechanisms to classify and filter the information requested by the end users. For this purpose, IDIRA developed a back end web service that provides document classification and filtering mechanisms. This service was applied during the generation of the PDF report to include the filtered and classified information. Regarding the classification process, the service classifies (tags) different EDXL documents into pre-defined categories. Such categories are built taking into account the types of information that is commonly included in the EDXL format. In this context, an OWL (2) ontology is used to model the terminology. For the filtering, the engine performs a two-layer filtering of data by using a reasoning module that consists of an ontology reasoner and a rule engine. The reasoner is capable of managing the underlying ontological model, while the rule engine provides certain rule-based policies for the information filtering. The rule policies are expressed in terms of SWRL rules. In the first layer of filtering, the information is processed based on the role of the IDIRA user. Each role is aligned and connected with certain types of information (categories) that could be accessed (e.g. based on the access rights policy of each particular organisation). The relevance is defined through the conjunctive rules included in the ontology. Therefore, this layer allows IDIRA users to receive information conform to their roles and access rights.
The ESA toolset (see the following figure) has been integrated directly within the IDIRA COP. For each ESA report, different blocks with specific content can be selected by the user, e.g. a situation map, points of entry, disaster/incident/task descriptions, contact information, regional information. For the situation map, the user can choose map layers showing critical infrastructure or other background geo data. The selected data appears in the report which is provided in PDF format. This report can be downloaded as a file and viewed on any mobile device or shared via e-mail.
1.3.2.13 Exchange with legacy systems
IDIRA uses EDXL (Emergency Data Exchange Language) for the communication with external legacy systems (e.g. C&C systems) used by organizations which cooperate in disasters management, and to get information from existing alerting and disaster information systems (e.g. GDACS). This is achieved by means of the developed Inbound and Outbound Interoperability services, described at a conceptual level in the IDIRA architecture deliverable (D2.2) and from a detailed software design and perspective in the deliverable D4.1. Of course, it is supposed that external systems are able to provide, or consume the generated information using these standards, in order to interoperate with IDIRA.
All EDXL messages can be used alone or sent as payload of the EDXL-DE (distribution element) message structure, especially if particular distribution information or addressing mechanisms need to be used. Besides providing elements to specify the originator of the message (e.g. sender ID, sender role), and the distribution type (e.g. Actual, Exercise, etc), the EDXL-DE message structure contains elements that can be used when particular routing or addressing decisions should be taken.
EDXL derivatives have been successfully used for information exchange on Incidents (EDXL-CAP), Resources and Tasks (EDXL-RM) and for providing Situation Reports (EDXL-SitRep). During the IDIRA project three C&C systems were connected exemplary to IDIRA: Engage (by Satways), Jixel (by IES) and MobiKat (by Fraunhofer).
1.3.2.14 Sensor data integration
In large scale disaster operations, there is often a lack of information about the situation in the field. Sensor information can bring great benefit to the situational awareness allowing the commanders to take faster and better decisions. However, even if sensors have been deployed in the area of interest, the integration and the interpretation of raw sensor data remains a challenge due to the heterogeneity in the communication protocols and not standardized data formats. Also, sensors usually provide huge amounts of raw data that cannot provide intuitive deductions nor can be processed in real-time.
Following the IDIRA concept of interoperability, the Sensor Data Integration subsystem leverages open standards (e.g. OGC Sensor Observation Service) allowing the interoperable integration of sensor data sources. In the context of IDIRA and according to their deployment characteristics, the already integrated sensor data sources can be divided into two categories:
• IDIRA sensor systems (e.g. Davis Weather Station Wireless Vantage Pro2, sensordrones)
• external sensor data providers (e.g. Wedaal, Pegel online, wunderground service)
A detailed description and examples of how external sensor data sources can be integrated into IDIRA are provided in deliverables D3.1 and D3.4.
For the interpretation and transformation of raw sensor data into meaningful information and the effective presentation of it, the Sensor Data Integration subsystem consists of several back-end components plus a number of user interfaces. The Sensor Fusion Engine (SFE) is the core back-end component that has been developed. It is responsible for the knowledge discovery of raw sensor data and the alerting mechanism based on complex processing workflows. The sensor experts use the SFE management tools in order to monitor the input sensor data streams, define sensor data fusion applications and manage their lifecycle.
The sensor plugin in COP enables end users of the IDIRA system to access sensor related information in an intuitive and user-friendly format. Using this plugin, sensor data sources are visualized on maps and sensor measurements are presented through charts. Also, a basic filtering tool has been developed providing search capabilities of sensor measurements.
Similar to the concept of sensor inbound interoperability, the Sensor Data Integration subsystem provides also the Sensor Outbound Service, which is responsible for making integrated sensor data available to external systems.
1.3.2.15 Ad-hoc data integration
IDIRA facilitates the straightforward integration of the following external data, among them:
• data on health care facilities
• data for estimation of earth quake impacts
• OpenStreetMap (OSM, used as base map in the COP)
• general vector data
• contact data
• real-time locations of mobile operators
For these data categories, specific tools for processing, transformation and import into the main databases were implemented. The details on the integration mechanisms are presented in detail in deliverable D3.2.
1.3.2.16 Integration of Twitter-messages
A Twitter Inbound Service has been implemented to get alerts and warnings from Twitter channels. The service enriches the IDIRA services for interoperable Inbound / Outbound information exchange with external systems, with the aim to improve situation awareness of first responders before, in the immediate aftermath of a disaster, and at any time during the response phase.
The Twitter Inbound Service can be split into three main conceptual components:
1. A Twitter Interface component, in charge of retrieving new tweets from connected External Twitter Sources, using the Twitter Streaming API interface,
2. A Tweets Converter component, in charge of converting received tweets into standard EDXL-CAP messages, using predefined mapping and conversion rules and
3. A Storage Interface component, which represents the actual interface with the downstream IDIRA components for EDXL-CAP storing and handling.
Incoming tweets from configured Twitter accounts are converted into standard EDXL-CAP messages, to be consumed by downstream IDIRA components and, ultimately, by the end users through the COP GUI. Generated EDXL-CAP messages are also published as ATOM feeds by the Outbound EDXL Service of IDIRA, so that they can be consumed by interoperating external legacy systems.
The use of the Twitter Inbound Service prototype has been verified by connecting it to Twitter profiles of existing monitoring and alerting sources, namely GDACS and INGV, the Italian National Institute of Geophysics and Volcanology. Both sources are committed to the provision of earthquake related alerts. The service has been designed and implemented in such a way that it can be easily generalised for use with any kind of Twitter alerting sources.
The Twitter Inbound Service has been integrated, as proof of concept for the use of alerts coming from social media during emergencies, in the earthquake scenario run during the last large scale exercise of the project, in Greece. More details on the twitter Inbound Service are reported in Deliverable D4.5 (Concept and exemplary implementation of twitter inbound service).
1.3.2.17 EXODUS driven evacuation simulation
The EXODUS evacuation simulation tool is a rule based micro simulation tool capable of simulating the evacuation process of big populations from large and complex environments. In the IDIRA project, buildingEXODUS, which is a version of the EXODUS simulation tool specifically designed to model building evacuations, was adapted to model large scale urban and rural evacuation scenarios. This adapted version of EXODUS is called urbanEXODUS.
Various enhancements were made to enable urbanEXODUS to model large scale urban and rural areas. Those key enhancements are as follows:
• urbanEXODUS accepts geospatial vector data from OSM to generate a virtual representation of the affected region, defining in this way the area to evacuate.
• Urban travel speeds were adopted.
• The software was optimised to perform faster than in real time.
A web service was developed for urbanEXODUS to provide an easily accessible secure web interface (Evacuation Simulation Expert GUI), depicted in Figure 25. It supports SOAP and RESTful queries (a common network protocol respectively a programming paradigm for distributed systems) for the specification of simulation inputs, the execution of run simulations remotely on the server and for viewing simulation outputs in the IDIRA COP.
urbanEXODUS was also integrated with the COP and the chemical substance release simulation (ChemSim) model to provide interoperability between other disaster management components. This integration was achieved by utilising open standards (OGC WMS & WFS). It was thus made possible to integrate external sources of data within the evacuation simulation tool utilising the aforementioned open standards. The integration with the COP allowed the COP users to specify closed and inaccessible areas via the COP. The integration with the chemical simulation tool allows the import of the areas affected by chemicals as hazards within the evacuation simulation tool.
1.3.2.18 Chemical substance release simulation
Chemical Substance Release Simulation (ChemSim) is a web-based prediction tool targeted at operational and tactical commanders, supported by command and control centre staff. ChemSim provides simulation capabilities of potential release of chemical substance, including instantaneous and continuous release scenarios, BLEVE (boiling liquid expanding vapor explosion), JetFire and PoolFire effects. ChemSim integrated 2D visualisation enables effective and comprehensive interpretation of the hazard situation and provides also detailed animates of the cloud movement in time. The tool has multilingual capabilities, uses common dictionaries and typology to overcome the language barrier.
ChemSim platform provides a set of RESTfull web services, utilizing OGC WMS and WFS standards and enabling ad-hoc integration with GIS tools and third party applications. ChemSim integration into the COP is provided by a specialized plugin, enabling both visualisation of the scenario locations as well as display of the scenario parameters and its results. Within the IDIRA project, ChemSim was also integrated with the Exodus simulation platform, now providing no-go zone boundaries in case of potential evacuation.
1.3.2.19 Forest fire propagation simulator
The Forest Fire propagation simulator is an expert tool which is used in a web-based environment to forecast the possible movements of a fire-front based initially on single or multiple ignition points. The Fire Simulator engine requires fuel data for the area for the calculations to work. The simulation engine takes previous outputs and current weather information to provide the fire front position in the next time step. Due to the nature of the tool, a map was incorporated to allow experts to select the ignition points and visualize the output at each time step. Each output is saved in the simulator for later retrieval. The same output can be published to the COP. The simulator provides the IDIRA commanders with added decision support in the case of fire of where to place resources, indicators for future no-go areas for evacuation etc.
1.3.2.20 Road network based decision support tools
The multi-criteria routing service computes routes that fulfil specific requirements given by field commanders and vehicle operators. The service is based on a Postgres spatial database which contains the necessary information for the area under examination. Spatial information is handled by spatial commands. The PGRouting framework provides an efficient solution for the calculation of the shortest and the k-shortest paths between two points. In general, the functionality provided includes the following:
• K-shortest paths. The user selects the number of the desired paths and the system responds with depicting the paths on the screen. Information related to guidance instructions, the length of the route and so on is available in the provided interface.
• Simplest path. The system selects the simplest path among a set of paths. Actually, the simplest path is that including the smallest number of turns and junctions. Hence, this path could be selected to simplify travelling.
• K-simplest paths. It provides k paths that are rated as the simplest among the available solutions. The number k is chosen by the user in the provided interface.
1.3.2.21 Load balancing
Considering a finite number of resources available for handling post-emergency situations, as hospitals, rescue teams, etc. IDIRA provides a predictive scheme for optimising the load for each available resource. On the basis of the knowledge about all previous decisions of all users, the underlying model provides decision support to avoid congestion.
Each resource has specific characteristics retrieved by the underlying database management system like the resource location. For hospitals, the available number of beds for each triage category and for specific departments are crucial. The resources are going to be utilized by specific entities. For instance, entities could be injured persons. Each entity also has specific characteristics that will affect their distribution into the available resources. One important characteristic is the location of the entity. Patients may need specific treatments. These needs of patients are to be taken into account during distribution into the available hospitals.
In the adopted algorithm, for each entity, initially, a number of predictors, are selected. Accordingly, the appropriate resources are chosen. The resources selection depends on two parameters. The first is related to the distance between the resource and the entity based on the coordinates of the entity and the resource, respectively. If the distance is below a threshold, the resource is judged to be appropriate for the entity. The second parameter is related to the similarity between entities and resource characteristics. The similarity is calculated by a specific function that results in an estimate of the similarity for each characteristic of the entity and resources. We consider two types for characteristic values: a) numerical, b) nominal.
1.3.2.22 Reachability Optimized Positioning
For first responders the ability to communicate to each other is essential. The Reachability Optimized Positioning (ROP) tool brings together the tactical needs and the ability to communicate. It allows taking into account tactical aspects, as well as communication aspects when defining the best position of a commander in the field. ROP provides a simulation based model where communication is possible, and where potential positions for a Wireless Gateway could be located. Together with the information from the incidents, an optimal position for the field commanders can be defined, where on the one hand he can fulfil the tactical needs on site, and is able to communicate with other field commanders and tactical or strategic commanders. The simulation is based on a digital elevation and a digital surface model to predict the reachability of a Wireless Gateway. ROP allows viewing previous simulation results and triggering a new simulation at a specific position.
1.3.2.23 Optimal resource allocation
The optimal resource allocation service was developed for the optimal placement of resources before a disaster happens. Combining the features of resources, such as speed, and geographical characteristics of an AoI (Area of Interest), an optimal allocation is determined according to user requirements. A number of resources are available to be allocated in a specific area. The discussed resources are of specific type (e.g. ambulances). It is considered that the road network of the area has an orthogonal shape. The result of the proposed model is the optimal placement for each resource in order to meet pre-defined conditions. Resources of different types could be placed in different positions, covering different regions. The data required by the proposed model are spatial data that are stored in a spatial database. Spatial data define an objective view of the area.
Every resource has specific characteristics that affect the area it will cover. The following information is taken into account: a) Resource Type (e.g. vehicle, building, team), b) Crew or Personnel (it depends on the resource type), c) Maximum Speed, d) Maximum travel distance, e) Current location. For moving resources (i.e. vehicles and rescue teams), there is a maximum allowed response time. This means that the location of such resources should be optimal in order to respond in the minimum time. The information taken into consideration for the examined area is the following: a) Amenity type (e.g. schools, fuel stations, fire stations, hospitals, forests), b) area type (e.g. city, village, hamlet), c) roads and road segment characteristics (e.g. length, lanes number, one-way, maximum allowed speed), d) road type (e.g. highway, primary, secondary, tertiary or track).
The proposed approach is based on the so called Particle Swarm Optimization (PSO) algorithm. The steps of the proposed method are the following:
• At first, the area is split into a number of cells creating a grid.
• Second, a specific weight for every cell according to the underlying spatial information is defined.
• Third, the PSO algorithm is used for finding the best location of each resource in order to achieve the maximum coverage.
1.3.3 The operational capacity
The IDIRA solutions were tested and evaluated using specific scenarios (pandemic, flood, fire and earthquake) inside Europe. In the final stage of the project, it was discussed amongst the technical team and representatives of the user groups, whether the approach would be feasible for generalisation. A discussion of some of those aspects can be found in D7.1
Regarding the scenario, it was common understanding that the IDIRA approach is not restricted to any specific type of disaster, even though IT systems are generally highly dependent from electric power supply. As long as this precondition is available with a sufficient reliability at any relevant place of operation, it would work.
More important than the scenario question is the need to integrate the proposed interoperability concepts into the day-by-day business, i.e. into the command and control systems used by fire and rescue services and their operation centers. It is crucial to have the capability and the functions always available to let the operators learn how to deal with it (not only technical how to connect knowledge, but also regarding role models or user rights management). Only following this approach it would be likely that the framework concept would also work in disaster situations.
Although no specific performance assessment procedure was made within the project, it can be said that the IDIRA concept (applying existing standards and following an up-to-date software architectural design) is fully scalable regarding the number of users and organisations as well as regarding the regional extent of the situation and the number of incidents.
There should be a fixed information space infrastructure, preferably distributed over several countries in order to achieve reliability. This infrastructure would regularly gather basic data, such as geographical maps, resource information, roles and rights of organisations and users and meta-data for systems potentially to be connected in case of an event. An up-to-date server infrastructure will be able to handle any needed amount of data traffic that can be expected. Regarding the mobile infrastructure, it is assumed that a MICS-like component would be able to act as data hub for events on a regional level, e.g. comparable with flood events in the German Saxony region, earthquakes like in Italy or Greece, or forest fires. In case of a large affected area, it is expected that more than one MICS module could be used.
The IDIRA MICS concept aims at supporting multi-organisational and cross-national disaster responses. The response time for this kind of actions is rather days than minutes or few hours in normal emergency situations. If one thinks of the MICS concept as part of an existing, or as core of a new standardized EUCP or ERU module, it can be expected that the equipment and personnel would need at least several hours before starting to operate in the field. Considering this, two implications might be concluded: First, each country should have established a fixed information space infrastructure connected with the daily-in-use command and control systems at a safe place in order to be able to provide the needed regional data as soon as possible. Second, the number of mobile MICS components should be high enough to limit the transport time needed before deployment.
1.3.4 Recommendations
The recommendations derived from the IDIRA efforts can be found in the deliverables D7.1 D7.2 and D7.3. The recommendations address different targets, actors and channels:
• User organisations: It became obvious that the usage of the IDIRA system does neither impede existing procedures, nor the structures, which are proven to be effective in crises response actions. The system developed by this project supports any kind of large-scale scenario and is flexible to be deployed by any organisation. Legal aspects of exchanging data and the willingness of organisations to participate were considered to be the most important preconditions for deploying IDIRA-like systems. It was decided that currently and also within the near future the use of tablets should be considered only for the level of field unit commanders and higher, because the communication and task assignment on the scene is anticipated to be oral and personal, now and in the future. A further conclusion is that intensive training and education is needed to prepare responders and leaders for the usage of IT systems. The successful realization of training requires thorough planning and preparation. Two aspects are of foremost importance: the clear definition of the exercise scenario, and the familiarization of users with the equipment and the available software. Users on whatever level working with the system need to clearly understand the use and limits of the system’s modules. To ensure an efficient, rapid and flexible response, a special training programme for the users should be offered. The target group of project users is wide, including many different categories of experts, personnel involved in civil protection, and staff with a specific fields of responsibility.
• Policy decision makers on national and European level: As each European member state has not just its own organizational structure, but also cultural and administrative arrangements, the scope of the EU in crisis management should be designed to get the member states to a common understanding.
• Technical developers: MICS-compliant ICT systems are systems that are just compliant with the rules (namely, used standards and communication interfaces) which enable the possibility to exchange information with the IDIRA MICS or between each other, or provide functionalities similar to the ones provided by the MICS. Basic principles are architectural and design principles such as the SOA approach and loose-coupling of components, principles of modularity, extensibility and possibility to integrate external tools and data in a common, interoperable environment, and the use of a standards to ensure seamless data exchange and, as a consequence, to realise interoperability. Different deployment scenarios are possible for such service oriented architectures. These include cloud-based solutions, as well as the deployment of local infrastructures. The solution adopted in IDIRA considers a combined approach, with a cloud-based infrastructure, always online and always able to get relevant information from connected external systems, as well as a portable solution, deployable on the disaster site (as an additional EU Civil Protection module for example). This portable and locally deployable solution, represented by the MICS itself, is intended to cope with situations, where the traditional networking infrastructures are not available, mainly because they are destroyed or damaged.
• Public authorities responsible for tendering IT systems for purchase to deal with disaster response, command and control, and operation centers: Request an architecture and the interfaces to be used to be compliant with the IDIRA concept, whenever introducing a new software in the fire, rescue or civil protection domain.
• Standardization groups (e.g. for EDXL, PFIF, OSM, TSO): IDIRA has identified gaps regarding the standardization. In new versions of standardization documents, the recommendations provided by IDIRA should be considered.
1.3.5 Code of conduct for data sharing
The outcome of IDIRA was externally evaluated regarding the use of data and data privacy. Two recommendations were concluded in that external report:
• A code of conduct should be established to regulate the collection and use of personal data in emergency response situations such as those considered by IDIRA.
• Training in the use of the code of conduct should form a central part of training platforms like those of IDIRA.
In January 2012, the European Commission proposed a comprehensive reform of the European Data Protection legislation, which currently consists of the 1995 EU Data Protection Directive. Such a reform would be needed to strengthen online privacy rights in view of recent technological developments, but also to harmonize the implementation of the 1995 rules by the 27 Member States. To eliminate such varied implementation in the future, the Commission is proposing a single law for the entire EU, namely the Regulation on the protection of individuals with regard to the processing of personal data and on the free movement of such data (or, as it will also be known, the General Data Protection Regulation). Contrary to the legislative instrument of 1995, this Regulation will be directly applicable in all Member States and will not need separate national implementing measures (e.g. national data protection laws). The proposal does not draw any distinction between the rules applicable to the public or the private sector, for instance. The General Data Protection Regulation will be applicable to entities processing personal data, irrespective of their legal form. If the new General Data Protection Regulation is adopted as proposed, it will update and modernize the principles enshrined in the 1995 Data Protection Directive to guarantee privacy rights in the future.
The draft Data Protection Directive and Regulation could have potential adverse impacts on humanitarian activities within the EU, as well as in third countries or international organizations.
There are significant obstacles, which certain provisions of the Proposed Regulation would cause on certain humanitarian activities, requiring the collection, processing and transfer of data gathered by the different actors during and after a humanitarian crises and catastrophes.
• Lawfulness of processing and processing of special categories of personal data (Arts. 5-9 of the Proposed Regulation):
o The provisions concerning lawfulness of the processing itself, and of the content of personal data (including forensic data), could potentially block an important portion of key activities being carried out in humanitarian crises.
o They would also involve significant obstacles to the implementation of activities carried out by different acting organizations in humanitarian crises, such as tracing of missing persons, identification of human remains, tracing the families of the deceased and handing over to them human remains.
• Transfer of personal data to third countries or international organizations (Arts. 40-44 of the Proposed Regulation): The prohibition on transfers covered in the “Transfer of Personal Data to Third Countries or International Organizations” section of the Proposed Regulation could severely undermine the humanitarian activities, in particular, all the work carried out with the purpose of tracing missing persons and/or restoring family links in humanitarian crises.
The new EU regulation and existing Data Protection legislation require that authorities and organizations take effective measures of compliance. Authorities and organizations need to be sure that effective measures of compliance are taken by all actors processing personal data.
In a multinational disaster, third country nationals are also likely to be involved, be it as disaster response actors or as part of the affected population. In such cases, there might be a need to transfer personal data outside the EU. Therefore, a Code of conduct on personal data processing is seen as a key measure. The appropriate safeguards referred shall be provided for, in particular, by: “[…] standard data protection clauses adopted by the Commission (…); or […] an approved code of conduct […]”. Details on Code of Conducts can be found in Arts. 38 “Codes of Conduct” of the proposed regulation: “[…] code of conduct shall contain mechanisms for monitoring and ensuring compliance with it by the controllers or processors which undertake to apply it, without prejudice to the duties and powers of the supervisory authority […]”.
It is not very realistic to assume that all actors in a multinational disaster would have such a code of conduct. This lack would imply that there is no legally binding instrument and monitoring mechanism in place at all. Thus, Article 44 of the proposed regulation “Derogations for specific situation” plays an important role for IDIRA and its users:
“In the absence of an adequacy decision […], or of appropriate safeguards […], a transfer or a category of transfers […] may take place only on condition that:
(a) the subject of the data gathered has consented to the proposed transfer,[…]; or […]
(d) the transfer is necessary for important reasons of (…) public interest; or […]
(f) the transfer is necessary in order to protect the vital interests of the subject of the data gathered or of other persons […]; or […]
(h) the transfer which is not of large scale or frequent, is necessary for the purposes of legitimate interests pursued by the controller or the processor and where the controller or processor has assessed all the circumstances surrounding the data transfer operation or the set of data transfer operations and, where necessary, based on this assessment adduced suitable safeguards with respect to the protection of personal data;”
In order to meet the requirements of the proposed EU data protection regulation, a reference framework, a soft-version of a code of conduct, should be established, which the users of IDIRA-like systems need to comply with. Conformance of requirements could be met by Data Processing Code of Conduct of the respective actor or an agreement according to the reference framework of IDIRA.
Regarding the implementation of this concept in the context of interoperable IT systems for disaster response management the following steps are envisioned:
• In many of the European countries it is standard that the personnel and the commanding officers of rescue organisations and civil protection authorities are introduced to and pledged obeying the data privacy regulations and the standards for keeping specific classified data undisclosed. Thus, the general process of implementing and training a code of conduct is already in place. It only has to be enhanced taking into account possible large amounts of data and the risk of their abuse. The relevant national authorities have to define, which data under which circumstances may be shared with which third parties. This action is driven by politics and it can be expected that bi-lateral agreements between cooperating countries would be the fastest way to achieve a certain level of willingness to share relevant data.
• All software tools connected to a shared information space should contain and display the code of conduct as part or as supplement of the End-User Licence Agreement. Additionally, before activating appropriate inbound or outbound functionalities it would be requested that the user is explicitly informed of the risk and the restrictions regarding use or forwarding of data, and that he or she is obliged to confirm by an appropriate action.
• All activation and deactivation actions must be stored in a logging system, in order to be able to retrace modifications.
• There must be a process between all connected software systems that allows authentication, encryption and other common security mechanisms.
• From a practical point of view, many of the relevant acting personnel in the civil protection and disaster response domain might not be completely aware of the effects, chances and risks using shared digital information spaces amongst different organisations. It is concluded that the general knowledge about IT networks, data clouds, social media etc. has to be strengthened in the course of the training of the end-users, because without that any code of conduct would not have the intended impact.
1.3.6 Key conclusions from the final end-user advisory board meeting
Most important for the application and implementation of the MICS concept is a common understanding by all of the actors, when it comes to joint deployment. As each European member state has not just its own organizational structure, but also culture and administrative differences, the scope of the EU in crisis management should therefore be to get the member states to a common understanding. Common training activities within the framework of the EU Civil Protection Mechanism is just a starting point and has to be broadened.
To bring an IDIRA-like module into the field, it needs a group of specialists readily available and trained in deploying it and erecting the infrastructure in the field. The training of the staff should also include some training of trainers as the technical team may also have to instruct others on how the system works. The staff also needs to have basic logistic skills as the handout and the return of the tablet PC needs to be organized. If the MICS is the only system deployed and all the units rely on it, a failure is mission-critical because there won’t be any redundancy.
The end-user, independently from his or her level, needs some training – at least to get an idea of the possibilities and also the limitations of the provided tools. This training should be provided before a deployment. A regular repetition seems useful.
In general, users felt that the system and its components were ready to be deployed and reasonable user-friendly. Though some surrounding conditions described in the following passages can make access for users easier:
• Strategic/tactical level commanders: The various tools integrated in the system require properly trained staff to work with them. Crisis managers working with the system may not be aware of all the functions of the system. Or even worse, they are aware of the functions but cannot access them, because of being blocked by their commanding activities. To overcome this problem it would be better to have a specialist operating the COP frontend, while the crisis manager can concentrate on the inherent tasks. This concept to support the crisis manager by a certain number of specialised and dedicated personnel is quite normal in most staff structures, i.e. the full bandwidth of tools can only be used if the situation officer and/or the IT officer (or their subordinated persons) are able to use them.
• Operational level commanders: In exercises users felt confident with the system and considered that the prototypes on the tablet were easy to use and intuitive. Users on the operational level suggested to have a kind of communication officer to take over communication with the COP as information provided needs filtering. That way the commander of the tactical unit would have the opportunity to fulfil her or his commanding role and would have access to the information provided by the system. Another issue not directly found as a lesson learnt, but discussed in one of the interviews is the time line: Especially search and rescue units should be on-site within six hours. The probability of the MICS being deployed within this time frame is relatively low.
The participants of the end-user advisory board meeting appreciated the fact that the foreground of IDIRA is going to be used in the running FP7 and upcoming H2020 projects, as well as in some of the products of the members of the technical team.
It was particularly seen positively that IDIRA has used existing standards and has shown which steps in legacy systems and in future software projects have to be taken to be compliant with the IDIRA concept, and consequently to be interoperable. It is up to the end-users now to consider the recommendations in the process of tendering and purchasing new IT products for command and control in the day-by-day and disaster response business. The responsibility for organisational interoperability and the will to share data was seen at the level of political decision making.
Potential Impact:
1.4 Impact
1.4.1 General conclusions
The IDIRA project has contributed to strengthen the command and control capabilities throughout all the phases of the crisis management process:
• Prevention: In this phase IDIRA modules or approaches can contribute indirectly. Especially the integration of external expert systems like evacuation simulation, forest fire prediction and chemical pollution simulation into a common operational picture supports early situational awareness, that – in some cases can prevent or mitigate sever impacts caused by accidents or incidents.
• Preparedness: Command and control structures are highly important to manage disaster response actions effectively and efficiently. IDIRA provides a comprehensive concept (MICS) to improve the capabilities of those command and control structures regarding the provision with data and information. Additionally, a set of recommendations how plan and to proceed IT-specific training for the commanding personnel was elaborated and published.
• Response: Most of the IT-related recommendations, such as proposed standards for data transfer and information integration, address tool that more or less are connected with the concept of a common operational picture (COP), which is the core element of joint response actions. This information hub is able to provide decision support and resource systems with the needed data, and to share this data with other involved actors.
• Recovery: IDIRA has also shown, how modules like donation management or international resource management can be integrated within the MICS concept.
This also included efforts to combine simulation of response actions in the field and in the command and control centers with training of newly developed IT solutions or features. The findings and recommendations can be considered in all upcoming IT-focused projects.
One notable impact of IDIRA was the significant improvement of the bilateral understanding between the two domains civil protection/disaster management on the one hand side and software development/IT system integration on the other hand.
The IDIRA concept is designed for multi-organizational cooperation in multi-national contexts. It is difficult to specify the magnitude of the events IDIRA-MICS will be able to cope with. Basically, the IDIRA concept is expected to be able to cope with big disasters of any scale, providing a common working environment and the tools for publishing information, working on this information and consuming information. For this to be possible, the important precondition is that relevant information is made available, coming from connected external systems or ad-hoc integrated (e.g. disaster related information, maps, and so on). This precondition is normally well satisfied in some countries, for example across Europe, and a bit less in others, leading additional issues to be dealt with.
We think that the way the IDIRA architecture has been conceived can ensure the sustainability of the technological results after the end of the project. The IDIRA architecture is based on the SOA (Service Oriented Architecture) paradigm, and on a modular integration of different software components. A set of core services ensure data persistence, message based communication between components, taxonomy handling and handling of geographical layers. Around these core components, specific Interoperability services are designed and implemented for ensuring the connection with external systems, while a plugin based approach is adopted to integrate all the other services within the COP. This approach ensure that enhancements that imply the integration of new technologies can be applied in a modular way, without affecting the whole architecture. Just to stay within the example of the connection of IDIRA to social media, as explained previously a new service has been developed: this is just part of the Interoperability services set, and can be enabled/disabled without affecting or having to act on the rest of the services. Of course, further technical considerations could be made in case, for example, the social media service will be extended to the possibility to get data from manifold social media sources, including data coming from normal citizens’ social's accounts therefore adding new issues such as, for example, the need to filter and verify the accuracy of the information. But still, to support this kind of scenarios and deal with emergent approaches in disaster management, improvements could be needed only to specific services, e.g. by adding specific filtering and data mining capabilities.
1.4.2 Co-operation with other projects/programs
In the final phase of IDIRA, contacts were made with representatives of other projects dealing with interoperability and taxonomy issues. IDIRA partner IES, as WP4 leader and responsible of the tasks on standardization in WP7, participated to a specific meeting of the projects funded under the topic SEC-2012.5.1-1 (Analysis and identification of security systems and data set used by first responders and police authorities) of the last FP7 Security Call. The four projects (EPISECC, SECINCORE, SECTOR and REDIRNET) are all researching on topics relevant for IDIRA. In particular, the coordinated efforts on the definition of a common taxonomy for data sharing between emergency services fits well with the features of the system developed in IDIRA. The meeting was hosted by CISCO in Paris (France) on 24th November 2014 and outlined the areas where the efforts of the four projects will be coordinated. The experience gained in IDIRA was shared and included as a reference for the “Task Forces” on Taxonomy and on Standardization.
Particularly at the final End-user Advisory Board Meeting representatives from the following FP7 projects were present to learn about the outcome of IDIRA and how it can be used in the context of their specific work: EMERGENT, SALUS, SECINCORE, DRIVER, and EPISECC.
The main outcomes of IDIRA – MICS Architectural Reference and COP prototype, and Recommendations for harmonization & standardization – will be re-used in further FP7 projects DRIVER and EPISECC by the participating partners FRQ, IES and ORK-HQ.
Several IDIRA partners participate in the activities of the CRISMA project, as partners as well as observers in the course of the planned exercise. CNVVF will leverage on the IDIRA outcomes using them as basis for the interoperability features and standards to be included into the activities to be carried out within the projects AF3 (Advanced Forest Fire Fighting – FP7 SEC-2013.4.1-6) and NEXES (NEXt generation Emergency Services - selected for funding in the framework of the H2020-DRS-19-2014).
1.4.3 Dissemination
In the course of the project more than 50 presentations on workshops or conferences were done. All of them were dedicated to specific stakeholders from the domains of crisis management, software development or communication technology, respectively. Additional several videos were produced and were made publicly available. Together with a summarizing leaflet the deliverables with public dissemination status are available on the project home page www.idira.eu in order to be available for ongoing and upcoming projects and for those tendering or developing IT solutions for the crisis management domain.
1.4.4 Outlook
Based on the IDIRA partners’ experience, the use of standards and open technologies for information exchange has proven to be an effective approach for interoperability. Particularly, the IDIRA MICS has been designed as an information hub, providing Inbound and Outbound interfaces, and the rules to share specific information types by using suitable, standard data formats, together with a Web-based and modular environment for the interoperable integration of external data and tools. Therefore an integrated set of tools and a common information space were realised, to be used in cooperative, multinational disaster management scenarios. There is, surely, potential for further improvements in the adoption of specific standards, as well as the possibility to propose new ones: project’s partners intend to disseminate such findings, by bringing the IDIRA results, as far as standardisation and harmonisation topics are concerned, to the attention of existing standardisation bodies and communities. Finally, relevant showcases, concerning the connection and interoperable integration of existing systems and data with the IDIRA MICS have been realised during the project. This demonstrates how interoperability by adapting existing systems, following the model and guidelines proposed in IDIRA, can be realised in practice with a sustainable effort.
The community of technical developers has gotten a certain set of standards and a general architectural design that allows for producing interoperable software systems following simple rules designed by IDIRA. Those active in the field of standardization can now refer to specific proposals how to improve or enhance existing standards and can consider the need for new standards.
Public authorities and end-user organisations are now in the position to define the requirements for new software products or new versions of existing ones in order to make them compliant to the IDIRA MICS concept. It is of particular importance, that each of the proposed standards can be implemented and applied solitarily, i.e. it is not necessary to build the whole and complex IDIRA system once again before being interoperable. Rather, it would be sufficient, if step-by-step the used systems evolve towards interoperable components.
For policy decision makers, two main fields of action still remain. First, the willingness to share specific data amongst organisations and countries must be part of a common understanding and contracts including a certain code of conduct, at least on bilateral level. Without that, any technical solution solely stays a theoretical option. Second, independently from the question how much data is shared with whom, the technical implementation will be based on interfaces and specific architectures. If politics does not support the development and use of open standards, such as proposed by IDIRA, then the authorities will become (or stay) dependent of single, regionally dominating, private companies. This has obvious negative implications for the costs and for the flexibility regarding the use of IT systems in large-scale multi-national and multi-organisational disaster response actions.
List of Websites:
1.5 Contact data
Project web page (hosted by Fraunhofer IVI): www.idira.eu
List of participating organisations and their individual roles in the project:
• Fraunhofer Institute for Transportation and Infrastructure Systems, Germany: Coordinator; WP 5 leader (Interoperable Management); WP 8 leader (Administration); Technical developments
• Salzburg Research Forschungsgesellschaft m.b.H. Austria: WP 3 leader (Interoperable Communication)
• Frequentis AG, Austria: WP 2 leader (General architecture)
• Brimatech Services GmbH, Austria: WP 1 leader (State of the art); gathering feedback from user groups
• National And Kapodistrian University of Athens, Greece: Technical developments
• Organismos Antiseismikou Sxediasmoukai Prostasias (OASP) (EPPO: Earthquake Planning And Protection Organization), Greece: End-user
• Deutsches Rotes Kreuz Landesverband Sachsen e.V. Germany: End-user
• University of Greenwich, UK: Technical developments
• Intelligence for Environment and Security SRL (IES Solutions SRL), Italy: Technical coordinator; WP 4 leader (Information and data interoperability); Technical developments
• Österreichisches Rotes Kreuz, Austria: WP 6 leader (Training and exercises); End-user
• Ministry Of National Defence, Greece: WP 7 leader (Recommendations); End-user
• Ministero Dell'interno, Italy: End-user
• SATWAYS - Proionta Kai Ypiresies Tilematikis Diktyakon Kai Tilepikinoniakon Efarmogon Etairia Periorismenis Efthinis Epe, Greece: Technical developments
• TLP SPOL SRO, Czech Republic: Technical developments
• World Agency of Planetary Monitoring and Earthquake Risk Reduction, now International Centre for Earth Silulation , Switzerland: Technical developments
• OLYMPIAKI: Anaptixiaki Etairia Peripherias Ditikis Ellados Anonimi Etairia Ota, Greece: End-user
• KEMEA: Center for Security Studies, Greece: End-user
