ScholarWorks @ UTRGV ScholarWorks @ UTRGV An Expert System for Local Flood Response Coordination and An Expert System for Local Flood Response Coordination and Training Training

Flood response is an essential component of flood management to rescue people, reduce property loss, and limit the impact to the environment. Effective flood response depends on a sound coordination structure with unified responsibilities, smooth communications, and scalable response plans. An efficient coordination system, including command and management structures, is built on a thorough understanding of the responsibilities and actions of each role for delivering the response core capabilities. Collecting, sharing, using, and handling the knowledge require great efforts in knowledge management. To further enhance such efforts, an expert system for local flood response coordination and training (LFRS) was developed and introduced in this paper. LFRS can help emergency managers construct scalable, flexible, and adaptable coordination structures and support educating flood response entities, such as individuals, communities, nongovernmental organizations, private sector entities, and local governments. The output of the prototype expert system contains two CSV formatted reports as well as prompt screens. The operational structure report hierarchically depicts the crisscross linkages among all responders, their primary functions, and contact information. Another report summarizes the responsibilities and actions of a certain role of flood responders from commanders to individuals.


Introduction
In the aftermath of accurate forecasting and timely warning of floods, the effective response should be recommended and implemented under the supervision of community authorities, city managers, state governors, or federal officers. However, management of flood response is far more complicated than many other management problems. The response to disasters like flooding is an emergency network with non-linear dynamics, uncertainty, open boundary, and varying topology (Liu, Li, Tu, & Zhang, 2011). Weaknesses in incident management are often due to the following issues: 1) a shortage of clear chained of command and supervision; 2) poor communication caused by inefficient use of communications systems and non-consistent terminology; 3) inadequate and unreliable data of incidents; 4) an absence of an orderly and systematic planning process; 5) a dearth of command and control coordination structure; 6) a lack of flexibility and adaptability of response procedures and plans (DOL, 2016; Select Bipartisan Committee of the U.S. House of Representatives, 2006). In addition, inferior decisions made by inexperienced flood response managers under high pressure and unproductive actions taken by untrained and stressful personnel could lead to unsuccessful flood response (Jennex, 2007). A typical example is an ineffective preparation for and response to Hurricane Katrina, the costliest natural disaster and one of the five deadliest hurricanes in the history of the United States (National Hurricane Center, 2011). Although the National Weather Service and National Hurricane Center forecasts were accurate and timely, a failure of leadership at all levels of government resulted in preventable deaths, great suffering, and tremendous property loss (Select Bipartisan Committee of the U.S. House of Representatives, 2006).
Local government officials often have difficulties in dealing with Federal guidelines (e.g., Interpreting which guidelines supply to their roles). In order to ensure that information moves within agencies, across departments, and between jurisdictions of government seamlessly, securely and efficiently and response plans are adaptable to meet whatever flood scenarios, a sound coordination system with unified responsibilities, smooth communications, and scalable response plans is required. Additionally, to shorten the distance between theory and practice, adequate training on structural roles, responsibilities, and actions to deliver the core capabilities of flood response, is vital for all potential flood response entities, such as individuals and households, private sector, nongovernmental organizations (NGOs), communities, local government, state government, and federal government (Flin, O'Connor, & Crichton, 2008). Development of a computer-based tool could aid in their flood response.

Background
With the purpose of strengthening the security and resilience of the United States through systematic preparation for the threats such as flooding, Presidential Policy Directive (PPD) 8 mandated the National Preparedness System (NPS). A number of projects were launched to develop and perfect the NPS. Among them are the National Incident Management System (NIMS) and the National Response Framework (NRF). The U.S. Department of Homeland Security (DHS) provided the NIMS and the NRF in order to build a framework of response to all disasters and emergencies regardless of size and complexity. NIMS provides the overall template, while NRF provides the structure and mechanisms for the management of incidents.
The NIMS systematically blends accepted best practices into a standard national framework for emergency management. It contains five major components: 1) preparedness, 2) communications and information management, 3) resources management, 4) command and management, and 5) ongoing management and maintenance. The command and management component is designed to offer a standardized incident management structure assisting incident coordination. This structure is based on three critical organizational constructs: the Incident Command System (ICS), Multiagency Coordination Systems (MACS), and Public Information (PI). Among those, the ICS is the most widely used. The ICS hierarchy assists activities in five major functional areas: Command, Operations, Planning, Logistics, and Finance/Administration. Intelligence and investigations is an optional sixth functional area that is activated as needed (DHS, 2008;FEMA, 2016).
The NRF describes managerial doctrine for all types of disasters and explains common response disciplines and process developed at all levels. More specifically, in addition to a scalable, flexible, and adaptable coordination structure, NRF defines other fundamental elements. These include the key roles, responsibilities, and the steps needed to prepare for delivering the fourteen core capabilities: 1) planning, 2) public information and warning, 3) operational coordination, 4) critical transportation, 5) environmental response/health and safety, 6) fatality management services, 7) infrastructure systems, 8) mass care services, 9) mass search and rescue operations, 10) on-scene security and protection, 11) operational communications, 12) public and private services and resources, 13) public health and medical services, and 14) situational assessment (DHS, 2008;DHS, 2013).
To close the gaps in qualified responders, the Federal Emergency Management Agency's (FEMA) National Integration Center (NIC) released the NIMS Training Program in February 2008, originally. This vital program defines the process for developing training and personnel qualification requirements for emergency management (NIC, 2011).
With the aim of increasing community preparedness and resilience for floods, America's PrepareAthon, a national community-based campaign, offers easy-to-implement resources to help individuals, organizations, and communities practice simple, effective actions. The resources include a short video: It Started Like Any Other Day (Williams, 2014), practical handouts (e.g., Prepare Your Organization for a Flood Playbook (FEMA, 2014), How to Prepare for a Flood, How to Prepare for a Flood Guide, Be Smart: Know Your Alerts and Warnings, Be Smart: Protect Your Critical Documents and Valuables, and Ready's Family Communication Plan for Parents and Kids (FEMA, 2016)), and abundant further reference linkages (e.g., Turn Around Don't Drown program at National Weather Service (NWS, 2015), National Flood Insurance Program at FEMA (FEMA, 2017), and Action Guide for Emergency Management at Institutions of Higher Education (DOE, 2009)).

Research Objectives and Methods
Learning, understanding, digesting, and mastering the extensive official documents and all-encompassing heuristic rules on flood response requires remarkable time and energy. The learning package should be individualized to each role of the response personnel. Despite distinct roles and priorities of response knowledge, training all responders with the same reference materials steepens the learning curve and elongates the learning time. As a result, a well-directed training process adaptable for various roles is required. Moreover, the training course should provide plenty of linkages to a broader scope of knowledge such as further explanations to their own jobs and tasks of other participating entities. Commanders, section chiefs, branch heads, and group leaders emr.ccsenet.org Engineering Management Research Vol. 6 No. 2; also desire a centrally organized but fully distributed command and control system (Turoff, Chumer, Walle, & Yao, 2004) with hierarchical summaries illustrating the crisscross linkages among all responders, their primary functions, and contact information, as well.
The objective of this research was to investigate the development of a computer-based program to assist flood response managers in constructing coordination structures regardless of the scale, scope, and complexity of flood.
It was also intended to support qualifying flood responders, such as individuals, communities, nongovernmental organizations, private sector entities, and local governments.
On the basis of NIMS, NRF, and other training guidebooks, the computer program for shaping a flood response coordination system can be conventionally coded in a traditional procedural language, such as an assembly language or a high-level compiler language (C, Pascal, COBOL, FORTRAN, etc.). Alternatively, the system can be programmed as an expert system with inferential logic.
As one successful form of Artificial Intelligence (AI) technology, expert systems are computer-based systems which emulate the decision-making ability of human experts by exploiting knowledge represented primarily as "if-then" rules (Jackson, 1998). Typically, a knowledge base and an inference engine are the major components of an expert system. Edward Feigenbaum, the father of expert systems, asserted that a knowledge base is the power source of an expert system (Feigenbaum, 1977). Knowledge primitives are usually categorized into facts and rules. Facts are simple statements containing data values that represent, and show relationships among entities; Rules are declarative knowledge linking sets of premises and conclusions. Primarily, an inference engine applies logic rules to create new facts in either a forward chaining or backward chaining mode. Forward chaining, also referred to as data-driven chaining, works top-down to assert conclusions or new facts. Backward chaining, also referred to as goal-driven chaining, works bottom-up to determine what facts must be asserted. In general, IT specialists script an inference engine as a general-purpose shell to simplify and expedite the programming process. Then, domain experts in a certain research field and/or knowledge engineers deduce and compile the necessary facts and rules into a knowledge base (Leondes, 2002).
To build a computer-based assistant system for flood response coordination and training, developing an expert system is viewed more effective than procedural code. In the procedural coding process, IT specialists are always vital from start to finish. On the other hand, in the coding process of an expert system, IT specialists are not required once an inference engine is packaged. Domain experts can either work alone or cooperate with knowledge engineers to develop their particular expert systems in the specific fields (Wong & Monaco, 1995). In other words, compared with procedural code, expert systems are more rapidly and easily developed and maintained and have more flexibilities of running with evolving goals. In addition, since rules and facts are stored together in an explicit knowledge base, an expert system has an explanatory capability. This capability enables the users (flood responders) to understand and learn the reasoning simultaneously when they get the conclusions, and therefore, promotes training. All these special characteristics make an expert system more attractive than a procedural code for this flood response application (Leondes, 2002).
Currently, the use of computer science and artificial technologies such as expert systems to support the decision makers is a widespread approach to deal with emergency problems. Some successful applications in this area are discussed below. The general method was to view management as a process and control problem and then to apply system engineering technology into the emergency response management in networked safe service systems (Liu et al., 2011). Liu (2004) developed an agent-based resource discovery framework to search for the relevant resources over the Internet. This expert system addressed two pivotal issues: Resource Description Language (RDL) and its resource matchmaking mechanism. A possibilistic Petri net-based resource description language was proposed to provide a specification to publish and request for resources in environmental emergencies. A matchmaking, allowing a relaxed match for close semantics to find an appropriate resource for environmental emergency management was developed, as well (Liu, 2004). Hernandez and Serrano (2001) developed knowledge-based models within the framework of ARTEMIS (a European Commission research project) for emergency management. This expert system incorporated the knowledge pieces, both from the point of view of the knowledge model calibration and the training of the emergency personnel, required to manage emergencies in different kinds of problem scenarios (Hernandez & Serrano, 2001).
However, there is limited research on developing expert systems to specifically help the incident managers establish sound coordination structures with clear and unified responsibilities of all participants. Potential responders could easily be educated by the system to identify their roles and the key concerns.

Design of the System
In order to fill the research gap, a prototype expert system for flood response coordination and training (referred to as LFRS hereafter) was designed at the local level based on the basic premise that in most cases, floods start and end locally and flood response is managed at the local level (DHS, 2013).
The most widely used computer languages for programming expert system include Visual Basic (Spyridakos, Pierakos, Metaxas, & Logotheti, 2005), Java or JESS (Java Expert System Shell) (Robindro & Sarma, 2013), CLIPS (Ooshaksaraie & Basri, 2011), MATLAB or NETLAB (Mounce, Boxall, & Machell, 2010), Visual Rule Studio (Chau & Phil, 2004), ART*Enterprise (Leon, Martin, Elena, & Luque, 2000), and PyKE (Python Knowledge Engine) (PyKE, 2015). PyKE is 100% based on Python. Python is an interpreted language which allows quick "ad-hoc" development once the code is published and deployed. PyKE offers a way to directly "program in the large". This characteristic is helpful in developing an expert system with a large knowledge base as in this application. In addition, Python is open source. Any software based on Python can freely run on almost all platforms including Windows, Mac, Linux, iOS, and Android (Python, 2015;PyKE, 2015). Based on the overview of functionality, installation, integration characteristics, and compatibility, we decided to construct our system using PyKE.
Typically, there are three phases to design and develop an expert system: design of an initial knowledge base, development of a prototype, and test and improvement (Durkin, 1994). During the knowledge base initialization phase, key concerns, connections, and heuristics about the addressed problems are identified, conceptualized, and formalized. During the development phase, the acquired knowledge was organized and coded, in often cases, module by module, function by function, or subsystem by subsystem. System verification and validation (V&V) are usually conducted simultaneously with coding and after the construction of the prototype to ensure every component of the system represent the actual knowledge and was built correctly.

Knowledge Acquisition
The power of an expert system derives from its knowledge base (Feigenbaum, 1977). The performance of an expert system rests on the knowledge acquisition. To complete the vital task, extensive information for construction local flood response coordination structure was gathered from literature reviews and human-expert interviews. Then, the collected information was extracted and organized in such a way that it can be easily understood. After analysis and evaluation, verified knowledge entities were finally structured into a computer-readable form (Liou, 1990;Storey, Chiang, & Chua, 2012).

System Content and Architecture
The prototype of the expert system for local flood response coordination and training consists of two standalone modules (shown in Figure 1): RRA (Roles, Responsibilities, and Actions) module and ROS (Response Operational Structure) module. The RRA module aims at generating the report of responsibilities and actions to deliver core capabilities corresponding to certain roles. All community entities from individuals to governments play distinct roles in developing the core capabilities of flood response. Focusing on local flood response, the LFRS narrows the spectrum down to local government and community level. The RRA module emphasizes five roles (individuals and families, communities, the private sector, NGOs, and local government) and identifies their activities (planning, assessing and exercising, offering and conducting resources and capabilities, and collecting learned lessons). The ROS module targets at creating the hierarchical layered and mutually supporting operational structures based on the ICS, the most common local response operational structure. The tangible output contains formatted reports as well as prompt screens. One report hierarchically depicts the crisscross connections among all responders, their primary functions, and contact information. Another report summarizes the responsibilities and actions of a certain role of flood responders such as commanders, command officers, section chiefs, branch heads, and group leaders. Every report was named with a unique case ID and formatted in a CSV file. Currently, the RRA module offers five roles for selection: 1) individuals, families, and households, 2) communities, 3) nongovernment organizations, 4) private sectors, and 5) local government. After giving the simple definition of each selected role, the RRA module provides the guidance and instructions. For example, individuals, families, and households play an important role in emergency management operations by decreasing flood hazards in and around their homes and taking care of themselves and neighbors. Their efforts may include raising utilities above flood level, preparing emergency supply kits and plans, and volunteering with emergency organizations. Additional information is given by providing them with verified website linkages. NGOs, especially those officially assigned as support elements, play a significant role in delivering vital services associated with response core capabilities. For instance, the American Red Cross (ARC), National Voluntary Organizations Active in Disaster (VOAD), and Volunteers and Donations (VD) have their specific goals in emergency management. Private sector entities contribute to response efforts through partnerships with governments. A private sector entity could be one or multiple roles of the six categories: 1) Affected Organization/Component of the Nations' Economy, 2) Affected Infrastructure, 3) Regulated and/or Responsible Party, 4) Response Resource, 5) Partner with Federal/State/Local Emergency Organizations, and 6) Components of the Nation's Economy. The responsibilities and actions of local government vary with specific local officials, such as chief elected or appointed officials, emergency managers, and department and agency heads (DHS, 2008;DHS, 2013). Role selection and the inferencing mechanism are discussed in the following section 4.2.2.

