Keywords

1 Introduction

The lack of interoperability among systems, sensor networks and in communication is one of the major obstacles for effective crisis and disaster management (CDM), especially in heterogeneous and multi-user environments. Accessing data provided by the first responders in the field, having a joint operational picture of a crisis by accessing sensor data and maps, and having a possibility of real-time effective communication with other crisis managers (organizations) are all examples of needs and activities a crisis responder experiences. However, the presence of significant diversity in the CDM domain in general creates barriers halting the efficient cooperation. Typical issues include usage of different hardware and software solutions, conforming to different (or incompatible) data and communication standards, not fully adjusting to the legal and administrative policies and procedures of involved organizations and responders, or considering the defined (data) security requirements. An example is a response to the Haiti earthquake in 2010, where lack of interoperability of equipment and procedures among the European field hospitals caused less efficient cooperation and response [1]. Similar story goes for Hurricane Katrina in 2005, in which a higher level of data interoperability would have enhanced evacuation cooperation between the governmental and voluntary organizations in matching parents with missing children [2]. Moreover, the frequency of disasters is expected to increase in the forthcoming future mostly due to environmental changes [3]. Floods are just one type of a crisis that in its nature often is transboundary, spanning several neighbouring countries or regions. For example, the Danube River is known for flooding Central and Eastern Europe regions for centuries, and several times in the recent two decades only [4], bringing devastation and loss of lives, together with an economic burden on the affected population and governments. Such situation calls for an enhanced level of cooperation, where linguistic, law and information exchange barriers are no longer an obstacle [5].

These are just some examples among a myriad implying a necessity for a solution involving “the capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units” (OGC’s definition for interoperabilityFootnote 1). In other words, in a fully interoperable response, every organization would have the possibility to use any software, data and communication formats and language that best suits their procedures and methods of operation while maintaining their independence, and at the same being able to take part in a joint crisis response.

The currently ongoing C2-SENSEFootnote 2 project [6] is meeting this demand by developing a framework where all relevant entities (organizations, rescue services, etc.) that need to cooperate during crises are collaborating. Collaboration means facilitating communication, information, and data exchange among actors, regardless if their systems are proprietary, or open. This reduces reaction time, increases the effectiveness of the management, and thereby saves lives and resources. The C2-SENSE Framework encompasses two parts:

  1. (1)

    components related to the physical nature of the Framework meaning software and hardware, and

  2. (2)

    the profiling approach, i.e., incorporation of rules orchestrating the functionalities of those components and rules for achieving interoperability.

The methodology and the approach in the second part are flexible enough to allow for implementation not only in crisis and disaster domain, but also in other domains where such functionality is required.

We present the Framework and its Collaboration Environment in Sect. 2, where the main software components necessary for interoperability processes are described in detail. In Sect. 3, the profiling approach is described, while an example of implementation is given in Sect. 4. The discussion and conclusion on the still ongoing work is provided in the Sect. 5.

2 The Framework and Collaboration Environment

Collaboration occurs whenever humans and/or computer applications work together to accomplish a common goal. In the domain of crisis and emergency management, it is critical that a sufficient level of collaborative effort and alignment between the crisis responders is achieved. In order to process and align the activities and procedures performed by the responders, applications and different Command and Control and Sensor Systems, the C2-SENSE Framework provides Collaboration Environment. It allows for critical functionalities and activities such as real-time data and information exchange, communication between entities involved in response activities, and alignment of operations and procedures during crises.

Collaboration Environment incorporates a set of software components. One group of these components are intended for decision making activities, covering functionalities such as GUI for crisis mapping, or data and sensor management. The second group of components are developed with the sole purpose of managing profiles, thus allowing for functionalities to achieve the interoperability at the level of seamless information and data exchange and procedure alignment, a process more described in Sect. 3.

2.1 Components and Applications for Decision Making

The following software components and tools are part of the Collaboration Environment important for the decision making in critical situations, as well as in the preparation phases.

Emergency Maps Tool (EMT):

