One of the greatest challenges that first responders and emergency teams face during a crisis, deals with inadequate information access, semantic differences and inconsistency of heterogeneous data sources. Against this background the project aimed to address the challenges of interoperability in crisis management by defining the requirements of Situation Awareness (SA) model responsible for real-time monitoring of first responders’ biometrics and notifying the actors about their symptoms and the immediate action(s) to be taken.

Description of Situation Awareness Services

The Search & Rescue project provided the foundation for the proper development of an original SA model. More specifically, the project provided:

• use cases and related devices which play a central role in each, as well as their contribution in situation awareness as a whole.
• characteristics of each device, the biometric values they monitor, their danger thresholds, the symptoms experienced in each dangerous zone and the corresponding set of actions to be taken in each, and a
• summary of the devices and their thresholds for all relevant values.

Use cases

The purpose of the SA model is to provide general situation awareness services by monitoring the biometrics of actors in search & rescue operations, as well as alerting the first responders and rescue teams about critical events happening in the field and may threaten human lives. To achieve this, certain devices were utilized as providers of real-time data, that would enhance the situation awareness capabilities of the SA model implementation. Below a description of each of the seven (7) use cases (UC) is provided, as well as the devices involved.

 

UC 1: Victims trapped under rubble in Italy. This use case tested a real-life crisis scenario, in which victims were trapped under rubble. Devices, which were involved are wearable GPS tracker, PHYSIO DSS, Wearable ECG, Wearable EMG, Wearable Strain Sensors, and AI algorithms for recognizing objects from drones’ images.

UC 2: Plane crash, mountain rescue, non-urban in Greece. In this use case, a forced airplane landing would be simulated in a mountainous area which was isolated without road access. Devices, which were involved are, Smartwatch, Emergency Response Health Condition Monitoring Device and Volunteer application.

UC 3: Earthquake and heavy storms between Vienna Rail Station and Kufstein railway station in the cross-border between Austria and Germany. The simulation involved collapsed structures such as damaged buildings and communication break downs because of lack of power supplies. Devices, which were involved are smartwatch, Six Gas Hazmat Monitor, Obstacle Detection and Avoidance System and Rescue robots and autonomous vehicles.

UC 4: Two-pronged threat between a forest fire which expanded rapidly and a threat in a nearby industrial zone in the Attica region of Greece. Devices, which were involved are Smartwatch, Radiation Sensors, wearable,  Chemical sensors, Drones, Collaborative drones’ platform, Rescue robots and autonomous vehicles and Obstacle Detection and Avoidance System.

 

UC 5: Victims trapped under rubbles in France. Devices, which were involved are PHYSIO DSS and Chemical sensors.

UC 6: Resilience Support for Critical Infrastructures through Standardized Training on CBRNE (chemical, biological, radiological/nuclear, explosive) in Romania. In this scenario, specialized underwent standardized training against CBRNE hazards management. Devices, which were involved, are Six Gas Hazmat Monitor, Wearable Strain Sensors and Smart Glasses.

UC 7: Chemical substance spill in Spain, after an accident in a factory that derived in chemical spill in a building, threatening the health of the workers of the factory. The Use case involved real life simulation of victims in chemical risk emergency situation. Devices, which were involved are wearable GPS tracker, smartwatch and Six Gas Hazmat Monitor.

Architecture of a Situation Awareness model

The Search & Rescue project developed the architecture of a SA model. In the following section, a high level view of the architecture is presented. The article sheds also light on the identified user needs and requirements and the means of verification of the models, which were applied by the consortium.

High level view of the architecture

The established provided included information on the operation context and its interaction with the other elements of the project’s ecosystem.