ROS Module
ROS module adopts the major structure of the ICS. However, the ROS module offers additional information on the relationships among ICS, Multiagency Coordination System (MACS), and Public Information (PI) for the further reference of response entities. In order to education the users, the ROS module provides introductions to the fourteen proven management characteristics of the ICS: 1) command terminology, 2) modular organization, 3) management by objectives, 4) Incident Action Planning (IAP), 5) manageable span of control, 6) incident facilities and locations, 7) comprehensive resource management, 8) integrated communications, 9) establishment and transfer of command, 10) chain of command and unity of command, 11) unified command, 12) accountability, 13) dispatch/deployment, and 14) information and intelligence management (DHS, 2008;FEMA, 2016). The users can choose any one or ones to learn more. Also, users can skip those lessons to set up the operational structure directly.
Consistent with the ICS, the response operational structure created by the ROS module consists of six sections: command, operations, planning, logistics, finance/administration, and intelligence/investigations function. The sixth section is optional. In each section, there are several units, branches, or groups (shown in Figure 2). The construction of the flood response operational structure is a complex task. To simplify users' practice, the ROS module provides a number of breaking points throughout the process of structure developing. These points give users flexibilities to build or edit one functional unit first, save changes, and then come back after taking a nap.
The ROS module will combine those pieces together to form the structures for various sections and the entire response coordination function.

