An Integrated Platform For Autonomic Computing For Disaster Relief Operations

Introduction

During the last few years, humanity has faced a number of humanitarian disasters due to physical phenomena (earthquakes, floods, drainage, and so on) and warfare (civil, between neighbouring states). One of the main obstacles in delivering humanitarian aid is, in most cases, the lack of communications and information infrastructure at the area of disaster. Additionally, the complexity of human relief operations is increasing due to the fact that humanitarian aid is delivered by a number of heterogeneous organizations (governmental agencies, non-governmental organizations [NGOs], and other non-governmental humanitarian agencies [NGHAs]) according to humanitarian principles set out in Resolution 46/182 of the United Nations General Assembly (for governments and UN agencies), and in the Code of Conduct for the International Red Cross and Red Crescent Movement and NGOs in Disaster Relief (for NGHAs), using different types of equipment and with various communication capabilities. In such a situation the Integrated Platform for Autonomic Computing (IPAC) proposed in this paper [1] can leverage the gap in communications by providing meaningful information fine-tuned to the needs and capabilities of the agencies rushing at the area of disaster. IPAC aims to deliver a service-creation and runtime (service-provision) environment for autonomic communications. IPAC tries to address several challenges of autonomic computing, such as reliable and efficient algorithms for information dissemination in autonomic environments, developer-friendly application creation, automatic discovery of deployed sensors, and knowledge-based node reconfiguration. The main contributions of IPAC can be summarized as follows:

• A developer-friendly graphical user interface (GUI) for building and debugging IPAC applications. This GUI also comes with a custom application description language and a respective workflow language that enable developers to write applications in an abstract way.
• Short-range communication technologies that support a novel probabilistic information dissemination model. This model is based on the concepts of [2] and is appropriate for environments with nomadic nodes with limited energy resources.
• Knowledge-based reconfiguration for embedded systems. IPAC is one of the first attempts to support mobile reasoning and relevant mechanisms for providing service intelligence. Similar work in this area can be found in [3,4].
• Adoption of the IEEE 1451 [5] standard for implementing plug and play sensors. IEEE 1451 is an evolving standard that promises a new era of sensor enabled applications, through easy integration of diverse sensor technologies.
• Collaborative context awareness. IPAC nodes can use contextual information for adapting the application execution even if they do not have attached sensors. Specifically, they can ‘harvest’ sensor data and contextual events from their local neighbourhood through a publish/subscribe mechanism.
• Provision of infrastructure-less communications with various levels of context delivery according to specific roles and missions.

Main technical objectives

The lightweight and flexible IPAC middleware provides all services required for the deployment and execution of diverse applications in a collaborative nomadic environment. These services are supported by novel knowledge and ontology engineering techniques, dealing with interoperability, integration, and re-configuration/adaptation problems encountered in contemporary embedded platforms. Figure 1 presents an overview of the IPAC middleware. Being collaborative, IPAC relies on short-range communications (such as ZigBee, DSRC, and Bluetooth) for the ad-hoc realization of dialogues between nodes. Being context-aware, IPAC relies on advanced sensing components thus, delivering highly innovative application architecture.

IPAC is based on sophisticated information dissemination algorithms [6]. Specifically, it relies on rumour-spreading techniques. Rumour spreading involves the propagation of information within a certain network. Information is propagated only to immediate neighbours that are interested in specific content (rumour). Therefore, IPAC incorporates recent research advances in the area of bio-inspired computing systems.

Mobile nodes in IPAC are specified and developed to be non-selfish with respect to information dissemination (a mobile incarnation of a peer-to-peer system). Specifically, the IPAC nodes operate in a collaborative fashion in order to diffuse contextual information and broader knowledge in their environment. A node propagates an information message received by another node across the network. In case that such message appears to be usable for the node, it can process it. An information message that is of no interest to an IPAC node has to be forwarded across the network for further processing. The same path is followed for the dissemination of new applications or application components after their development thus contributing to the deployment and use of new embedded applications. IPAC integrates techniques and algorithms for energy-efficient, autonomic node behaviour, advanced context awareness, embedded service/application modelling, and efficient information dissemination.

Technical approach