The main purpose of the Emergency Maps Tool is to provide the end user or the network of users (e.g., crisis managers, responders in the field) with a collaboration tool for representation and sharing available geo-referenced data and information. This tool mashes up the emergency geospatial data from the C2-SENSE data repository, map layers and data from external Map Services. The tool displays the emergency area geographically to the related authorized users.

The EMT is, however, not only about data on maps, but it also includes widgets that are useful and required in emergencies. These are widgets for displaying timeseries sensor data (e.g., water level development for the last 24 h), monitoring exchanged messages among the C2-SENSE responders, or monitoring the latest incoming values regardless of their source (temperature data, showing the last position of an ambulance, etc.). The EMT tool is easily expandable to include new widgets and features. A screenshot is given in Fig. 1.

Fig. 1.
figure 1

Emergency maps tool with the map, line graph, and last values table

Full size image

Object of Interest Data Repository (OOI):

All the relevant data that have to be available to other Collaboration Environment components are stored in the Object of Interest Data Repository [7]. Fast response times are required during crises, implying quick data access and repository response and tight coupling between the OOI repository and technologies for reliable and fast data access and exchange by using the available technologies (e.g., Apache KafkaFootnote 3). The sources of data can be anything from sensors measuring environmental parameters (air quality, temperature), to sensors tracking location of ambulances. To allow for effective and accurate applications of the OOI data, the data can be further enriched with meta-information (e.g., data are georeferenced). Moreover, other type of sources, as are texts in exchanged messages or in social media can also be stored as relevant data in the OOI data repository. The component is working in the background without any direct interaction with the end user (e.g., crisis responder).

Sensor Management Tool (SMT):

The purpose of the Sensor Management Tool is to provide an overview over available sensors in the field to crisis mangers and to allow them some basic configuration in a generic way without the need to know all the details about the sensors. As the configuration needs to be agnostic in respect to the sensor type, the possibilities of the tool are intentionally limited to very basic and generic commands. These include sending information on sensor identification (ID), capabilities and location, controlling and adjusting the data-sampling rate (off, low, medium and high), or re-locating a sensor (in case of autonomous sensor platforms).

SMT encompasses a GUI for sending commands and for visualizing responses (see Fig. 2). Visualization functionalities can also be done with the EMT. The component defines messages for the ESB, and information/data on how sensors can react by providing a reference implementation. This is an optional implementation of the interface to sensors and sensor network adapters. Finally, SMT is not planned as a replacement for any sensor specific configuration tools, but as a complementary tool to be used without any prior knowledge of the actual sensors used.

Fig. 2.
figure 2

Sensor management tool user interface for sending commands

Full size image

GIS Server:

The GIS Server is used to provide the data from the OOI in a standard conform way to clients already used within a specific organization. The clients range from dedicated GIS solutions (e.g., QGIS) to broadly used applications (e.g., Google Earth). The component primarily makes the data available to the end users who are connected to the C2-SENSE Framework and authorized to access the data. The data, however, can also be made available to end users in case the data are open. Moreover, by using the GIS Server, it is possible to visualize crisis related data on standard GIS clients making the information available to everyone without the need to use a specialized tool like EMT.

LimitChecker:

Crisis responders require automatic provision of warnings and alarms during crises. This is specifically important when many events occur simultaneously, and when there are large amounts of data coming in, making having an overview of the crisis very hard. LimitChecker provides automatic monitoring functionality. This C2-SENSE component monitors relevant sensor data (i.e., water levels) that are streamlined in the C2-SENSE data repository, and compares them to pre-defined threshold values. In the case of exceedance, a warning or an alarm are sent to the system and relevant end users. Moreover, the LimitChecker component also provides data modelling functionality, where timeseries sensor data for a chosen period are analysed to predict the development of, e.g., water levels, for the next few hours.

Due to the flexible component architecture, which includes free statistical software R sub-component, LimitChecker can easily be used and extended to serve other, more complex, data analysis tasks (e.g., combining ground-based sensor data with weather forecast).