Inference Engine
The LFRS is equipped with a backward chaining inference engine for more efficient processing. The information needed for the RRA module is different from the data necessary to the ROS module. For example, certain roles determine the responsibilities and actions in the RRA module but have little impact on the construction of the ROS; the contact information of a response chief is vital in ROS but does not affect his/her job tasks. Obviously, the information query and report production are driven by users' goals and their selection of modules. The backward chaining inference engine enables the LFRS to collect the critical data for each module respectively after the module selection. Figure 3 depicts the banner screen displayed upon entry to the system. Inputting "Y" loads the subsequent screens of module selection screen. Once the users select either the RRA module or the ROS module, a unique case ID will be requested (shown in Figure 4). After a brief introduction to the selected module, an interview is conducted by the module starts. For example, Figure 5 to Figure 7 demonstrate the use of the RRA module; Figure 8 to Figure 13 illustrates the process to construct a coordination structure. Note that the user responses appear as part of the interview dialogue. Figure 5 and Figure 6 are the screen shots of the introduction to the RRA module and the interview dialogue. Once the users select a role, the screen of the corresponding responsibilities and actions matched by the RRA module displays (shown in Figure 7). At the same time, for the users' future need, more detailed information is written in a CSV formatted report named with the unique case ID. Figure 7 is the screenshot of RRA report for the role of individual, families, and households.