IPAC pursues the development of a middleware platform for embedded devices with specific characteristics. IPAC also aims at the delivery of an application creation and runtime environment for autonomic computing. Autonomic nodes enter in the proximity of other nodes and relay relevant information in the form of ‘rumour spreading’. Target applications include traffic management, in-building guidance, industrial environment control, as well as crisis management. For instance, vehicles equipped with an IPAC device may forward information to one another regarding the road conditions (such as congestion and accidents) so as to improve circulation, and avoid potential accidents. Another potential application domain of IPAC is road advertising, or advertising in large commercial centres. Individuals in a shopping centre obtain useful and timely information (for example, where a specific product may be found, discounts, special offers, and so on) through the autonomous information exchanging of their IPAC devices.

The platform is supplemented by an application creation environment. Within the scope of IPAC, the application creation environment refers to all tools, APIs and libraries, which assist the development of new applications for IPAC nodes. It is responsible for providing a sophisticated interface to developers in order to be able to define applications as well as their properties. This is to be done in an efficient, user-friendly manner that also allows for reusability of design and code. It is a software module that is able to be run on a standard computer and coexists and cooperates with well-known third party software. It will provide a visual and a textual interface (see Figures 2 and 3) to developers and tools for testing and emulating every application before their deployment in IPAC nodes.

Applications may be preinstalled on the node or deployed on demand by the user. Nodes may be considered as sources of information stemming from various sensors mounted on them or from human user input. Such information may be disseminated from one node to another in the network, thus, catering for a distributed, autonomic information propagation platform. In order to have meaningful and controlled information dissemination, the spreading of information is governed by space-time validity rules (directives). For instance, a message concerning congestion at a crossroad would be valid for less than one hour and within a radius of some kilometres.

The IPAC uses the short-range communication (SRC) technology for achieving communication between autonomic entities, thus, enhancing bandwidth and reducing latency in the communication link. Contrary to other wireless technologies (such as GSM) SRC operates in short distances, thus, enabling the formation of relatively small and isolated communication zones. In addition, IPAC explores the possibility of applying wireless sensor network technologies for implementing short range communications. An indicative example of such a technology is the 802.15.4 protocol (ZigBee) targeting to devices with low battery consumption constraints that need to continuously transmit information.

Key issues

IPAC develops embedded middleware technology for the realization of innovative context-aware services by autonomous nodes. Supported by ad-hoc network infrastructures, IPAC proceeds to the study of situation-aware and context-aware services deployed by numerous and mostly dynamic network groups and communities. Context awareness allows autonomic nodes to sense and adapt to their environment, not only at the network level but also at the application plane. This adaptive behaviour will be supported by knowledge-based methods and technologies, in a highly innovative manner.

Therefore, the key contribution of IPAC is a novel embedded middleware and service provision platform that brings considerable intelligence to the device. None of the existing research projects or products, in the academic or industrial context, has implemented all the self-CHOP (self-configuration, self-healing, self-optimizing and self-protecting) characteristics, and additionally offer self awareness and context awareness, which are of major importance in many environments. IPAC addresses all the self-CHOP requirements and thus provides a solid, efficient and future-proof platform.

IPAC in disaster relief operation

In order to verify the usefulness of IPAC in disaster relief operations a number of trials is scheduled to take place in the Multinational Peace Support Operating Training Centre (MPSOTC) in Kristoni, Kilkis, near Thessaloniki http://www.mpsotc.gr/. The trials will focus on the deployment of IPAC infrastructure in simulated humanitarian operations in order to provide a much needed communication infrastructure (Figure 4.)

In order to capture user requirements for the IPAC a survey was conducted to experts from MPSOTC and the Hellenic Army General Staff. The questionnaire was organised in five categories as follows:

• Personal details.
• Device Requirements.
• Interface Requirements.
• Process Application Requirements.
• System Evaluation.
• Other (free comment).
• This questionnaire formulated the trials scenarios and the specific requirements for the devices and the applications of IPAC systems as expected by users.