2.2 Components and Applications for Profile Management

Management of profiles defined in Sect. 3 is done by four software components described in the following. The management process is given in Fig. 3.

Fig. 3.
figure 3

Profile management process

Full size image

Profile Definition Tool (PDT):

The main purpose is to provide users with an online tool to create, to update and maintain profiles in an easy way. It provides users a graphical user interface to define a profile as an ad hoc workflow describing the order of the tasks, messages to be exchanged within tasks, and documents that constitute the message content. The aim is to lighten the workload of domain experts and help them to handle complex tasks easily. After profiles are defined, PDT produces automatically both human readable Word documents, which addresses the versioning problem and helps to keep documents always up-to-date; and machine processable XML documents, which enables software systems to understand the profiles. The schema definition of this XML document (XSD) is referred as Emergency Profile Definition Language (EPDL).

Profile Specialization Tool (PST):

Profiles defined through PST are generic and independent from organizations and specific incidents. These generic profiles contain enough structure to prevent chaotic response to crises situations such as the initial activities, control and data flow structure, and resources needed to start managing a variety of crisis situations. Profile Specialization Tool is used to customize the generic profiles to specific organizations and specific incidents by considering the existing procedures and operations of the organizations involved. It is used to create a machine readable and executable process definition from the graphical definition by using a business process specification language, namely BPMNFootnote 4. The BPMN documents created by the tool are then sent to Profile Execution Engine for execution.

Profile Execution Engine (PEE):

This is a tool built on Alfresco Activiti, which is an enterprise Business Process Management (BPM) solution targeted at business people and developers. PEE is used to execute emergency web processes defined as business rules in BPMN format by invoking corresponding Web services automatically.

Profile Monitoring Tool (PMT):

Profile Monitoring Tool, a graphical user interface, makes it possible to visually trace the execution of a specific instance of profiles by PEE. The aim is to enable users to track the status, bottlenecks and incomplete tasks to take necessary measures.

3 Profiling Approach

The second part of the C2-SENSE framework is the application of profiles. Profiles define a standard set of messages and documents, business rules, processes, constraints and choreographies that allow even a new entity to join an already existing response network, without any additional integration efforts, as long as the entity conforms to one or more predefined profiles. In cases where entities do not conform to any profile or standard specification (meaning that they have their own proprietary document formats, workflows, business rules, etc.), adapters should be implemented for every two entities so that they can be interoperable. This operation should be repeated every time a new entity joins the network. In this regard, profiling approach helps in improving interoperability as it eliminates the need for prior bilateral agreements between entities involved in crisis response, and who wish to exchange information and data by defining standard specifications for achieving specific goals. In other words, these are sets of rules orchestrating the functionalities of the Framework.

A profile-based approach has already been successfully implemented in domains such as eHealth [8] addressing three layers of the Interoperability Stack. “Communication Layer” covers the transport and communication layer protocols, “Document Layer” addresses the content format of the messages and documents exchanged among the applications, while the “Business Process Layer” addresses the choreography of the activities to be executed by the participants [9]. For the CDM domain, however, organizational aspects including policies, procedures, strategies and operations are critical. Therefore, the Interoperability Stack shown in Fig. 4 has been proposed for the domain [10].

Fig. 4.
figure 4

Interoperability stack for emergency management

Full size image

The first full implementation of the Stack is deployed through the C2-SENSE Emergency Interoperability Framework [11]. The profiles developed in the project are addressing all the layers, exposing available applications and implementing the missing technologies, and making them available to the crisis response community. In the following, we provided details on profiles currently available in the Framework, while keeping in mind that the new ones can be added upon the need and purpose of the collaboration (e.g., data exchange for environmental monitoring, maritime surveillance [12], etc.).

Emergency Situation Map profile:

