Collaborative AmI technologies have the potential to increase the efficiency and effectiveness of rescuers during crisis response work. However, few AmI technologies are designed specifically for such scenarios. Our findings from a number of case studies have resulted in a set of requirements. In this paper we present some of these findings. We then present a second generation AmI tool that was developed to support our users. The tool is a jacket equipped with a number of sensors/actuators allowing coordinators to draw the attention of rescuers in the field and to provide them information and commands. The tool is currently undergoing evaluation in collaboration with our users.
The ability to get accurate and on-time situation awareness and to coordinate rescuer
teams effectively is essential for crisis management. The efficiency of response
actions impacts directly on the extent of damages, the number of saved lives and the
reduction of risks for rescuers. A major challenge for rescuers on the fields is to
combine tasks that require full concentration and physical effort with the use of
communication and collaboration tools. Today, a number of technical tools, such as
computers, sensors, cameras and ad-hoc networking equipment, are regularly
operated by rescuers in disaster areas. Pervasive and ambient computing technology
can be applied to support the rapid and accurate collection of data, and efficient
decision-making, and situational awareness [
This paper focuses on the user interface with the system. We explore tangible user interfaces that can be integrated in a smooth and non-intrusive manner in the rescuer environment, and plugged in and shared in a collaborative software tool. An example of such tangible interfaces, a smart jacket, is presented. In addition, related to cognitive aspects, we explain how the capabilities of the presented tool can be exploited to reduce abruptions when sharing information during a rescue.
This paper is structured as follows: Section 2 shortly introduces the research approach. Section 3 describes our findings from a number of case studies and observations of users. Section 4 and 5 describe our scenario and how our implementation can potentially solve some coordination problems for the rescuers. Section 6 presents the system implementation. Finally Section 7 concludes this paper and presents our future research plan. 2
Our research follows the design science paradigm [
Our research started with two sets of domain-related data from two European R&D
projects, Mirror1 and SOCIETIES2. As part of the Mirror project, a set of case studies
and observations involved rescuers from the Italian civil defence during a simulation
of a massive disaster held in 2011 in Italy [
User studies carried out during a simulation of a massive disaster held in 2011 in Italy have shown that rescuers still rely largely on handheld transceivers (e.g. walkietalkies) to communicate and coordinate the work. During rescue operations, the rescuers are given instructions by a coordinator through radio broadcasts. At the same time, they have to communicate back information, such as their position, environmental data (temperature, humidity, air quality) in a half-duplex communication channel. Rescuers need to remember and execute the tasks they are assigned to (by the coordinator) without any technological aid. In the meantime personnel in the coordinator side transcribe radio communication and update the positions of the teams and data they have collected using annotations on a map.
We divided our analysis based on the two main users in our scenarios: the rescuers (in the disaster field) and the coordinators (in a back office or in a tent coordinating the rescue). From an AmI perspective, the rescuer role is the most interesting one. Our observations showed that the usage of consumer hardware, like touch-screen smartphones or tablets, is not a good design choice for the rescuers. Indeed rescuers wear touchscreen-unfriendly gloves, require high screen readably, and depend on high battery capacity. Also, they often wear blouses without additional pockets for such devices. Furthermore the design should avoid requiring the rescuer to interrupt her task in order to interact with the tool.
The first prototype of a tangible and wearable device to support data capturing and inter-role coordination was developed in the shape of a wristband (Figure 1). It supports automatic capture of the rescuer’s location, environmental temperature and noise, and it is able to display text messages broadcasted by the coordinators. The rescuer can send a digital acknowledgement to the coordinators, for example when a task has been accomplished, without interrupting the work (using gestures and proximity-activated buttons). An early evaluation of the prototype with users has revealed a good acceptance of the system. However, the size of the tool and its wearability weren’t considered satisfactory. The users called for a smaller device and asked for a user interface able to be operated leaving hand and lower arms totally free to operate in the rescue scene.
Based on our observations the following application scenario (see Figure 2) is set up and implemented. The scenario will be evaluated by the USAR team in SOCIETIES. Background. An earthquake of magnitude 7.8 with epicentre about 32 km SouthWest of the island of Cyprus has caused severe damage and casualties. The local response capacity is exceeded and the government of Cyprus has requested international assistance. Several international rescue experts, like USAR and medical support have been sent to Cyprus to support the local emergency management. Initial technical setup. All team members are equipped with Android devices running the collaboration tool iDisaster. Knut the coordinator uses an Android tablet (simulating a laptop), while Tor the rescuer uses an Android touch-based phone (see Figure 2). As part of the initial setup (prior to the operational phase in the field) the following actions are performed by the coordinator and each rescuer: Knut (Coordinator): 1. Creates teams: Knut uses iDisaster GUI to create a new team called "Larnaca" with information about the mission, location of the mission, and other relevant information about the disaster. 2. Adds rescuers to the team: Knut browses a directory of rescuers and adds the ones needed for this mission, including Tor. After the rescuers are added, they get access to the "Larnaca" shared space provided by iDisaster, created in step 1 above. 3. Recommends services: Each mission will have specific needs regarding what tools will be used. Knut browses a directory of services and adds them as recommended services to the shared area for the team to use. One of these services is iJacket. Services give access to external physical tools such as sensors and actuators.
Tor (Rescuer): 1. Installs recommended services: After Tor is added to the "Larnaca" team he receives a notification and is asked whether he wants to add the recommended services (apps) to his phone. He answers yes and some software is downloaded and installed automatically on the smart phone. 2. Sets up services and tools: One of the services that were recommended by Knut was the iJacket service. This is a service that supports communication with the smart jacket that all rescuers wear (see Figure 3). Tor scans the jacket QR-code to establish connection between his Android smartphone and the smart jacket (Figure 3.B). The service displays the set of actuators and sensors available on the jacket. Tor can test that they all work properly: display, loudspeaker, LED lamp and vibrator are all operative.
Operation in the field. Following the preliminary set up, all rescuers have now joined their teams. Knut coordinates individuals and teams using the iDisaster GUI and the services. Using the iJacket client, he commands Tor to examine the structure of a building in the Athenon street. Tor’s jacket immediately vibrates and displays the command. Later, as the weather forecast indicates shifting winds, he sends a warning to all team members in Larnaca. The LED lamps on their jackets are switched on. At any moment, the team members can, using iDisaster, retrieve the messages sent to the teams or to themselves.
Rapid and undisruptive coordination of actions and situation awareness are the main goals of the system. This is done through a) A light-weight mechanism for sharing of information: The system supports real-time sharing of information that is posted in a shared space called a CIS (Collaborative Interaction Space). "Larnaca" in the example above is a CIS. b) Undisruptive interaction mechanism, in particular for the rescuers: Rescuers should be able to concentrate on their tasks. Physical user interfaces support peripheral awareness of situations without the need for complicated operations. The system interface, in form of the smart jacket, tries not to compete for their attention.
In this phase of our research we have focused mainly on the "Operation in the field" part of the scenario. We have tried to apply points a) and b) to the field operation phase. The "Initial technical setup" might seem too complicated in its current form. There are a number of opportunities to improve the setup phase such as using templates and recommendations. One particular example is the use of QR codes and NFC tags to facilitate the setting up of tools such as the smart jacket and other sensors/actuators. This is already part of our implementation. In the near future we will do more experiments in order to improve the initial setup phase. 6
We are using a number of exiting platforms to realize our scenario.
Arduino4 boards and sensors/actuators are used inside the jacket in order to implement the physical prototype. Figure 3.C and D show how the physical prototype looks like. Figure 4 below shows how this is done in the overall architecture. Android OS5 and devices are used to implement the remaining parts of the user interaction (the middle box of Figure 4). Virgo and OSGi6 are used for implementing a back-end where shared data from a CIS is stored and accessed by the various Android devices (left-most box in Figure 4).
On top of the above platform we have built a number of components (shown as grey boxes in Figure 4): CIS Manager: This is a back-end component that stores data about shared spaces (CISs). It provides interfaces for creating, managing and notifying about changes. 4 http://www.arduino.cc/ 5 http://android.com/ 6 http://www.eclipse.org/virgo/
CIS Manager client: This is an Android-based client for CIS Manager. It is implemented in form of an Android Content Provider7. It communicates with CIS Manager using XMPP messaging technology8. iDisaster and iJacket: These are Android applications that allow coordinator and rescuer to interact with and configure the functionalities provided by CIS Manager and the smart jacket.
Bluetooth library (BT lib) and Jacket app are Arduino-based applications that facilitate communication between iJacket and the real jacket.
Our near future work is to evaluate the current prototype with our users. Our focus will be on the user interaction mechanism, which metaphors are suited for crisis management work and which hare not, and get feedback on what sensors and actuators will be necessary for a real field deployment of such a physical tool. In the long run we want to collect and systematise knowledge about what interaction metaphors are empirically proven to work in the similar scenarios where physical work is in focus.
From a technical point of view, our goal is to develop a library or toolkit of primitives that will make it easier for application developers to develop similar physical applications on top of Arduino and Android.
Acknowledgments. Our research is supported by EU IST 7th framework programme. This paper results from the collaboration between the projects SOCIETIES (contract 257493) and Mirror (contract 257617). 7 Content providers are a standard way of providing access to shared data in an Android device. 8 http://xmpp.org