The current issue and full text archive of this journal is available at www.emeraldinsight.com/1750-6166.htm
Resource sharing using UICDSe framework for incident management Basit Shafiq Center for Information Management, Integration and Connectivity (CIMIC), Rutgers University, New Brunswick, New Jersey, USA
Soon Ae Chun
Resource sharing using UICDSe
41 Received 9 November 2010 Revised 22 March 2011, 9 April 2011 Accepted 10 May 2011
College of Staten Island-City University of New York, Staten Island, New York, USA, and
Vijay Atluri, Jaideep Vaidya and Ghulam Nabi Center for Information Management, Integration and Connectivity (CIMIC), Rutgers University, New Brunswick, New Jersey, USA Abstract Purpose – Pertinent information sharing across various government agencies, as well as non-governmental and private organizations, is essential to assess the incident situation, identify the needed resources for emergency response and generate response plans. However, each agency may have incident management systems of its choice with valuable information in its own format, posing difficulty in effective information sharing. Application-to-application sharing cross agency boundaries will significantly reduce human efforts and delay in emergency response. Information sharing from disparate systems and organizations, however, requires solving of the interoperability issue. The purpose of this paper is to present the UICDSe-based resource sharing framework as a step toward addressing the afore-mentioned challenges. Design/methodology/approach – A prototype middleware system is developed using a standards-based information sharing infrastructure called UICDSe (Unified Incident Command and Decision Supporte), an initiative led by the Department of Homeland Security (DHS) Science and Technology division. This standards-based middleware, resource management plug-in utilizes the ontology of organizational structure, workflow activities and resources, and the inference rules to discover and share resource information and interoperability from different incident management applications. Findings – The middleware prototype implementation shows that the UICDSe-based interoperability between heterogeneous incident management applications is feasible. Specifically, the paper shows that the resource data stored in the Resource Directory Database (RDDB) of the NJ Office of Emergency Management (NJOEM), Hippocrates of the New Jersey Department of Health and Senior Services (NJDHSS) can be discovered and shared with other incident management systems using the ontology and inference rules. Research limitations/implications – This study illustrates the possible solutions to the application to application interoperability problem using the DHS initiated interoperability platform called UICDSe. Originality/value – The resource discovery and emergency response planning can be automated using the incident domain ontology and inference rules to dynamically generate the location-based incident response workflows. Keywords United States of America, Resource sharing, Information management, Information systems, Incident response ontology, Resource discovery, Interoperability, Unified Incident Command and Decision Supporte (UICDSe), Workflow visualization Paper type Research paper
Transforming Government: People, Process and Policy Vol. 6 No. 1, 2012 pp. 41-61 q Emerald Group Publishing Limited 1750-6166 DOI 10.1108/17506161211214813
TG 6,1
42
1. Introduction The essential components of effective emergency management and response include pertinent information sharing across various government agencies as well as non-governmental and private organizations to assess the situation, identify the needed resources for emergency response and generate response plans. Interoperability is a key requirement for information sharing from disparate systems and organizations, such as the case in emergency response. Such information sharing is critical for: . identifying the resource and logistics requirements for emergency response operations such as evacuation, sheltering, food and medical supply, infrastructure restoration; . discovering appropriate agencies/organizations that can collectively satisfy the resource requirements; and . integrating allocation, tasking, dispatch, and mobilization processes along the resource supply chain across various agencies/organizations to ensure timely delivery of needed resources. Similar to the SAHANA FOSS Disaster Management System which serves as an information repository, a more dynamic and complete system is needed. The clear and obvious necessity of such a system can be seen through the example below. Consider a chemical tank explosion scenario (NRF, 2008). Some of the critical mission areas identified in this scenario are evacuation and sheltering of downwind populations, providing medical care to victims, and conducting hazard mitigation operations involving decontaminating victims and responders and performing site remediation. For an effective emergency response encompassing all of these mission areas, information sharing among the response agencies is critical for determining: . What activities need to be performed? . Where these activities need to be performed? . What resources are needed to perform these activities? . Who can provide these resources and support the response activities? For example, for identifying and obtaining resources related to evacuation and victim care, first the region to be evacuated needs to be identified. This requires integration and analysis of a wide range of data and models such as weather reports and forecasts provided by National Oceanic and Atmospheric Administration (NOAA) and smoke/plume dispersion forecast and its possible effect on population and environment provided by the State and/or Federal Environmental Protection Agencies in coordination with NOAA. Additionally, information about sites in the affected area that store/use hazardous materials (nuclear fuel/waste, biochemical agents) helps to determine what type of hazmat team and equipment is needed for clearing hazardous materials. Similarly information such as number of people that need to be sheltered, people with special needs or have disabilities/medical conditions is needed for sheltering logistics management including food and water supplies and medical services. This information comes from special needs registry managed by state, counties, and town municipalities. In addition, the resource inventory and availability information from various agencies, retailers, and private suppliers facilitates in obtaining these resources
in a timely manner. For example, if there is a scarcity of resources within the local jurisdictions, those resources can be requested from other neighboring jurisdictions. In addition to information sharing between response partners, the coordination of the response activities, i.e. the response process, will enhance the collaborative efforts to mitigate the situation. Designing this global collaborative process is a huge endeavor that requires pre-incident meetings and policy agreements. Given the dynamic nature of the emergency management environment and the differences in the roles, responsibilities of the agencies/organizations and the resources they can provide, pre-designing response plans is never complete. A tool that can generate the response plan in ad hoc manner as a workflow may be useful to augment the pre-plans. To achieve these two goals, i.e. resource discovery/sharing and response process generation, we propose an ontology-based resource management framework that assists the process designer and incident commander in discovering response activities and resource requirements of activities, and gather the resource information to compose a collaborative response process for further evaluation and execution to manage a given emergency situation. This framework uses context parameters such as type and location of the incident, severity of the incident, resource requirements, and resource availability in government, non-governmental and private organizations. It also considers the rules and policies of relevant organizations for mobilizing and committing their resources. The ontology-based resource sharing framework consists of: . ontology library for modeling incident types and resources as semantic objects; and . reasoning engine for deriving the resource requirements and emergency response plans based on the incident-related context information and the policies of different agencies and modes of cooperation. This ontology-based resource management approach is proposed as a resource management middleware (plug-in) for a standards-based information sharing middleware infrastructure called Unified Incident Command and Decision Supporte (UICDSe) which is a major initiative by the Department of Homeland Security (DHS) Science and Technology division to promote the information sharing and situation awareness in emergency situation. This paper presents UICDSe-based resource management prototype implementation to illustrate resource visibility, information sharing, and interoperability among different New Jersey State agency systems, including the Resource Directory Database (RDDB) of the NJ Office of Emergency Management (NJOEM), and Hippocrates of the NJ Department of Health and Senior Services (NJDHSS). It also shows how the information can be shared with open source community-based systems such as SAHANA. The prototype implementation also includes a workflow component that uses a reasoning engine to infer the incident response-related activities and resource requirements to compose a response plan as a workflow based on the ontology model and context information. Each activity in the workflow discovers resources through the resource management plug-in component. The prototype also includes a GIS-based interface to visualize the location of resource availability along with other situational awareness (SA) data for effective decision making related to emergency management. The rest of the paper is organized as follows. Section 2 presents an overview of the UICDSe framework. Section 3 describes the proposed approach for resource management
Resource sharing using UICDSe
43
TG 6,1
44
and Section 4 describes prototype implementation. Section 5 provides a discussion on how this work addresses technology-related challenges for enabling information sharing and interoperability among incident management systems across agencies and jurisdictions. Section 6 presents conclusion and some future work directions. 2. UICDSe-based resource management and coordination There are several challenges related to interoperability for resource management coordination among the response agencies. For example, agencies do not follow a common standard for providing access to their resource databases or for exchanging information for resource ordering, requisitioning, and tracking. Moreover, there is a lack of standards and mechanisms for sharing response plans, policies, and procedures for resource management coordination. For addressing this challenge, UICDSe information sharing infrastructure is adopted in our ongoing work with New Jersey State for achieving interoperability and information sharing among the different New Jersey’s State agency systems for improved SA and resource management coordination. 2.1 UICDSe framework UICDSe is a DHS Science and Technology initiative to architect, develop, and deploy a middleware foundation that enables information sharing and interoperability among commercial and government incident management technologies for improved SA and common operating picture (COP). The architecture of UICDSe shown in Figure 1 is based on the design criteria taken from the National Response Framework (NRF, 2008), National Incident Management System (NIMS) and the Incident Command System (NIMS, 2008). UICDSe adopts standards-based service-oriented architecture (SOA) Adapter
HTTP, SOAP, WSDL, NIEM, EDXL-RM, Atom, WS-Notification, WSTopic, UICDS IEP, CAP
User Agent
UICDS CORE
UI
Persistent Incident Data
Computer External Incident Mgmt. Application
App. Adapter User
Personalization & Config.
Incident Mgmt. Services
Info.Mgmt. Services
• Sensor
Services • Agreement • Notification • Tasking • Profile
• Incident Cmd. • IAP • Incident Mgmt. • Resource • Forms
• Tools Exec. • Directory • Product • Query • Doc. Mgmt.
SA & Visualization Services • Map • Logging
Reference To External Apps.
User
GIS (External)
Comm. & Message • Alert • IM • Email • Bradcast • Pub./subs • Collaboration
UICDS Services OGC– SOS
OGC– WMS, WFS
External Incident Mgmt. Application
Agent Network
Integration Services
EDXL–RM
Sensor Suite (External)
Open Search
OGC–WPS
Adapter
Adapter
Resource Mgmt. App. (External)
Service/ Simulation (External)
Adapter
External DB
Data Service (External)
Adapter
UICDS CORE
Situational Awareness DB
Reference To External Apps.
HTTP, SOAP, WSDL, NIEM, EDXL-RM, Atom, WS-Notification, WSTopic, UICDS IEP, CAP Integration Services •Sensor SA & Visualization Services •Map •Logging
Personalization & Config. Services •Agreement •Notification •Tasking •Profile
AgentNetwork
Incident Mgmt. Services •Incident Cmd. •IAP •Incident Mgmt. •Resource •Forms
TCP/IP Network
Comm.& Message •Alert •IM •Email •Bradcast •Pub./subs •Collaboration
Info. Mgmt. Services •Tools Exec. •Directory •Product •Query •Doc. Mgmt.
UICDS Services
Adapter
HTTP, SOAP, WSDL, NIEM, EDXL-RM, Atom, WS-Notification, WSTopic, UICDS IEP, CAP
UICDS CORE OGC– WMS, WFS
OGC– SOS
EDXL – RM Adapter
Open Search
OGC – WPS Adapter
Adapter
Integration Services
Persistent Incident Data
Reference To External Apps.
• Sensor SA & Visualization Services • Map • Logging
OGC– WMS, WFS
Figure 1. UICDSe architectural components
GIS (External)
Sensor Suite (External)
Source: Morentz et al. (2009)
Resource Mgmt. App. (External)
Service/ Simulation (External)
GIS (External)
External DB
Data Service (External)
Agent Network
Personalization Incident Mgmt. Info.Mgmt. & Config. Services Services Services • Agreement • Notification • Tasking • Profile
Comm. & Message
• Alert • Incident Cmd. • Tools Exec. • IM • Directory • IAP • Email • Incident Mgmt. • Product • Bradcast • Query • Resource • Doc. Mgmt. • Pub./subs • Forms • Collaboration
UICDS Services OGC– SOS
Sensor Suite (External)
EDXL–RM
Open Search
OGC–WPS
Adapter
Adapter
Resource Mgmt. App. (External)
Service/ Simulation (External)
Adapter
External DB
Data Service (External)
for enabling information sharing and interoperability. A major advantage of this approach is the support for incremental addition of middleware components and data adapters for enabling interoperability with the existing incident management applications by different vendors as well as new applications developed by the open source and research community. Currently, UICDSe provides standards and data models for the following aspects of incident management applications: . Sharing of geospatial data and map documents. . Command and coordination structure for incident management. . Incident management, resources, and personnel tasking. . Incident planning and document management. . Sensors and alert management. External incident management applications communicate with the UICDSe components using web services as shown in Figure 1. The UICDSe architecture is a federated system of interconnected “core servers”. A UICDSe core server communicates with external incident management applications or other data services to gather incident-related information which is stored in the UICDSe SA database. This information can be disseminated to or can be queried by any external incident management system. For such information exchange with external incident management applications/systems UICDSe provide a set of web services as shown in Figure 1. The external applications/systems connected with the UICDSe core are called UICDSe client. The message exchange between the UICDSe client and a given UICDSe service must follow the standard for the given service. In case the client’s native application is not compatible with such standard, middleware components and data adapters need to be developed and employed by the client application. These middleware components and data adapters will convert the client application’s non-standard messages into standard messages for the UICDSe services and vice versa. 3. Ontology-based approach for resource management A primary aim of an emergency response planning and execution system is to assist the incident commander and response personnel in planning and execution of the response processes for a given emergency situation. Such a situation can be characterized by several context parameters such as type and location of the incident, severity of the incident as local, state, or federal level emergency, resource requirements, and resource availability with relevant agencies. To enable effective response, there is a need to integrate resource management with applications that provide a COP to the incident commander. As discussed in the later sections, the utility of such a tool can be exponentially increased if it coupled with the UICDSe framework to allow seamless information sharing. One way of modeling a response process is as a workflow of activities with certain resource requirements. Depending on the resource requirements, time constraints, and jurisdictions, the activities in a response process can be executed by different agencies in coordination with each other. Given the dynamic nature of the emergency management environment and the differences in the roles and responsibilities
Resource sharing using UICDSe
45
TG 6,1
46
of agencies across jurisdictions, several questions arise when planning and executing an incident-specific response process: . Given a particular emergency situation in a specific location, what are the different default response actions and associated activities? . What resources are required for the default actions and associated activities? . What are the primary and supporting agencies that have jurisdictional authorization for the given emergency management activity in the given location? . What are the resources available with these agencies that can be used for the given emergency situation? . If there is a scarcity of resources, what are the other agencies or volunteer organizations (in order of priority) that can provide these resources? Since many of these issues require automated reasoning capabilities, an ontology-based reasoning framework is employed for the resource management system. This is also tightly integrated with the incident command console application to allow response process workflow management as well as collection and GIS-based visualization of data and information from a number of sources such as situation reports, alerts, weather, traffic, hospital information, school location, fire company location, News, census information, socio-economic data, disability statistics, etc. Figure 2 shows the overall system architecture along with the components and features of the incident resource management system and its interaction with an incident command console application. The resource management component includes a knowledge base encompassing emergency management ontology and a rule engine to reason about required resources and potential responders for resolving an incident. Detailed description of the resource management component is given below. Incident Management Console (Response planning, execution, and monitoring) Response Process Workflow Management
GIS-based Visualization of Data Layers
Knowledge Base Rule Engine Default Actions & Response Plans Ontology
Figure 2. Architecture of resource management system to support incident command system for response planning, execution and monitoring
Resource Management System
Resource Provider Directory
Incident Mgmt Policies & Procedures
Data Services
Resource DB
Agency 1
Incident Mgmt Policies & Procedures
Resource DB Agency n
3.1 Emergency management ontology Ontologies are essential components of knowledge management systems and are a necessary prerequisite for any kind of automated reasoning. A comprehensive emergency management ontology needs to include domain knowledge (in the form of concepts and their relationships) from various domain ontologies related to emergency management. Some of these domain ontologies include: . An ontology for organizations covering various government agencies and non-governmental organizations that can directly or indirectly support emergency management activities; their jurisdiction, roles, and responsibilities; type of resources they can provide, etc. . An ontology for resources providing characterization of emergency management resources, including personnel and equipment. These resources are characterized based on NIMS standards (NIMS, 2008). . An ontology for response activities covering aspects related to emergency management activities and services such as aid delivery; medical services; food and shelter; victim triaging; onsite-treatment; transportation, etc. . An ontology for geo-spatial location covering the geographical aspects related to disaster location and emergency management operations. . An ontology for humanitarian aid covering aspects related to the different types of disasters requiring humanitarian aid; disaster management and relief operations; types of resources needed and organizations involved in such operations; humanitarian aid programs, etc. . An ontology for hazard mitigation covering aspects related to the hazardous materials, their effects to humans and environment during or after an incident, appropriate mitigation efforts, etc. . An ontology for transportation covering aspects related to transportation of victims, aid workers, resources, hazardous materials, etc. The above list of domains is not comprehensive. However, these domains encapsulate information relevant to emergency management as identified in the literature, e.g. AKTiveSA (Smart et al., 2005, 2007) and the emergency management scenarios (NRF, 2008). For developing the emergency management ontology, a scenario driven approach is adopted in this paper. This approach enables integration of relevant domain ontologies and supports expansion of the ontology with knowledge from new domains as identified in the planning scenarios. For integrating these domain ontologies, a base ontology is needed that links the emergency management concepts to the concepts in the specific domain ontologies as well as links concepts across domains. This paper uses the AKTiveSA knowledge web ontology as a base. The AKTiveSA ontology focuses on information fusion and enhanced situation awareness in military operational contexts other than war such as humanitarian assistance and disaster relief (Smart et al., 2005, 2007), and does cover concepts from many of the domains described above. However, the specific concepts are only detailed at a generic level, which makes AKTiveSA more of a mid-level ontology (Niles and Terry, 2004). Therefore, AKTiveSA needs to be significantly expanded to include a fine-grained characterization of concepts in the relevant domain ontologies. This is done using a scenario driven approach, by considering several incident-specific
Resource sharing using UICDSe
47
TG 6,1
48
scenarios such as hurricane scenario, wildfire, and chemical plant fire. For each of the scenarios, the support functions at the federal level, state level, and local level are listed. From a given scenario specification, use cases are derived to identify different actors (e.g. agencies, persons, applications), their roles and functions, and the interaction among them. Starting with a use case and AKTiveSA as a base ontology, the actors in the use case are mapped to the appropriate concept class in the base ontology. If the concept class is not present in the base ontology, it is added and linked to the appropriate high-level concept in the base ontology. Interactions between actors in the use case are represented as property (relation) between corresponding concept classes. The ontology base is then expanded by integrating the concepts in the base ontology with other concepts in the relevant domain ontologies including the ones listed above. The overall emergency management ontology is represented in ontology web language (OWL) formalism and follows the structure and elements of a regular OWL ontology, including classes, class hierarchy relations, properties, constraints/restrictions, and rules. The emergency management ontology also includes policies and rules of agencies with respect to emergency management and response. The rules in the ontology may be global (i.e., applying to all the agencies in the ontology), regional (i.e., applying to the agencies in specific regions), or agency-specific. Examples of the specific kinds of rules are as below: . Global rule. All local agencies must respond to a disaster incident within their jurisdiction if they have available resources needed for disaster response. . Regional rule. Within the State of Nebraska, any state agency that supports wildland fire protection can mobilize its resources for responding to a wildland fire incident if all the local agencies have exhausted their resources. . Agency-specific rule. The Hudson County Fire Department in New Jersey State can respond to any fire related disaster in a neighboring county in New York State. Figure 3 shows an illustration of the structure and elements of the emergency management ontology using the chemical plant fire class as an example. This figure depicts the class hierarchy and the object properties associated with the chemical plant fire class. The range of the object properties associated with chemical plant fire class is also shown in Figure 3. 3.2 Reasoning and inference engine The reasoning and inference engine is the most important component in the design, planning, and execution of response processes. Reasoning and inference is performed based on the specific instances in the ontology such as disaster instance, response agencies, available resources with agencies, and their rules. It is not feasible to generate all such instances in the emergency management ontology in advance and perform reasoning based on those static instances. For example, resource availability with agencies changes dynamically and cannot be included in the ontology statically. Similarly, there may be volunteer organizations in different localities who may not be known a priori and cannot be statically loaded in the ontology in advance. Moreover, the rules of agencies may get changed depending on the situation and context as well. For reasoning and inference, relevant instances in the ontology are dynamically loaded and reasoning is performed in an iterative manner. However, to increase
Location
Plant Fire (Properties)
•Building Address •Block Address Firefighting Region
Disaster Human Natural Earthquake
•Building •Street Address Address •Block Address •Polygon region with geo-coordinates Region to be Evacuated
Fire DomesticFire Plantfire Wildfire
•Street Address •Block Address •Polygon region with geo-coordinates
Response Activities (suggested) •Firefighting •Evacuation •Victim care -Burnt injuries -First aid • • •Traffic management •Hazmat removal • •
Flood Hurricane
Potential Responders
Landslide
•Firefighting -City/town Fire Dept -County Fire Dept -State Fire Coordinator • • •Victim care -City/town Health dept -Local Hospitals -County Health Dept. -Local/County OEM -State OEM -Local Community Centers • • •Hazmat Removal -County EPA -State EPA -US EPA
Tornado Tsumani Typoon Volcano Weather Response Activity Response Agency Response Resource SpatialRegion USLocation
Resources •Firefighting •Hazmat Fire team •Fire Engine • • •Victim care -Burnt injuries •BurnDMAT (team) • • -First Aid •BasicDMAT (team) • •
Resource sharing using UICDSe
49
Potential Responder Resources •Firefighting -City/town Fire Dept •Fire Engine •Basic fire Team -County Fire Dept •Hazmat Fire team -State Fire Coordinator • • •Victim care -City/town Health Dept. •BasicDMAT (team) •BurnDMAT (team) -Local Hospitals •Trauma care facility •Burnt victim facility •-County Health Dept. •Paramedic team for victim transportation • •
the efficiency, some of the instances that are generic and common to all emergencies are statically loaded in the ontology right from the start. Example of such instances include location instances (e.g. city, town, state); Federal and State Agencies; global and regional rules, etc. Our proposed methodology for reasoning and inference can be summarized in the following steps: (1) When a disaster incident is reported, an instance of the disaster is created under the appropriate disaster class using the disaster type information in the incident report. Additionally, properties such as disaster location, disaster severity, possible injuries and damages are assigned values based on the information in the incident report. (2) Using the properties determined in Step 1 and the information in the ontology, reasoning and inference engine is used to determine the following: . All the local agencies that have jurisdiction over the disaster location. These agencies are then loaded into the ontology. Here it is assumed that there are available registries that list agencies with their territorial jurisdiction. These registries also provide link to the web services of these agencies that can be used to query their resource databases and policies/rules. . Based on the type and severity of the disaster, the activities that may be required for response. . The type of resources needed for the response activities.
Figure 3. Class hierarchy and properties of chemical plant fire class in the emergency management
TG 6,1
50
(3) For the agencies identified in Step 2, their resource databases are queried to determine available resources. These resources are loaded into the ontology against the respective agencies. Additionally, the policies/rules of these agencies are queried and loaded as rule instances in the ontology. (4) The reasoning and inference engine is invoked again to match the agencies identified in Step 3 against the response activities based on their resource availability status and policies. In case, the local agencies do not have the needed resources for one or response activities, the above steps are repeated for other neighboring local agencies, county agencies, and so on. For reasoning and inference with our emergency management ontology, JESS rule engine is used. JESS is a JAVA-based inference engine developed by Sandia National Lab (Friedman-Hill, 2008). It is to be noted that in the reasoning and inference process, inconsistency in ontology may arise when conflicting rules and policies of agencies are loaded. This is an important issue that needs to be addressed for discovering available resources and identifying agencies that can support the response activities. This is planned in our future work. 4. Prototype: UICDSe-based resource management This section discusses the prototype implementation of the proposed approach in the context of incident management and data service applications. 4.1 Incident management applications and data service applications The New Jersey State Government has developed several web-based systems to store state-wide resource data that can be used for emergency response. Specifically these data service applications include: . Hippocrates is the health emergency SA and response system that connects the health response systems within the State of New Jersey. Hippocrates provides SA by collecting, integrating and analyzing real-time and static health data such as: medical facility baseline information including contacts, bed counts, medical supplies; hospital diversion status; EMS vehicles location and status information; medical stockpile information. It provides the capability to monitors health system status on a daily basis and supports informed decision making during a health emergency. Hippocrates is compliant with the HAVBED standards by US Department of Health and Human Services for sharing of hospital bed availability and diversion status information. . New Jersey RDDB identifies and catalogs all the state, county, and municipal resources available within the State of New Jersey for response to an emergency situation. The resource status information in this database is regularly updated by respective resource owner agencies. This database has been developed as part of the New Jersey State Emergency Preparedness Information Network (EPINet) program for improving the emergency management and law enforcements capabilities. In addition, government agencies adopted commercial incident applications to manage the incidents. These are often commercial off the shelf incident
management systems, and nowadays include some open source incident management systems. Examples include: . COTS incident management systems. State or local agencies use their incident management system such as E-team or WebEOC, to manage incidents and to communicate. . Open source disaster management system. In addition, the resources from open source disaster management systems such as SAHANA can be shared through UICDSe Resource Management plug-in. SAHANA is a web-based collaboration system to manage missing people, volunteers and aids as well as tracking the government agencies, NGOs and victims during a disaster.
Resource sharing using UICDSe
51
When an incident occurs, the government agencies have to look up necessary data stored in the above data service applications in parallel with their own incident management systems. In order for the resource data in one of the above data service system to be shared with the incident management system, UICDSe core is augmented with resource management middleware plug-in that enables interoperation between the external applications for resource discovery, ordering, and tracking. Below is a description of the proposed extensions of UICDSe for resource management. 4.2 Resource management middleware plug-in Figure 4 shows the architectural components of the resource management middleware within the UICDSe framework. As depicted in this figure, the agencies incident management applications and resource databases (such as NJ RDDB and Hippocrates) interact with UICDSe core services to acquire incident-specific response plans, mission knowledge, and make resource allocation decisions. As can be seen, the UICDSe core is extended with the following components: Client Applications Incident Mgmt. Console WEB-EOC NY State
ED
UICDS Core
XL
-R
Resource Requester
M
M -R
Resource Management Agent
Resource Service
• Discovery • Routing
XL
Rule Engine
ED
Profile Service
RDDB
UICDS Situational Awareness DB
NJ State OEM Alert Service
NJ State
Hippocrates NJ DHSS
CA ED P; XL -H A
Special Needs Registry
Resource Provider Directory
Resource Status Database
VE
Resource Provider
Ontology
• Request/response tracking • Resource status querying
EDXL-RM SAHANA Open Source Disaster Management System
Figure 4. Extended UICDSe core with resource management middleware component (shaded area)
TG 6,1
. . . . .
52
resource management agent; resource ontology; rule engine; resource provider directory; and resource status database.
The existing UICDSe framework includes a resource service that allows a client application with other external resource applications using OASIS Emergency Data Exchange Language Resource Messaging (EDXL-RM) standard (OASIS Emergency Management Technical Committee, 2009). The UICDSe resource service simply provides the functionality of forwarding the EDXL-RM messages to the intended recipients explicitly identified in the message. It does not support the capability for discovering the resource providers in case these are not known to the requesting application. The extension to the UICDSe core not only address the resource provider discovery issue but also facilitates rapid information exchange between the requester and potential resource providers for timely allocation, tasking, and mobilization of needed resources. The functionality of ontology and rule engine components in the extended UICDSe core is the same as discussed in Section 3. Therefore, only the resource service and resource management agent and their interactions with other components will be discussed below. Resource service. The UICDSe resource service provides operations for resource discovery, ordering/requisitioning, and status tracking. Additionally, the resource providers use this service for providing availability status of their resources, offering resources unsolicited, and committing resources to requesters. The resource service uses the EDXL-RM standard for message exchange with the client applications that may be requesting for resources or responding to resource requests. EDXL-RM specifies 16 types of messages for supporting major communication requirements related to resource management coordination across the emergency incident life cycle. These include preparedness, pre-staging of resources, initial and ongoing response, recovery, and demobilization/release of resources (OASIS Emergency Management Technical Committee, 2009). A major functionality of the resource service is to perform routing of the messages between sender and recipient applications. However, in many cases the recipient information may not be specified. For example, an incident commander may request resources from other states and may not know the specific agencies that can provide the requested resources. In this case, the system needs identify the appropriate agencies and route the request to these agencies. This requires reasoning with consideration for several factors, including location, type, severity, of the disaster, mutual-aid agreements between agencies and their policies/procedure as discussed in Section 3. For handling such resource requests, the resource service interacts with the resource management agent which in turns utilizes the ontology and rule engine to identify the relevant agencies. Resource management agent. The resource management agent interacts with other components of the extended UICDSe core to provide the following functionalities: . Resource identification. A requester may query the resource service for the resources needed for a particular response activity such as evacuation
.
.
in a chemical plant fire incident. This request is forwarded to the resource management agent, which utilizes the emergency management ontology to identify the appropriate resources. Resolution of resource naming and typing conflicts. The resource management agents uses the ontology to resolve any naming or resource typing conflicts in the resource message exchanges between resource requester and provider systems. Discovery of resource providers. For any resource request that does not specify the resource provider agency, the resource management agent interacts with the ontology, rule engine, resource provider directory for discovering resource providers. The steps for discovering the resource providers are discussed in Section 3.2. Specifically, the resource management agent loads the instances of the agencies identified from the resource provider directory based on their location and jurisdiction. In addition, the resource management agent queries the resource database of these agencies (e.g. RDDB) and load the resource data instances in the ontology under the appropriate resource type for reasoning and inference about the potential responder agencies.
In addition to discovery of the potential responders, the resource management agent also supports the resource request and ordering process by enabling a message exchange between resource requester and resource providers. In case the requester needs to decide whom to send the resource request, the list of the potential resource providers with resource availability status is sent to the requester who then resubmits the request to the selected providers: . Tracking of resource request and response messages. For any resource request messages that the resource management agent has proactively sent to the potential resource providers, tracking of the request and response messages is performed to ensure that the request is not lost and the requester receives all the response messages. . Resource status querying. The resource management agent queries the resource databases of different agencies on a regular basis to keep an update of their resource status (e.g. type of the resources, quantity, policies and procedures for resource ordering/requisitioning). This information is stored in the resource status database in the extended UICDSe core and supports the reasoning and inference process discovering resources and resource provider agencies. 4.3 Response workflow management and sharing resources To illustrate the functionalities of the resource management middleware, the incident management console (called iTeam) has been developed. iTeam assists the incident commander and response personnel in planning and execution of the response processes by providing a visual interface for: management and tracking of response process workflow; indicating regions where response activities need to be carried out; tasking and assignment of resources for various response activities; and GIS-based fusion and visualization of different data layers (Figure 2). Below is a description of the components of the incident management console. GIS visualization with situation awareness data. The incident command console allows collection and visualization of data and information from a number of sources
Resource sharing using UICDSe
53
TG 6,1
54
such as situation reports, alerts, weather, traffic, hospital information, school location, fire company location, news, census information, socio-economic data, disability statistics, etc. This data is overlaid on a GIS that comprises of several layers. Response process workflow management. This component facilitates incident commander with visualization, activation, status monitoring, management, and adaptation of the given emergency response process. Specifically, it provides the following functionalities: . Visualization of the workflow associated with a given response process in a graphical manner. . Identifying the resource requirements for each response activity and the agencies that can provide the needed resources based on the reasoning performed by the resource management system. . Requesting/ordering of needed resources from agencies that have such resources available. . Tracking the status of all the activities in the response process workflow. The status can be in progress, not started, awaiting resources, completed, etc. . Specifying the regions where response activities need to be carried out, e.g. residential blocks that need to be evacuated, sections on the road that need to be cleared for free flow of emergency management vehicles, etc. Incident commander can specify such regions by drawing a geo-fence on the map for each specific activity. . Adaptation of a response process both before and during the execution of the process to respond to changing situation. Such adaptations include addition of new activities, modifications/changes (reassignment, rescheduling) of the planned activities, and removal of one or more of the activities from the original process. Figure 5 shows some of the functionalities of the response process workflow management component implemented in our research prototype system. In this figure, a portion of the response process workflow for a fire incident in a chemical facility is depicted. One of response activity in this workflow is clearing hazardous materials (hazmat response). For the hazmat response, the activity status, resource requirements, and the agencies with available resources identified by the system are depicted on the left side of Figure 5. From the list of agencies an incident commander can select one or more agencies for ordering, requisitioning, and deployment of the selected resource. Additionally, the incident commander can specify the region where the response activity needs to be carried out as shown in Figure 5 for the hazmat response activity. Resource management in response workflow. The response workflow component uses resource management to fulfill the resource requirements of each activity in the workflow. The interaction focuses on the message exchanges among resource requesting applications, resource management agent, and resource provider applications for discovery and ordering of resources. For each workflow activity, the resource management agent generates an EDXL-RM request information (RI) message to discover necessary resources. For example, the RI message destined for RDDB contains the explicit address element to RDDB application. As discussed above, RDDB stores the availability information of all the local, county,
Evacuation
Resource sharing using UICDSe
Shelter Service
Start Node Fire fighting
Clearance Inspection
Hazmat Response
55
Hazmat Response Primary agency: NJDEP. Status: In progress Region: 2 blks b/w Stanley Support agencies: Bellmawr Fire Dept; Ave. & Harding Ave. in Camden Cnty. Bellmawr, NJ Environmental agency;
Resources Needed • Hazmat entry team • Foam Tender • Brush Patrol • Portable pump • Protective CPC • Vapor-protective CPC
Agencies (with Hazmat entry team) NJDEP Hazmat entry team Type III Available Qty: 4 Deployment time: 1 hr Camden Cnty. Fire Dept. Hazmat entry team Type I Available Qty: 2 Deployment time:15 min..
!
and state agencies with New Jersey. The RI message also specifies the jurisdiction level of agencies whose resource availability need to be queried. For example, the resource availability data is requested from the county level agencies of Camden and Burlington counties and the local agencies of Bellmawr and Cherry Hill towns. Also, in the RI message the category of the resource (e.g. fire fighting, law enforcement) can be specified. When the resource database application (e.g. RDDB) receives an RI message, it queries the database for availability status against the agencies with the specified geographical and hierarchical jurisdiction for all the resources in the requested resource category. It then uses the query result to generate an EDXL-RM response to RI (RRI) message, including the list of agencies with their contact information and the resource availability status. The UICDSe core upon receiving the RRI message forwards it to the resource requesting application. The incident commander or appropriate response personnel can use this resource availability information to select the appropriate agency for requesting the needed resources. For this, the client application generates an EDXL-RM resource request (RR) message. This RR message includes the name and NIMS type description of the requested resource, quantity of the resource needed, requested arrival time, and the reporting location and person. The resource provider agency when receiving the RR message can accept the request with the requested quantity, accept with changed quantity, or deny the request. In all cases an EDXL resource commit message is sent to the requester. In case of denial, the quantity element in the commit message is set to zero. When a resource provider agency accepts the request, it needs to provide the committed quantity of the requested resource which may be less than the requested quantity as well as the scheduled departure and arrival time in the commit message.
Figure 5. Example of an emergency response process workflow allowing incident commander to monitor the response activity status, make resource ordering for the response activity, and specify region where the activity needs to be performed
TG 6,1
56
Figure 6 shows a screen shot of the workflow component interacting with resource management component. In this figure, the top window shows the response process workflow, including the fire fighting, evacuation, hazmat response, and shelter management activities. The incident commander selects the firefighting activity and the UICDSe Resource management agent performs resource discovery and forwards the results to the client resource management workflow application. The resource discovery results for the fire fighting activity are depicted in the middle window of Figure 6. Based on this the incident commander or response personnel can select the agency which has the needed resource available and send a resource request message shown in the bottom window of Figure 6. 5. Discussions In the context of emergency response, coordination among the various federal, state, tribal, and local agencies for resource management is guided by NIMS that provides an organizational structure for effective execution of emergency response functions (NIMS, 2008). However, this structure can function only if there are policies,
Figure 6. Screen shot of workflow management application
procedures, and mechanisms in place among these agencies for facilitating all aspects of resource management, including resource discovery, requisitioning, delivery, deployment, costing, and reimbursement (Adam, 2010). At the policy and procedure level, agencies share their resources through mutual aid agreements (Adam, 2010). These mutual aid agreements can be made at intra-state level (NEMA, 2004), interstate level (EMAC, 2007). Additionally, Federal agencies may also make mutual aid agreements with state and local agencies in different areas. For example, the US Department of Agriculture has made Wildland Fire Management Agreement with different states facilitating coordination and sharing of personnel, equipment, and other material resources for disaster assistance (CFMA, 2007). Beyond establishing policies and procedures for mutual aid, there is a need for automating all the aspects of resource management process for timely delivery and deployment of resources. The level of automation for resource sharing amongst agencies and jurisdictions varies from one state to another. In many states, the process for resource discovery and requisitioning is still manual with emergency managers making phone calls or emails to inquire about resource status or ordering resources with other agencies and jurisdictions (Adam, 2010). Specifically, resource visibility and mutual aid automation across states is not widely supported due to the lack of interoperability across states’ incident management and resource management systems. The key challenges that need to be addressed to overcome this lack of interoperability include: . Agencies in different states use non-standard terminology for naming and describing their resources. For example, emergency management services (EMS) in the New York City use the term “Bus” for “ambulance.” The EMS professionals in other regions often use different names for ambulance, for instance “Medic Unit”, “Box”, and “WAGON”. . Resource management systems across states often use non-standard processes for resource ordering, tracking, and costing. . The policies and procedures of the agencies for resource sharing through mutual aid are not encoded into the resource management systems that support automated processes for resource management. The UICDSe-based resource sharing framework presented in this article is a step toward addressing the aforementioned challenges. It employs emergency management ontology with a detail categorization of resources based on the NIMS resource typing (www.fema.gov/emergency/nims/ResourceMngmnt.shtm). NIMS resource typing definitions provide a standard description of resources that are commonly exchanged for disaster assistance through mutual aid agreements. Moreover, these resource typing definitions allows the agencies to examine their resources, identify their capabilities, categorize them according the NIMS resource typing standards, and use such standard resource typing and description when proving information about their resources for disaster assistance. Moreover, the ontology provides a structure for linking different names/description of the same resource to its conceptual class, thus providing the capability to resolving naming heterogeneity. For addressing the second challenge listed above, UICDSe framework employs the EDXL-RM standard for exchanging resource messages across systems (OASIS Emergency Management Technical Committee, 2009). As discussed in Section 4.2,
Resource sharing using UICDSe
57
TG 6,1
58
EDXL-RM is an open source standard developed by the Organization for the Advancement of Structured Information Standards (OASIS) for supporting major communication requirements related to resource management coordination across the life cycle of the emergency incident. Finally, the proposed framework allows encoding the policies and procedures of different agencies as rules in the system as discussed in Section 3.1. These rules are incorporated in the ontology using the Semantic Web Rule Language (W3C, 2004) and are considered when reasoning about the emergency response plan as discussed in Section 3.2. Resource management requires real-time access to distributed resource data-bases/repositories to make critical decisions in the context of incident management and supply chain provisioning. Often times, the types of resources available and the resource databases providing such information are not known “a priori”. Also, at times networks may form dynamically specially in case of community resources. There is also a significant work done by the research community that can be leveraged to address the semantic heterogeneity and interoperability related challenges. A majority of this work is done in the context of enterprise information integration (Halevy et al., 2005) and business process automation. Mainly this work focuses on schema mapping and schema integration in distributed database systems (Ullman, 1997; Rahm and Bernstein, 2001; Miller et al., 2001; Do and Rahm, 2002; Lenzerini, 2002). In addition, work done on distributed workflow management systems in distributed, enterprise-wide applications (Muth et al., 1998; Atluri et al., 2007) can be leveraged for designing and developing resource management processes across agencies and jurisdictions. Despite this large body of work on information integration, sharing and interoperability, there are very few projects in academia that focus on the design and development of an integrated system in the emergency management context. Responding to Crisis and Unexpected Events (RESCUE) is one such project that aims at transforming the ability of organizations to gather, manage, analyze and disseminate information when responding to man-made and natural catastrophes (Lickfett et al., 2008; Ashish et al., 2009). However, RESCUE mainly focus on the SA aspect of incident management and response and does not provide resource management capabilities for emergency response planning and management. 6. Conclusion and future work The DHS initiative UICDSe framework is a SOA-based middleware between application systems of different organizations and aims at providing the capabilities that allow emergency responders to capture important incident-related information, analyze captured information, more effectively disseminate mission critical information to emergency responders, present decision guidance options for emergency response community, effectively coordinate efforts of emergency responders, and store incident-related information for analysis. The proposed ontology-based resource management plug-in extends UICDSe Core services to enable information sharing and interoperability among the different incident management applications used by the various state, county and local agencies. This UICDSe-based approach to application-level information sharing does not force the agency officials to give up their favorite information systems, such as E-team, WebEOC, or other home-grown incident management application systems. The presented approach and prototype
implementation go beyond traditional resource management, allowing application-to-application level interoperability by intelligently discovering, requesting and deploying resources that are often stored scattered in different organizations but need to be shared seamlessly for the emergency response. In addition, the system also provides capabilities that compose and visualize the emergency response process in the form of a workflow and support status monitoring, execution, and adaptation of the response process. Moreover, the system provides a geographical interface for visualization of SA data. As part of the future work, the plan is to collaborate with the UICDSe standards development team to contribute towards the development of standards within the UICDSe framework for supporting interoperability among a wide range of incident management systems in various domains such as healthcare, cyber systems, and transportation. The standards will not be limited to data models and data exchange protocols, but will also encompass security, privacy, and access control requirements of data owners. References Adam, N.R. (2010), “Workshop on emergency management: incident, resource, and supply chain management”, Final Report, US Department of Homeland Security, Washington, DC. Ashish, N., Lickfett, J., Mehrotra, S. and Venkatasubramanian, N. (2009), “Rapid information integration for emergency response”, paper presented at Workshop on Emergency Management: Incident, Resource, and Supply Chain Management (EMWS09), Irvine, CA, 5-6 November. Atluri, V., Chun, S., Mukkamala, R. and Mazzoleni, P. (2007), “A decentralized execution model for inter-organizational workflows”, Distributed and Parallel Databases, Vol. 22 No. 1, pp. 55-83. CFMA (2007), California Master Cooperative Wildland Fire Management and Stafford Act Response Agreement, available at: www.fs.fed.us/r5/fire/cooperators/08_cfma_final.pdf (accessed 17 April 2011). Do, H. and Rahm, E. (2002), “COMA: a system for flexible combination of schema matching approaches”, Proceedings of the 28th International Conference on Very Large Data Bases, Hong Kong, China, 20-23 August. EMAC (2007), “Enhancing EMAC’s collaborative and administrative capacity should improve national disaster response”, United States Government Accountability Office Report to the Committee on Homeland Security and Governmental Affairs, US Senate, June. Friedman-Hill, E.J. (2008), Jess the Rule Engine for the Java Platform, Sandia National Laboratories, Albuquerque, NM. Halevy, A.Y., Ashish, N., Bitton, D., Carey, M., Draper, D., Pollock, J., Rosenthal, A. and Sikka, V. (2005), “Enterprise information integration: successes, challenges and controversies”, Proceedings of the 2005 ACM SIGMOD International Conference on Management of Data, Baltimore, MD. Lenzerini, M. (2002), “Data integration: a theoretical perspective”, Proceedings of the Twenty-First ACM SIGMOD-SIGACT-SIGART Symposium on Principles of Database Systems, Madison, WI, June. Lickfett, J., Ashish, N., Mehrotra, S., Venkatasubramanian, N. and Green, J. (2008), “The RESCUE disaster portal for disasters and emergency response”, Proceedings of the 5th International ISCRAM Conference, Washington, DC, USA.
Resource sharing using UICDSe
59
TG 6,1
60
Miller, R.J., Herna´ndez, M.A., Haas, L.M., Yan, L., Howard Ho, C.T., Fagin, R. and Popa, L. (2001), “The Clio project: managing heterogeneity”, SIGMOD Record, Vol. 30 No. 1, pp. 78-83. Morentz, J.W., Doyle, C., Skelly, L. and Adam, N. (2009), “Unified Incident Command and Decision Support (UICDS): a Department of Homeland Security Initiative in Information Sharing”, Proceedings of the IEEE Conference on Technologies for Homeland Security (HST’09). Boston, MA, 11-12 May. Muth, P., Wodtke, D., Weisenfels, K., Dittrich, A.K. and Weikum, G. (1998), “From centralized workflow specification to distributed workflow execution”, Journal of Intelligent Information Systems, Vol. 10 No. 2, pp. 159-84. NEMA (2004), Model Intrastate Mutual Aid Legislation, National Emergency Management Association, Lexington, KY, available at: www.emacweb.org/?1546 (accessed 17 April 2011). Niles, I. and Terry, A. (2004), “The MILO: a general purpose mid-level ontology”, Proceedings of the International Conference on Information and Knowledge Engineering, Las Vegas, NV. NIMS (2008), “National Incident Management System”, Department of Homeland Security, available at: www.fema.gov/pdf/emergency/nims/NIMS_core.pdf (accessed 6 April 2011). NRF (2008), “National Response Framework”, Department of Homeland Security, available at: www.fema.gov/pdf/emergency/nrf/nrf-core.pdf (accessed 6 April 2011). OASIS Emergency Management Technical Committee (2009), OASIS Emergency Data Exchange Language Resource Messaging (EDXL-RM) 1.0, available at: http://docs.oasis-open.org/ emergency/edxl-rm/v1.0/EDXL-RM-SPEC-V1.0.pdf (accessed 6 April 2011). Rahm, E. and Bernstein, P. (2001), “A survey of approaches to automatic schema matching”, The VLDB Journal, Vol. 10 No. 4, pp. 334-50. Smart, P.R., Russell, A. and Shadbolt, N.R. (2007), “AKTiveSA: supporting civil-military information management in military operations other than war”, Proceedings of the 4th International Conference on Knowledge Systems for Coalition Operations (KSCO ), Waltham, MA, USA. Smart, P.R., Shadbolt, N.R., Carr, L.A. and Schraefel, L.A. (2005), “Knowledge-based information fusion for improved situational awareness”, Proceedings of the 8th International Conference on Information Fusion, Philadelphia, PA, USA. Ullman, J.D. (1997), “Information integration using logical views”, Proceedings of the 6th International Conference on Database Theory, Delphi, Greece, 8-10 January. W3C (2004), “SWRL: A Semantic Web Rule Language Combining OWL and RuleML”, W3C Member Submission, 21 May, available at: www.w3.org/Submission/SWRL (accessed 17 April 2011). Further reading Morentz, J.W. (2008), “Unified Incident Command and Decision Support (UICDS): a Department of Homeland Security Initiative in Information Sharing”, Proceedings of the IEEE Conference on Technologies for Homeland Security (HST’08), Waltham, MA, 12-13 May, pp. 321-6. About the authors Basit Shafiq is an Assistant Professor at Lahore University of Management Sciences. He received his Masters and PhD degrees from Purdue University and his Bachelor degree from Ghulam Ishaq Khan Institute of Engineering Sciences and Technology. He also held a position of Research Assistant Professor at Rutgers University. His research interests are in information
systems security, privacy, and semantic web. Basit Shafiq is the corresponding author and can be contacted at:
[email protected] Soon Ae Chun is an Associate Professor in Business Department, and a member of the Doctoral Faculty of Computer Science Program, at the City University of New York. She has been an area chair of an interdisciplinary Information Systems program. She received her PhD in Information Technology from Rutgers University, and MS in Computer Science from SUNY Buffalo. Her research areas include applied informatics, including digital government, workflow, information security and privacy, and semantic web, Web 2.0, and mobile web. Vijay Atluri is a Professor of Computer Information Systems and Research Director for the CIMIC Center at Rutgers University. Her research interests include information systems security, databases, workflow management, data mining, and privacy. She serves as the Chair of the IFIP WG11.3 working group on Data and Application Security and as the Vice-Chair for ACMSIG on Security Audit and Control. She is a recipient of the NSF CAREER Award, and the Rutgers University Research Award for untenured faculty for outstanding research contributions. Jaideep Vaidya is an Associate Professor of Management Science and Information Systems at Rutgers University. He received his Masters and PhD degrees from Purdue University and his Bachelor degree from the University of Mumbai. His research interests are in privacy, security, data mining, and data management. He has received two best paper awards from the premier conferences in data mining and databases, and is the recipient of a NSF Career Award and a Rutgers Board of Trustees Research Fellowship for Scholarly Excellence. Ghulam Nabi is a Software Engineer at the Center for Information Management, Integration, and Connectivity (CIMIC) at Rutgers University. He received his Bachelor and Master’s degrees from the University of Sindh, Pakistan.
To purchase reprints of this article please e-mail:
[email protected] Or visit our web site for further details: www.emeraldinsight.com/reprints
Resource sharing using UICDSe
61