This profile describes how a user or an organization is provided with a common operational picture of the emergency area using a real-time data and geographical maps. It describes how to get the data, maps and mash-ups. The objectives of implementing this profile are: 1. Getting the overview of the current situation in the emergency area. 2. Identifying emergency characteristics/attributes/hallmarks. 3. Identifying the critical emergency areas. 4. Identifying location and information related to emergency resources. 5. Identifying location and information related to rescue targets. 6. Comparing different information related to maps (e.g., elevation) or data (water levels at different locations). 7. Communicating the findings to other C2-SENSE and local parties.

The profile supports a process of providing C2-SENSE users with a common operational picture with maps and/or data with access determined by the Service Level Agreements (SLA). The intended scope for this profile includes pre-emergency, during and after emergency on-site coordination centres, local organizations, national organizations and non-governmental organizations. The activities specified in this profile are intended to provide a common ground for a decision support between organizations taking part in emergency operations. It is expected that all parties have necessary infrastructure/devices, to enable them to acquire maps and data, and to view them.

Situation Analysis profile:

This profile describes how a user or an organization is provided with a possibility to simulate the situation on the ground for a given set of data. The profile describes how to get the data, maps, mash-ups and simulation results. The objectives of implementing this profile are: 1. Acquiring an overview of the possible situations based on the current situation (data) in the emergency area. 2. Identifying the potentially critical emergency areas. 3. Identifying the potentially critical events. 4. Communicating the findings to other parties.

This profile supports a process of providing users with a common operational picture with maps and/or data. The intended scope for this profile includes: pre-emergency, during and after emergency situations on-site coordination centres, local organizations, national organizations and non-governmental organizations The activities specified in this profile are intended to provide a common ground for a decision support between organizations taking part in emergency operations. It is expected that the parties have necessary infrastructure/devices, to enable them to acquire maps and data, to view them and to run simulations on them. The access is determined by the SLA agreements.

Sensor Measurement Profile:

The profile describes how sensors transmit their measurements to the C2 Systems, where organizations can analyse the observations. This is important across the complete emergency incident life cycle, including preparedness, initial and on-going response, recovery and demobilization/release of sensors.

The objective of implementing this profile is to expect that all sensors are sending measurements of their observations according to their configuration.

This profile supports the process of sensors that send measurements to C2 Systems. The intended scope for this profile includes (during and after emergencies) emergency managers among on-site coordination centres, local organizations, national organizations and non-governmental organizations. It is assumed, (1) that the sensor infrastructure is ready to run and (2) that sensors can send their measurements. That means that configuration (including type of protocol, physical connection, etc.) is a prerequisite and thus not part of this profile.

Sensor Management Profile:

This one describes how organizations can configure sensors to gain observations from areas of interest. This is important across the complete emergency incident life cycle, including preparedness, pre-staging of sensors, initial and on-going response, recovery and demobilization/release of sensors. The objective of implementing this profile is to expect that sensors are available and that they need to respond and adapt to emergency incidents, such as querying and finding out about available sensors, and configuring sensors to send the requested observations (data).

The profile supports a process of discovering, ordering and deploying sensors, which are needed in emergencies. The intended scope for this profile includes (during and after emergencies) emergency managers among on-site coordination centres, local organizations, national organizations and non-governmental organizations. It is assumed, that the sensor infrastructure is ready to run, i.e., low-level configuration (including type of protocol, physical connection, etc.) is a prerequisite and thus not part of this profile.

4 Collaboration Environment in a Real Life Example

We show here a simplified example in order to see how the physical components and the profiling approach harmonize the data exchange among two or more entities (organizations, responders, etc.). The example is a part of a larger crisis scenario involving floods.

Entity A has only limited overview of the situation in field: reports from police and firefighters provide last measurements on water levels and the extent of flooding, which can be mapped into their Geographical Information System (GIS). These are, however, not real-time and can be obsolete due to rapidly changing situation on the ground. Besides reports, Entity A can have direct access to water level measurements provided by the sensors in-situ owned by Entity B. Accessing sensor data would provide real-time situation data and an overview of the situation that would manifold the effectiveness of decision making for Entity A. The obstacles are, however, which protocols to use in order to access the data, how to get the correct permissions, and finally, how to align the data formats to be embedded into their GIS system. Since the data are in the possession of Entity B, some kind of exchange and alignment rules and agreements need to be put in place in order to bypass the mentioned obstacles. The following process is applied when exchanging the data between Entities A and B (Fig. 5):