The main trial will focus the deployment of IPAC infrastructure in simulated humanitarian operations in order to provide a much-needed communication infrastructure for the execution of multiple applications in a collaborative nomadic environment. Being collaborative, IPAC relies on short-range communications for the ad-hoc realization of dialog between autonomous nodes. The trial environment will simulate various scenarios common in a humanitarian crisis zone (such us relief-force establishment, and reception of refugees or NGOSs at disaster zone) where other communications are non-existent. In this case, the IPAC infrastructure will assume the role of communication support between pedestrians and vehicles, or between static check points and vehicles or pedestrians of the operations workforce.

The provision of assistance in a usually dangerous and potentially hostile environment, results in the need for full interoperability of personal communications. Since some of the information transmitted will either be critical or confidential, IPAC security support will be tested. , The deployment of large-scale assistance upon short notice, typically hours or days, results in the double requirement of rapid deployment and economical and operational appropriateness.

One characteristic that affects and possibly limits telecommunications technologies in Humanitarian Assistance is the provision of assistance by institutions and organizations from several countries, resulting in the need to consider special regulatory aspects.

Furthermore, the possibility of sensor integration will be investigated, in order to provide warning and alerts about possible dangers in the vicinity of the IPAC devices.

Some of the characteristics of that scenario include:

• high mobility of users,
• high traffic density,
• co-operation with non emergency services, and
• multiple groups of emergency workers.

One humanitarian-assistance mission is the provision of critical invasive and supportive care of sick and injured citizens and the ability to transfer the people in a safe and controlled environment. The need for communications services for medical services providers inside and outside of the vehicles is vital. Information required by them includes:

• Patient Information.
• Medical Information.
• Incident Information.
• Geographical Information.
• Real time Information.

Emergency systems must be able to inter-operate with other agency systems. Bio-medical information needs to be transmitted with guaranteed accuracy. Accurate medical information is also required to be transmitted to the medical persons to enable them to give the best possible patient care.

The ability to send and receive relevant information concerning several patients at the same time from the same scene without interference or corruption is also required.

Convoy movement

Furthermore, the system is primarily intended for convoys of vehicles with vehicle-to-vehicle and vehicle-to-infrastructure communications. Therefore, one important aspect of the architecture is the capability of the system to provide a coordinated view to all vehicles (such as road/environment conditions, and air pollution) and minimize movement deviations across the convoy. This can be handled as a qualitative objective.

Some features of the convoy network include the following:

• Emergency vehicle location tracking.
• Emergency vehicle route guidance.
• Emergency vehicle signal priority.
• Automatic collision notification.
• In-route driver information.
• In-vehicle communication (such as communication between driver and/or co-driver with personnel at the back of a truck).
• Incident detection and management.
• Probe data for traffic control.
• Transit management.
• Automated roadside inspections.
• Automated vehicle classification.
• Hazardous materials incident response.
• Collision avoidance.

Patrolling

In this context information exchange become critical to elaborate a specific, targeted and fast response to the situation and to better co-ordinate all the units through one common objective. Another important point to notice during these kinds of operations is that in a lot of cases public infrastructure are unavailable. It is very important to ensure a stable and expansive communication path from remote areas where terrestrial infrastructures may be unavailable or unusable due to natural or man-caused disasters.

The first responder in the field should be provided with devices that can move or gather material, perform complex and/or difficult mechanical tasks, provide remote audio information from dangerous or obstructed areas, provide detailed analysis of chemicals, environmental or hazardous materials and, in general, serve as a real-time extension to the first responder.

Some applications as the following:

• rescue of people from hazardous areas;
• remote chemical analysis;
• excavation of material in hazardous areas;
• remote mapping and analysis of dangerous structures or areas such as damaged buildings, bridge structures, tunnels, mines or caves;
• remote search and rescue;
• automated inspection of non-accessible areas; and
• land mine clearing.

During patrolling, users should have access to a variety of data including

• structural data,
• environmental data, and
• personnel data.

For each of the aforementioned scenarios the following roles and responsibilities will be supported:

Roles and responsibilities

The distinct roles, which somebody may have in a mission, are the following:

