An Internet of Things System Architecture for Aiding Firefighters in the Scene of Disaster

1. Introduction

Firefighters typically perform their duty in dangerous circumstances where smoke, dusts, flame, fumes, noise, and explosion often blunt their senses of vision, auditory, touch, and direction. Their apparatuses including protective clothes, self-contained breathing apparatus, helmets, and boots are typically heavy, and endurable working time is very limited due to the restricted amount of breathable air. Therefore, they are often exposed to dangerous situations that threaten their lives. The 2016 Annual Report of the US Federal Emergency Management Agency (FEMA) [1] said that 69 firefighters died while on duty in 2016 and the 15 deaths were on the fire ground.

To protect firefighters and aid their duty in the scene of disaster, there is a need of new technologies and systems applicable to the disaster and safety domain. Recently, governments and companies are applying ICT technologies to this domain and developing systems for aiding firefighters. These systems were introduced in Interschutz, a world trade fair for fire and civil protection. However, they are mostly at the early stage and focus on specific disaster scenarios (e.g., infrastructure-available indoor fire). As disaster situations vary widely, systems must be flexible and applicable according to situations.

In this paper we propose an Internet of Things (IoT) system architecture that can be configurable and applicable to firefighting and rescue in various disaster situations. Our approach provides increased adaptability and reusability of systems compared to existing approaches.

First of all, we explore and identify requirements of systems aiding firefighting and rescue in Section 2. Then, based on the requirements, an IoT system architecture for disaster and safety is proposed in Section 3. To validate the proposed approach, a system of systems based on the architecture was developed and tested which is introduced in Section 4. Finally, conclusion and future work are given in Section 5.

2. System Requirements

We have analyzed various scenarios that can occur in various disaster situations including indoor fires at different places (e.g., residential area, high-rise buildings, chemical plants, etc.), outdoor fires, and distress. From the scenarios, the following core requirements are identified for systems for supporting firefighting and rescue.

Fig. 1.

The concept of a hierarchical structure of IoT systems.

(1) A hierarchical structure of IoT systems: An IoT system for aiding firefighting and rescue is usually composed of multiple IoT systems, like a system of systems. As shown in Fig. 1, an IoT system that is connected with various sensors and devices (e.g., visualization devices, environment sensors, bio sensors, etc.) can be deployed in a firefighter’s field equipment, then the system can collaborate with other IoT systems deployed in other firefighter’s equipment or in a field command center. These IoT systems can be seen as local IoT systems, while they collaborate each other and form a global IoT system. Therefore, our target system architecture has to support this hierarchical system-of-systems structure.

(2) Flexible configuration of local and global IoT systems for adapting variabilities: The sensors and devices that are connected with a local IoT system is variable (i.e., optional or alternative) according to cases of disaster situations; For example, infrared (IR) cameras are typically used in most of situations, while chemical sensors are used only in specific cases. Our target architecture must be easily configurable based on the variability. Also, a global IoT system may consist of different/various local IoT systems according to disaster response schemes. Our architecture needs to provide flexible composition of IoT systems.

(3) Mobility and dynamic configuration of network connection: For the collaboration of local IoT systems, they must be connected via network (e.g., Wi-Fi, Sub-GHz, etc.). Fig. 2 shows two different network connection configuration examples. As the number of firefighters in a group and movements of them are varied according to situations, mobility of IoT systems deployed in firefighters’ equipment is necessary and the local network among the systems needs to be dynamically configured.

(4) Flexible configuration of application services and support for augmented intelligence services: The application services provided by IoT systems are various according to disaster situations, types of connected sensors/devices, disaster response schemes, etc. For example, GPS-based positioning service is useful in outdoor fires, but may not be applicable in indoor fires. Our architecture has to support flexible configuration of application services.

Fig. 2.

Network connection configuration example.

In addition, sometimes there is a need of augmented intelligence services in complex and dangerous disaster situations. Using these services, an IoT system can combine information received from others and provide more useful (augmented) information (e.g., route guidance service reflecting obstacles detected by other systems). Providing rule engine that can support augmented intelligence services may be very helpful in those disaster situations.

Based on these requirements, we propose a core system architecture in the next section.

3. The Proposed System Architecture

To satisfy the requirements analyzed in the previous section, the core system architecture is proposed in this section. The proposed approach is based on the software product line engineering (SPLE) paradigm. SPLE is a reuse paradigm that helps organizations develop a family of software systems from reusable common assets. Compared to traditional application-specific software development, product line-based development can reduce maintenance cost dramatically, because organizations maintain common assets rather than a number of similar systems.

Applying this paradigm, the proposed architecture (Fig. 3) is a reference architecture that is composed of mandatory and variable (i.e., optional or alternative) components and that can be instantiated into architecture instances for specific system. In Fig. 3, rectangles with bold lines represent optional elements that can be included or excluded based on situations where the system is applied.

Fig. 3

The proposed system architecture (reference architecture).

The entire system (i.e., global IoT system) is composed of multiple local IoT systems, each of which includes devices/sensors that are mandatory (e.g., communication module) or optional (e.g., smartwatch, IR camera, oxygen sensor, etc.). The local IoT systems communicate and collaborate via the distributed bus, thus it is easy to change the local IoT systems and re-configure the entire system.