Verification and Validation
The technical goal of Verification and Validation (V&V) is determining whether the expert system conforms to the requirements and satisfy customers' needs (IEEE, 2012;O'Keefe & O'Leary, 1993). V&V are vital components to ensure the quality of developed expert systems through the processes of analysis, evaluation, review, inspection, assessment, and testing of products.
Typically, developers conduct a set of test cases to assure they are building the expert system correctly. These cases are either collected from real life situations or designed by domain experts to represent the possible problems in implementation (O'Leary, Goul, Moffitt, & Radwan, 1990;Leondes, 2002). With the help of the debugging tools built in Python, we periodically verified the LFRS throughout the development stage by conducting a complete set of pre-defined tests. Specifically, the the RRA module was tested role by role; Similarly, the ROS module was primarily tested section by section. Based on the results of those tests, we modified or reprogrammed the necessary heuristic knowledge and inferential logic.
A common method to assure building the right prototype of expert systems combines face validation (the process by which the experts assess the prototype "at face value") with component testing and system validation through cases or Turing tests (O'Leary et al., 1990). According to this paradigm, experts from the fields of water resource management and emergency management viewed the system's operation, output, and documentation. In addition, the experts tested our system using selected cases from their experience.

Conclusion
To break through the bottleneck of knowledge management in local flood response coordination, we identified the knowledge necessary to incorporate into the LFRS and assimilated these knowledge primitives into the knowledge base. The case studies illustrate that both the RRA module and the ROS module work out the correct reports. The responsibilities and actions match with the various roles accurately. Hierarchies of response operational structure correctly link with each other. The contact information and capabilities of each staff lay out clearly. Introductions and all additional information pop up promptly. By repeated running either the RRA module or the ROS module, the emergency personnel is well trained.
Security and resilience work is never finished. The LFRS can be improved to face more challenges simply by blending more knowledge into the two existing modules or adding more modules into the LFRS. For example, the responsibilities, actions, and capabilities of the governmental roles above local level can be incorporated into the RRA module and the ROS module to prepare for larger scale and more complicated flood events. New modules cover other mission areas like planning and recovery can be built to provide better performance in flood response.