• The devices serve as sensors and endpoints, which process data or produce information which needs to be processed, forwarded and/or stored. These devices interact with the ecosystem through RESTful APIs and either offer data passively, or actively forward them to necessary components in general.
• Data aggregation pipeline. This pipeline referred to the general processing of sensor data throughout the Search & Rescue ecosystem. Data originating from sensors and historical sources were gathered into the Data lake for coherence and maintenance, while the data were then undergoing aggregation operations, resulting in their storage.
• Actor or component. This was a placeholder indicating any actor or component of the entire ecosystem with the potential of querying the SA model for data and information, or a general entity which the SA model is responsible for notifying in a timely fashion in case of an alert trigger.

All external integration and interaction points of the SA model interacted with the project’s ecosystem in

one of the following ways:

• Sending data to the SA model or the SA model itself pulling their data through REST. The devices themselves and the interaction with data base through the aggregation pipeline interact with the SA model this way.
• Querying the SA model for specific information. Actors who are involved in an alert trigger interact with the SA model this way.
• The SA model pushes alert messages/notifications to involved actors and components. The SA model pushes important alerts and messages to actors of relevance and important components of the ecosystem such as the command centre.

 

In the following the inner modules of the SA model are briefly mentioned here.

• Semantic database. The semantic database of the SA model was responsible for keeping all stored data for future reference and for queries.

• Scheduler. The scheduler was responsible for periodically communicating with the devices

participating in general situation awareness, in order to filter the biometrics of subscribed actors

in case of an alert trigger event. Due to the importance of the scheduler, and to avoid stale

content, the scheduler adjusted the time period per check dynamically.

• Rules engine. The rules engine was responsible for monitoring the values of the data obtained

by the scheduler against a set of sophisticated rules, in order to determine whether one or

more values trigger an alert.

• Push notification service. The service of the SA model responsible for properly notifying

relevant actors in cases of alert triggers. It kept track of subscribed actors and components

per actor paired with devices and notifies them in a timely fashion.

• RESTful interface. The RESTful layer of the service. Following the REST principles in a strict

fashion, this interface supported POST/GET operations. The data format for all exchanges was

JSON.

The overall high-level architecture of the SA model is shown in the figure below,

User needs

Because of the central role of the SA model in alerting events detection from critical biometrics’ values,
it was established that the component needed to provide the following core functionalities:

• Interfaces to provide aggregated data about specific devices, actors, date ranges etc.
• Sophisticated rules engine which filters biometrics and occasionally triggers alarm events.
• Storage of alarms for future reference as historical data.
• Timely notification and signalling of relevant parties about alerts.
• Real-time updating of information as needed. For example, a device paired with a first responder suddenly changing its paired actor, once the first responder places the device on a victim to measure their vitals.
• Documentation of the provided infrastructure. In order to ensure maximal usability of the system, it is imperative to describe its functionality and behaviour in detail.
• Decision Support. While not strictly a DSS component, the SA model plays a central role in general situation awareness, by monitoring devices and alerting actors and components on time.

Means of verification

The objectives of the SA model and corresponding verification means, which were required included:

• proper aggregation of biometrics and alerts per device, per actor,
• dynamic scheduling at device/actor level to ensure efficient real-time monitoring of the devices,
• avoiding redundant pinging , and
• filtering of biometrics’ values against rules, which trigger conditional alerts.

The following table provides information on the entities, which played major role in the verification process:

Objective	Domain of SA requirements	Concepts
Proper aggregation of biometrics and alerts per device, per actor	Interfaces	Actor Alert Trigger Device
	Storage	Actor Alert Trigger Device
	Decision Support	Alert Trigger Device
	Scheduled pinging	Actor Device
Dynamic scheduling at device/actor level to ensure efficient real-time monitoring of the devices, avoiding redundant pinging	Real-time updating	Actor Device
	Storage	Actor Alert Trigger Device
	Decision Support	Alert Trigger Device
	Timely notification	Alert Trigger Device

Table 1: Objectives and Means of Verification

Links

https://search-and-rescue.eu/

Keywords

First respondents, situation awareness services, architecture, verification