Each local IoT system provides services that are mandatory (e.g., working state management, devices/ sensors configuration, work history logging, etc.) and optional (e.g., indoor/outdoor positioning [2-4], escape route navigation, explosion detection, etc.) and managed by the core framework. The core framework registers/unregisters services and manages the life-cycle of services. It also manages key resources used by and/or shared among various services and provides subscription/notification about certain conditions of resources. Various services can access to the resources using Representational State Transfer (REST) style API [5] provided by the framework.

The key resources and system information managed by the framework are stored (and also restored) using DBMS. The spatial DBMS (such as SpatiaLite) is optionally included in the system when spatial operations are required by a service(s) (e.g., map matching, escape route calculation, etc.).

The rule engine is optionally included in the system when an augmented intelligence service(s) is included. It provides inference of logical consequences from a set of asserted facts. Existing engines such as Drools [6] can be utilized as the rule engine.

The feasibility of the proposed architecture is validated in the next section.

4. An Application of the Proposed Approach: A System of Systems based on the Architecture

To validate the feasibility of the proposed reference architecture, a system of systems based on an architecture instance was developed and tested. The selected disaster scenario for this study is indoor fire scene at a building where infrastructure including electric power and communication was destroyed. In the scenario, three firefighters begin firefighting and rescue in the building.

The system architecture for the selected scenario is presented in Fig. 4. It is an architecture instance of the reference architecture (Fig. 3); the rule engine and spatial DBMS were excluded and devices/sensors and services only required for the scenario were included in the system. For example, IR camera for heat detection, smart watch for firefighter’s bio-signal monitoring, pedestrian dead reckoning (PDR) device for indoor-positioning were included in the system. Also, applications for controlling these devices/sensors and for providing salient services such as indoor positioning, indoor explosion detection, firefighter’s bio-signal monitoring, and escape route guidance were included and implemented in the system. In the implementation, the core framework was developed based on AllJoyn middleware that supports distributed client-server operations, and SQLite was used as the DBMS.

Fig. 4.

The architecture of the system used in the study.

We developed the prototype of the local IoT system as follows. The components in one local IoT system are deployed in one firefighter’s equipment. A firefighter is equipped with the selected devices/sensors such as head-up display, UWB device, and PDR device. The service applications (except PDR service), core framework, and DBMS are deployed in the master processor board (MPB) of the hand-held device. PDR service application that requires very frequent communication with the PDR and UWB devices is deployed separately into the slave processor board (SPB). The PDR and UWB devices are connected to SPB, and other devices/sensors and SPB are connected to MPB via wired or wireless connection.

The testbed was 5th floor of the 12th research building in Electronics and Telecommunications Research Institute. In the testbed, we first prepared one test performer equipped with the local IoT system and validated that the services were provided as we intended. The sate management application (Manager App. in Fig. 4) manages firefighter’s working state (e.g., entering the scene, returning, and finishing) and devices’ states (e.g., connected, initiated, and running, disconnected). In the working state, the system provides services (such as indoor-positioning, map display, bio-signal monitoring, air respirator monitoring, explosion prediction, etc.) that can support firefighter’s activities. In the returning mode, the system displays and guides escape routes for the safety of the firefighter, and finally in the finishing mode, the system saves the work history and sends it to the work history server. We also tested the performance of the local IoT system and the average time for receiving sensor data and processing it in the corresponding applications was within 1.5 seconds.

After testing one local system, we prepared three test performers (as the scenario assumes that three firefighters entered the scene of a fire), each of which equipped with the local IoT system, then we made the performers walk on different routes in a same floor of a building. In the test, the local IoT systems successfully formed a local wireless network and collaborated each other by sharing key information (e.g., emergency status of firefighters). When we tested the performance of the global IoT system (i.e., a system of local IoT systems), the average time for delivering emergency information of one local system to others was within 2 seconds.

More details about the system and test results of this study are introduced in [7].

5. Conclusion and Future Work

In this paper, the requirements of the IoT system aiding firefighting and rescue in various disaster situations were analyzed and the reference architecture for the system was proposed. Our contributions are (1) to present the reference architecture that is more flexible and applicable to various disaster scenarios compared to the existing systems and (2) to provide an application of the architecture, a system of systems for a fire disaster scenario, which showed the feasibility of the proposed approach.

We plan to develop and apply systems for the different disaster scenarios based on the proposed architecture, and the architecture will be refined based on the findings and feedbacks. We also have a plan to apply the rule engine and develop augmented intelligence services; we will develop disaster response rules based on the Standard Operating Procedure for the scene of disaster and implement services supporting decision-making in disaster situations.

Acknowledgement

This research was supposed by the Field-oriented Support of Fire Fighting Technology Research and Development Program funded by the National Fire Agency (No. MPSS-Fire Safety-2015-83) and supported by Electronics and Telecommunications Research Institute grant funded by the Korean government (No. 18ZH1100, Distributed Intelligence Core Technology of Hyper-Connected Space).