• Convoy: During the convoy the following distinct roles are identified:
• Convoy Leader: Is the operational leader of the convoy. All the decisions considering the movement of the convoy such us (driving speed, duration of stops, distance between vehicles, and so on) are under his authorization. In general he is co-driver in the first vehicle of the convoy, but he/she can move in every direction within or out of the convoy.
• Convoy Security Officer: Is the second in command at any convoy. He is substituting the convoy leader whenever he is not available. He is located at the last vehicle of the convoy.
• Convoy Maintenance Vehicle: Maintenance vehicle is located at the end of the convoy just before the vehicle of convoy’s security officer. It can move in any direction within the convoy whenever a vehicle requests technical assistance.
• Convoy Medical Vehicle: Medical vehicle (ambulance) is located at the end of the convoy just before maintenance vehicle. It can move in any direction within the convoy whenever a vehicle requests medical assistance.
• Vehicle co-driver: He is located in any vehicle and he is responsible for the communications between the vehicle and the convoy leader or the other supporting vehicles and between the driver and the personnel at the back of the vehicle whenever those personnel are present. His responsibility is also the use of any driving aid (maps, GPS, RF transceivers, and so on).
• Head of personnel at the back of a vehicle: He is responsible for the communication between the personnel carried by a vehicle and the vehicle co-driver.
• Rest Scenarios: In the rest of the scenarios that are going to be tested in Kilkis, the following roles are identified:
• Check point: Is the main control point of the IPAC infrastructure. Furthermore is the gateway of IPAC devices to other networks.
• Patrol leader: He can be on foot or within a vehicle. He is responsible for the communication (reporting, send-receive orders) between patrol and the check point.
• Medevac leader: He can be on foot or within a vehicle. He is responsible for the communication (reporting, send-receive orders) between med evacuation team and the check point.
• Chem-Response Team Leader: He can be on foot or within a vehicle. He is responsible for the communication (reporting, send-receive orders) between the chemical response team and the check point.
• Unexploded Ordinance Team (UXO): He can be on foot or within a vehicle. He is responsible for the communication (reporting, send-receive orders) between UXO team and the check point.
• Non Governmental Organization Member: He/she is part of an NGO who also operates within the Area of Responsibility of the check point. He/she also carries an IPAC device and must be able to receive-send general (non restricted) information.

According to the questionnaire all participants in a mission should have the ability of radio communications (voice and data) and of defining the location of other nodes. Convoy maintenance vehicle, convoy medical vehicle and vehicle co-driver should have the ability of vehicle-to-vehicle communications and vehicle inspection. Convoy security officer and medevac leader should have chemical contamination sensors.

Types of communication

Vehicles and personnel deployed in this training facility will carry IPAC devices with the purpose of optimally coordinating the overall activity. Automobiles, assisting in crisis management accumulate dynamic information on random occurrences. This is also fused with indications of human activity. This information must be forwarded so as to reach the base camp. People in base camp will evaluate and exploit the information they receive and will take measures resulting in the handling of difficult conditions in an effective way.

The IPAC system should make communications between:

• vehicles (intra-convoy);
• vehicles and pedestrians (moving IPAC nodes – convoy); and
• static check points and vehicles or pedestrians.

Expected impact

The expected impact of IPAC spreads beyond the strict limits of the embedded devices sector. The applications supported have a profound impact on multiple human activities, especially in the context of humanitarian relief operations where currently are characterized by the lack of communication infrastructure and the vast amount of different organizations with various types of communication equipment in most of the times non interoperable.

Acknowledgements

The author would like to acknowledge the fruitful contribution of Stathes Hadjiefthymiades, George Samaras, Eleftherios Fytros, Vassileios Tsetsos, Damien Piquet, Christoforos Panayiotou, Stauroula Giatili, all significant members of the IPAC consortium to this paper.

(This work was supported in part by the European Commission through the FP7 ICT Programme in the scope of the project IPAC (Integrated Platform for Autonomic Computing), contract FP7-ICT-224395.)

References

Author

Dr. P.K. Kikiras is a graduate from the Hellenic Army Military Academy and holds a PhD in electrical engineering from the National Technical University of Athens. Currently he is an adjunct Associate Professor in the Department of Computer and Networks Engineering at the University of Thessaly Greece. Furthermore, has scientific responsibility for the implementation of IPAC project on behalf of the Hellenic Ministry of National Defence .