Fig. 5.
figure 5

Steps in the alignment process in the profiling approach for one entity

Full size image
  1. (1)

    Register as a new organization (in the C2-SENSE system),

  2. (2)

    Choose a default profile for data exchange (i.e., Emergency Situation Map profile).

The profile defines the needed input, such as the data format and communication protocol. Normally (without profiles), Entity A and Entity B are supposed to first understand their proprietary formats, protocols, rules etc., update their internal systems according to specifications of the other, and then exchange information. However, with the profiles, they just either update their internal system according to standard specifications in the profile, or use some adapters in C2-SENSE framework, which makes them profile compliant.

  1. (3)

    Specialize the chosen profile by providing the network access point (e.g., URL) of the receiver/sender of the data,

  2. (4)

    Activate the specialized profile.

After the final step, it is possible for Entity A to receive the data from Entity B based on the specifications defined in business process model and notation, and apply further functionalities provided by the components in Collaboration Environment (e.g., decision making, etc.) The process of specializing a chosen profile, however, needs to be executed by both actors for their respective specifications. Entity B sends the data in JSON format, while Entity A can only treat XML formats. The Framework would then consider this and make the appropriate transformations needed for these two actors to exchange data and information. Transformation can be done at semantic level as well. The framework provides a semantic interoperability suite allowing for semantic transformation for organizations using different data models, or the same standard but different versions. What this example shows is the interaction between the physical components that offer data integration and transformation and the rules governing the data exchange between these components. Without the profiles, the system would not know which format is received, nor which format is accepted and used by the receiving actor.

Very similar actions are planned as a part of the real flood scenario in the C2-SENSE project’s pilot due in 2017 [11]. The results will be reported in a subsequent publication.

5 Discussion and Conclusion

The novel profiling approach presented here is based on the successful application of the conventional profiling approach in eHealth domain [8]. However, the conventional one addresses only the first three layers of the Interoperability Stack, covering the transport and communication layer protocols, addressing the content format of the messages and documents exchanged among the applications, and addressing the choreography of the activities to be executed by the participants [9]. For the emergency management domain, however, organizational aspects, such as policies, procedures, operations and strategies are as important as technical aspects of interoperability. Absence of those can result in loss of time and resources, and potential wrong decision-making.

The C2-SENSE Framework offers a solution in form of its software components and profiles. The defined and developed profiles in C2-SENSE are addressing additional layers of the Interoperability Stack defined in [10], thus covering these lacking aspects. The solution is flexible enough to be applied for the Emergency Management domain, or to be adjusted for any other domain that incorporates sensor and sensor network data, data exchanges, crisis mapping, and collaboration in multi-user environments. One such domain is Maritime Surveillance where illegal activities such as smuggling or piracy, or maritime vessel traffic management and protection are of critical importance for law enforcement. Implementing the identified profiles in such scenarios can serve for their improvement [12].

This implies potential for introducing the Framework in domains dealing with environmental challenges, being that of real-time monitoring, or mitigating. Since the world today awaits more disasters related to climate changes (e.g., floods, droughts, landslides, air pollution), it is important to provide necessary tools for not only treating the crises when they occur, but also for monitoring the events leading to a disastrous situations. Moreover, such solutions need to have the strength of being easily implementable, adjustable to all the needs of different end-users (e.g., crisis responder, police, volunteer [13]), adjustable to new research and technological approaches (e.g., citizen science [14], crowdtasking [15]), and potentially globally affordable and available. It is expected that the profiling approach of the C2-SENSE Framework, with its provided software components in combination with the set of rules orchestrating the functionalities of those components and rules for achieving interoperability, is a solution fulfilling those needs.