Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

A geographical information system's approach to analyzing critical infrastructure interdependencies :… Cervantes Larios, Alejandro 2008

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
24-ubc_2008_fall_cervantes_larios_alejandro.pdf [ 7.34MB ]
Metadata
JSON: 24-1.0066623.json
JSON-LD: 24-1.0066623-ld.json
RDF/XML (Pretty): 24-1.0066623-rdf.xml
RDF/JSON: 24-1.0066623-rdf.json
Turtle: 24-1.0066623-turtle.txt
N-Triples: 24-1.0066623-rdf-ntriples.txt
Original Record: 24-1.0066623-source.json
Full Text
24-1.0066623-fulltext.txt
Citation
24-1.0066623.ris

Full Text

A Geographical Information System's Approach to Analyzing Critical Infrastructure Interdependencies: A Case Study at the UBC Campus by Alejandro Cervantes Larios BSc., Instituto TecnolOgico y de Estudios Superiores de Monterrey (Mexico), 2000  A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF  MASTER OF SCIENCE in The Faculty of Graduate Studies (Geography)  THE UNIVERSITY OF BRITISH COLUMBIA (Vancouver)  April, 2008 © Alejandro Cervantes Larios, 2008  Abstract In the past few years, the study of critical infrastructures and the interdependencies amongst them in the context of an emergency situation has become a priority for many countries, including Canada. Governments, universities, and private companies all over the world are spending vast amounts of money and effort trying to better understand how infrastructures and humans react in the time stages before, during, and after a disruptive event. Analyzing complex systems such as those formed by infrastructure networks and decision makers is not a simple task and requires a multidisciplinary holistic approach. The field of research in infrastructure interdependencies is fairly new, and lies in the intersection of areas of knowledge such as emergency management, geography, simulation modeling, planning, and safety engineering.  Analyzing interdependencies between infrastructure networks is not only a complex problem in terms of its formalization, but also in terms of the intricacy required to test and validate that formalization. Furthermore, identifying and having access to the data necessary to validate the formal system is probably an even more complicated issue to resolve. It is, however, only through the study of these interdependencies that certain failures or weaknesses in the systems can be discovered; weaknesses that could not be studied through the analysis of a single isolated system. Not only is it a challenging task to analyze the interconnections between infrastructure systems, but studying these at moments of stress, when the interdependencies become dynamic, is even more difficult. In this thesis I explore the intersection between three main themes: Critical infrastructure interdependencies, Emergency Management, and Geographical Information Systems (GIS). Furthermore, I analyze the different types of interdependencies between infrastructure systems, I describe some of the challenges that have to be dealt with when modeling interdependencies, and I explore the possibility of modeling and visualizing some of these interdependencies by constructing an Infrastructure Geographical Information System of the UBC campus.  ii  Table of Contents  Abstract ^  ii  Table of Contents ^  iii  List of Tables ^  vi  List of Figures ^  vii  Acknowledgements ^  viii  Dedication ^  x  Chapter 1: Introduction ^  1  Chapter 2: Emergency Management and Geographical Information Systems ^ 6 2.1 Abstract ^  6  2.2 Introduction ^  6  2.3 Definition of Critical Infrastructure and the Emergency Management Cycle^ 7 2.3.1 Critical Infrastructure ^ 7 23.2 Emergency Management ^ 8 2.3.2.1 Mitigation ^ 2.3.2.2 Preparation ^ 2.3.2.3 Response ^ 2.3.2.4 Recovery ^  2.4 GIS in the different phases of The Emergency Management Cycle ^ 2.4.1 GIS and Mitigation ^ 2.4.2 GIS and Preparedness ^ 2.4.3 GIS and Response ^ 2.4.4 GIS and Recovery ^  10 10 11 12 13 13 18 22 24  2.5 Issues with Spatial Information and Emergency Management ^ 29 2.5.1 Access to Spatial Data ^ 30 2.5.2 Distributed vs. Concentrated GIS ^ 31 2.5.3 High Dependence upon Qualified Human Resources ^ 32 2.2.4 Complexity in the Construction and Conceptualization of a System ^ 32 2.6 Conclusions ^  33  Chapter 3: Infrastructure Interdependencies: A Review of Concepts and Modeling Approaches ^ 35 3.1 Abstract ^  35  3.2 Introduction ^  35  111  3.3 Infrastructure Interdependencies Taxonomy ^  36  3.4 Static vs. Dynamic Interdependencies ^  38  3.5 Methods to Analyze/Simulate the Different Types of Interdependencies ^ 39 3.6 The Granularity Issue —Spatial and Temporal Resolution ^  44  3.7 Data Issues ^ 3.7.1 Data Accessibility Issues ^ 3.7.2 Data Compatibility Issues ^ 3.7.3 Data Quality Issues ^ 3.7.4 Inexistence of Data or Non-Systematized Data ^  46 47 48 48 48  3.8 Modeling Interdependencies Before/During/After an Emergency ^ 49 3.9 GIS to Study Geographical and Physical Interdependencies ^ 3.9.1 Physical Interdependencies ^ 3.9.2 Geospatial Interdependencies ^  49  3.10 Conclusions ^  53  Chapter 4: An Infrastructure Geographical Information System as Part of a Model to Analyze Infrastructure Interdependencies ^  51 51  56  4.1 Abstract ^  56  4.2 Introduction ^  56  4.3 The JIIRP at UBC — Background and Structure ^ 4.3.1 Description of case study ^ 4.3.2 The Disruptive Scenario ^ 4.3.3 Objects of Study and Problem Instances ^ 4.3.4 Bottom-up or Top-down Approaches ^  57  59 60 61 63  64 4.4 The Development of an Infrastructure GIS at UBC ^ 4.4.1 Data Gathering ^ 65 4.4.2 Data Conversion, Standardization, and Simplification ^ 67 4.4.3 Infrastructure Hierarchy/Layers ^ 68 4.4.4 The Different Processes in the Construction of the I-GIS ^ 70 4.4.5 Analysis and Visualization of Individual Infrastructure Networks ^ 72 72 4.4.5.1 The Water Network ^ 74 4.4.5.2 The Gas Network ^ 4.4.5.3 The Steam Network ^ 75 4.4.5.4 The Electrical Network ^ 77 4.4.6 Interaction of GIS with other Systems and Databases ^ 79 80 4.4.6.1 Interaction with the Damage Assessment Module ^ 4.4.6.2 Interaction with PowerWorld ^ 80 4.4.6.3 Interaction with Interdependencies Simulator (GIS and the Cell Model) ^ 81 4.4.7 Objects of study and problem instances attacked with the I-GIS ^ 82 83 4.4.8 Methods used to look for Interdependencies ^ 4.5 Conclusions ^  84  iv  Chapter 5: The UBC Infrastructure GIS: Results, Limitations, and Recommendations for Future Research ^  85  5.1 Abstract ^  85  5.2 Introduction ^  85  5.3 Results ^ 5.3.1 Integration of layers ^ 5.3.2 Day Time vs. Night Time Campus Population ^ 5.3.3 Building to Cell Mapping ^ 5.3.4 EOC Personnel Location and Availability ^ 5.3.5 Road Network Analysis ^ 53.6 Examples of Interdependencies ^ 5.3.6.1 Physical Dependencies ^ 5.3.6.2 Geographical Dependencies ^ 5.3.6.3 Organizational Interdependencies ^  5.3.7 Centers of High Importance on Campus ^  85 86 87 89 90 93 94 95 99 101 104  5.4 Conclusions, Limitations, and Recommendations for Future Research ^ 105 5.4.1 Information Sharing Challenges ^ 105 5.4.2 Perception of Risk — Structural Changes vs. Operational Changes ^ 109 5.4.3 Changing and Emergent Behaviours, Can these be Modeled? ^ 109 5.4.4 Impossibility to Model Everything and the Importance of Defining the Infrastructure Unit (the Granularity Issue) ^ 110 5.4.5 The Ontology Definition in an Interdisciplinary Project ^ 111 5.4.6 The Role of GIS as an Integrator — Common Ground between Disciplines ^ 112 5.4.7 Continuing Efforts towards a Complete Infrastructure GIS ^ 112 5.4.8 Recommendations to other Interdisciplinary Groups ^ 113  References ^  115  Appendices ^  119  Appendix A: Water Network and Water Circuits Geodatabase Table Structure ^ 119 Water Network: ^  119  Water Circuits: ^  120  Appendix B: Gas Network and Gas Circuits Geodatabase Table Structure ^ 121 Gas network: ^  121  Gas Circuits: ^  122  Appendix C: GeoDatabase Model ^  123  V  List of Tables  28 Table 2.1 - GIS Emergency Management Applications ^ 37 Table 3.1 - Interdependencies Taxonomy ^ Table 3.2 - Advantages/Disadvantages of Integrated and Coupled Modeling Approaches ^ 43 45 Table 3.3 - Granularity and Finest Element of Infrastructure ^ Table 3.4 - Factors Affecting Interdependency Analysis ^ 54 Table 4.1 - Water Layer Attribute Table ^ 69 Table 4.2 - Buildings Layer Attribute Table with Updated Water Circuits ^ 70 Table 4.3 - Interdependency Modeling ^ 83 Table 5.1 - UBC I-GIS Geodatabase ^ 86 101 Table 5.2 - UBC Organizational Interdependencies ^  vi  List of Figures  Figure 2.1 - Disaster Management Cycle ^ 9 Figure 2.2 - Geo-Spatial System for Natural Hazard Assessment ^ 17 Figure 2.3 - CATS - Estimation of Toxic Substance Propagation Using Real Time Weather Forecast ^ 20 21 Figure 2.4 - 3D Model of the Santa Barbara Airport Runway and Buildings ^ Figure 2.5 - Flooded Areas near New Orleans ^ 26 Figure 2.6 - Bus where Different GIS Applications were used to Produce Maps ^ 27 Figure 3.1 - Infrastructure Interdependencies ^ 38 40 Figure 3.2 - The Four Objects of Study ^ 42 Figure 3.3 - Integrated (A) vs. Coupled (B) modeling approaches ^ Figure 3.4 - GIS in an Integrated (A) and Coupled (B) Infrastructure Interdependencies Model ^ 52 Figure 4.1 - An Overview of the JIIRP at UBC ^ 58 61 Figure 4.2 - UBC's Risk Priority Matrix ^ Figure 4.3 - JIIRP-UBC Sub-Modules ^ 64 Figure 4.4 - A Layers' Hierarchical Structure ^ 68 Figure 4.5 - Data Flow ^ 71 Figure 4.6 - GIS Functionality within the project ^ 72 73 Figure 4.7 - Water Network ^ 74 Figure 4.8 - Gas Network ^ 76 Figure 4.9 - Steam Network ^ Figure 4.10 - Electricity Network -South Campus ^ 78 Figure 4.11 - PowerWorld Simulator ^ 79 80 Figure 4.12 - Interaction with Structural Assessment Module ^ Figure 4.13. Interaction with PowerWorld Simulator ^ 81 Figure 4.14 - Interaction with the Interdependencies Simulator (I2Sim) ^ 82 Figure 5.1 - Day Time Population ^ 88 Figure 5.2 - Night Time Population ^ 88 90 Figure 5.3 - Cell Classification ^ Figure 5.4 - EOC Personnel on Campus ^ 92 Figure 5.5 - Ambulance Emergency Route: University Blvd. to UBC Stadium to UBC Hospital ^ 94 96 Figure 5.6 - Damage to Water Network - Buildings Affected ^ Figure 5.7 - Damage to Gas Network - Buildings Affected ^ 97 98 Figure 5.8 - Damage to Power Network - Buildings Affected ^ Figure 5.9 - Affected Infrastructure 10 meters from the Henri Angus Building ^ 99 Figure 5.10 - Location of Emergency Responders and Estimated Damage to Buildings - Intensity X 100 Earthquake ^ 104 Figure 5.11 - 3D View (NW) of the UBC Campus - Important Buildings ^ 106 Figure 5.12 - Data Sharing in the JIIRP-UBC Project ^  vii  Acknowledgements First and foremost, I would like to thank Dr. Brian Klinkenberg, for his support and advice during the past three years. Not long after I arrived in Canada, Dr. Klinkenberg opened the doors of his lab at the Geography Department to me. He guided me first as a volunteer, then as a research assistant, a teaching assistant, and finally as his student. I am deeply in debt both to him and to his wife Rose.  I am also grateful to Dr. Jorge Hollman. He had the toughest job of all managing an interdisciplinary team of students working for the JIIRP-UBC project. It is thanks to him that the student's individual efforts were given a direction towards a common overall objective. Dr. Hollman and I worked close together during most of the JIIRP project. Many of his ideas, including that of using the UBC campus as a case study, helped to give shape to the project and to this thesis.  I would like to thank my peers at the Lab for Advanced Spatial Analysis —in particular Dr. Kaoru Tachiiri, Stanley Tian, Alan McConchie, Wayne Kwok, and Carlos Silva— with whom I had many interesting discussions, ranging from politics to metaphysics to GIS.  Many thanks to Jose Aparicio for his continuous assistance: he provided data, helped me with the many ArcGIS tricks and even stayed at work during weekends to help me print posters.  I would also like to thank Dr. Jose Marti and the JIIRP-UBC project for providing funding for my research. Special thanks to Hugon Judrez, Kate Thiebert, Lucy Lu, Jian Xu, Nathan Ozog, and Hafiz Abdul Rahman with whom I worked closely throughout the study.  viii  I must also acknowledge the numerous UBC employees who were involved in the JIIRP-UBC project, in particular David Grigg, Erin Kastner, Doug Smith, Alexander Paderewski, Monica Tzokas, and Tom Ziemlansky.  I would like to thank Angela and Ivan, my good friends who were always there to encourage me and to give good advice.  I would like to thank my mother, Julian, my sister, my late father, and all my family for their love and support through the years. A special mention goes to my grandfather who passed away exactly one year ago.  Finally, I would like to thank Adriana, my wife, for all her love, encouragement, support, and for her beautiful every morning smile.  ix  To Adriana and Sofia  x  Chapter 1: Introduction Infrastructure networks, such as power transmission and distribution, gas and water distribution, transportation and telecommunications, have become increasingly interconnected and interdependent, both physically and logically. The underlying susceptibility of these networks to disruptive events is in large part due to the increasingly complex pattern of intra/interdependencies, and hierarchies that tie these together (Dumas-Osorio et al., 2005).  The study of critical infrastructure interdependencies is not only a complex problem in terms of its formalization, but also in terms of the intricacy required to test and validate that formalization. Furthermore, having access to the data necessary to validate the formal system is probably an even more complicated issue to resolve. It is, however, only through the study of the interdependencies among infrastructure networks that certain failures or weaknesses in the systems can be discovered; weaknesses that could not be studied through the analysis of a single isolated system. Not only is it a complicated task to analyze the interconnections between infrastructure systems, but studying these at moments of stress, when the interdependencies become dynamic, is even more difficult. Unexpected outcomes occur. By studying the relationships between interconnected infrastructures and the way they operate at different stress moments, it is possible to come closer to a picture of what could fail or what should be subject to attention given a specific emergency scenario.  In the past few years, the study of critical infrastructures and the interdependencies among them in the context of an emergency situation has become a priority for many countries, including Canada. Governments, universities, and private companies all over the world are spending huge amounts of money and effort trying to better understand how infrastructures and humans react in the time stages before, during, and after a disruptive event.  1  Interdependencies are not static elements of a system, they are dynamic relationships between objects or between objects and humans (Rinaldi, 2001; Robinson, 1998). They can change depending on the status of the whole system. In other words, they can change depending on the phase of the emergency cycle in which the system is functioning (Rinaldi, 2004). As the behaviour of infrastructures and the roles of the decision-makers change according to the stage in the emergency management cycle, it is not until the moment of a crisis that most of the organizational (human) interdependencies emerge. It would therefore seem contradictory to try to model emergent behaviour if its defining characteristic is that it is unexpected or unpredictable.  A great number of these emergent behaviours are a consequence of the relationships between the different infrastructures and the people in charge of making decisions during an event that perturbs the natural state of things (Rinaldi, 2001; Robinson, 1998). Analyzing complex systems such as those formed by infrastructure networks and decision makers requires a multidisciplinary holistic approach. The field of research in infrastructure interdependencies is fairly new, and lies in the intersection of areas of knowledge such as emergency management, geography, simulation modeling, planning, and safety engineering.  This thesis is in part the result of the work I have done for the Joint Infrastructure Interdependencies Research Programme' at the University of British Columbia (JIIRP at UBC). The JIIRP at UBC is an interdisciplinary project conducted by a team of researchers from six departments and funded by the former Public Safety and Emergency Preparedness Canada (PSEPC), and the Natural Sciences and Engineering Research Council (NSERC). Besides UBC, other five Canadian universities participated in this programme. The JIIRP at UBC aims at studying the complex relationships between infrastructure networks and the way these behave before and during situations http://www.ps-sp.gc.ca/prg/em/jiirp/index-eng.aspx  2  of large scale emergencies. One of its main objectives is to develop "simulation and human interaction tools to better coordinate joint actions by various organizations before and during situations of large scale emergencies 2 ".  In this thesis I explore the intersection between three main themes: Critical infrastructure interdependencies, Emergency Management, and Geographical Information Systems (GIS). The thesis is divided in two components, one theoretical (a review of the concepts mentioned above), and one practical (the incorporation of a GIS to a larger model of infrastructure interdependencies). The practical component focuses on the effect that an earthquake scenario would have on UBC's infrastructure.  One of the recurrent tools employed by researchers when studying critical infrastructures and when trying to simulate and calculate risks and occurrence probabilities of different disaster scenarios are GIS. Geospatial information and its integration in a robust GIS can play a central role in all stages of emergency management. The second chapter of this thesis is devoted to a review of some of the uses that are currently given to GIS in the context of the Emergency Management Cycle. I review a set of academic, private and governmental GIS applications, and I classify these according to: a) the phase in the Emergency Management Cycle in which they are used, b) the developer of the system(s), and c) the type of emergency modeled. Furthermore, I discuss some of the main issues encountered when using GIS for Emergency Management.  Through an examination of the available literature in the field of infrastructure interdependencies, in the third chapter of this thesis I explore the nature of the different types of relationships between infrastructure networks. Moreover, I identify the different methodologies used to classify infrastructure dependencies, and the tools that can be used to analyze these. I analyze the different objects that need to be considered in 2  JIIRP — UBC, http://www.ece.ubc.ca/—jiirp/  3  a multiple infrastructure model, and some of the approaches that can be taken to model these. I also touch upon the main data related issues that can be encountered in the process of constructing a system that attempts to model multiple infrastructures. Finally, I suggest some of the ways in which GIS can be used in the analysis and visualization of geospatial, physical, and organizational interdependencies. To demonstrate the types of infrastructure interdependencies that can be modeled with a Geographic Information System, a simplified Infrastructure GIS (I-GIS) of the UBC campus was constructed. Putting together, updating, and standardizing the data was a long and laborious process. The construction of the I-GIS and its interaction with other systems developed within the JIIRP-UBC group allowed us to illustrate different types of infrastructure dependencies. The fourth chapter of this thesis is devoted to: a) describing an overall picture of the JIIRP-UBC project by reviewing its structure and main objectives, and b) describing the way in which a Geographical Information System was incorporated to the overall infrastructure interdependencies model. There are two approaches that can be taken when studying the interdependencies between infrastructure networks: — A top down or integrated approach in which various infrastructure networks are modeled in the same system. — A bottom-up or coupled approach in which the internal structure of an individual infrastructure system is studied, a failure is then simulated within it, and the results of that simulation are extended to other individual infrastructure systems in order to study the cascading effects (Abdalah, 2006; Pederson et al., 2006). Choosing one approach over the other has consequences in terms of the level of abstraction, the data needed, and the complexity of the model. I touch upon these issues in Chapter 4. A combination of both approaches was followed by systems developed  4  within the JIIRP-UBC. The I-GIS followed the second approach. In Chapter 4 I also go through the processes of interviewing, gathering of data, and constructing the I-GIS for the UBC campus. I explain how the I-GIS became a central component in the functioning of the project as it turned out to be a valuable source of information for most of the other modules. Furthermore, I describe the main components of the I-GIS and its relationship with other modules in the project. One of the main areas of controversy amongst the different participants in the project was the definition of a common ontology. I believe the GIS precisely worked as a common communication platform amongst the members of the team.  In the fifth and final chapter, I describe the results obtained from the analyses undertook with the I-GIS. I review the way in which the integration of multiple information layers in the I-GIS helped the identification and visualization of physical, geospatial, and organizational interdependencies at the UBC campus. I give examples of these interdependencies. I also define the areas of higher risk on campus, areas where multiple infrastructures elements from different networks coexist. I stress the need for a culture of information sharing and I try to emphasize on the importance of continuing the efforts towards constructing and maintaining a complete Infrastructure GIS that centralizes the information on campus. In this final chapter I also explain some of the limitations of the work (the problems encountered when modeling high detail infrastructure networks in a GIS) and I describe some desirable steps to be undertaken in future research: the automation of the interaction of the I-GIS with other modules in the project; the construction of a detailed infrastructure geometric network topology that allows for simplified network analyses (e.g., common cause of failure, physical dependencies). I also document some of the major obstacles found in the way (e.g., data quality issues, data sharing policies, the definition of the minimum or maximum common level of detail between infrastructure models, a definition of an ontology). In the final section of the thesis, I conclude by sharing some of the lessons I have learnt after working in a multi/interdisciplinary project.  5  Chapter 2: Emergency Management and Geographical Information Systems 2.1 Abstract  In this second chapter I examine some of the uses that are currently given to Geographic Information Systems in the context of the Emergency Management Cycle. I review a set of academic, private and governmental GIS applications, and I classify these according to: a) the phase in the Emergency Management Cycle in which they are used, b) the developer of the system(s), and c) the type of emergency modeled. 2.2 Introduction  One of the recurrent tools employed by researchers when studying critical infrastructures and when trying to simulate and calculate risks and occurrence probabilities of different disaster scenarios are Geographical Information Systems. Geospatial information and its integration in a robust Geographical Information System (GIS) can play a central role in all stages of emergency management. In the preparation phase, GIS can be used to manage the large volume of data needed for the hazard and risk assessment, to plan evacuation routes, to design centers for emergency operations, and to integrate satellite data with other relevant data in the design of disaster warning systems (Banger, no date). In the response phase, GIS and other spatial technologies (e.g., aerial photography, satellite imagery, GPS) can be used for the immediate planning of rescue operations and to effectively and rapidly combine and display large amounts of information about the disaster area. In the recovery and mitigation phases GIS can be used to assess the damage, plan reconstruction, and to plan the actions that need to be taken to minimize damage in a future emergency.  6  In this chapter I review some of the uses that are currently given to Geographic Information Systems in the context of the Emergency Management Cycle. I classify the different applications according to the phase in the Emergency Management Cycle in which they are used, according to the developer of the system(s) and according to the type of emergency modeled. This chapter is divided into 3 main sections: in the first section definitions of Emergency Management and Critical Infrastructure are reviewed, in the second section an analysis of the uses given to GIS in the different stages of Emergency Management is performed, and in the third section a discussion of the main issues encountered when using GIS for Emergency Management is presented. The GIS applications reviewed in this document are a sample of governmental, academic and private developments. The characteristics of these systems were drawn from the authors' presentations at conferences or from technical papers. In general, the nature of the developer of the application gives, in and of itself, rise to certain characteristics of the system, as I will explain later in this section. 2.3 Definition of Critical Infrastructure and the Emergency Management Cycle 2.3.1 Critical Infrastructure  Although there are countless definitions of Critical Infrastructure, here I cite two that are complementary and to my viewpoint encapsulate the concept effectively: a) A functional or applied definition of Critical Infrastructure is given by the Government of Canada: Those physical and information technology facilities, networks and assets, which if disrupted or destroyed would have a serious impact on the health, safety, security or economic well-being of Canadians or the effective functioning of governments in Canada (PSEPC).  7  b) A conceptual or theoretical definition is given by Rinaldi et al. (2001, p. 13). They define infrastructures as complex adaptive systems: Complex arrays of interrelated components that are constantly changing and being improved. Unexpected behaviours constantly arise from the interactions among them. Taking into consideration these two definitions we can say that the study of infrastructures necessarily carries the following issues: — Sensitive information is accessed/produced, thus data accessibility and data sharing issues are always present — The study of infrastructures necessarily involves multiple actors at different levels: Academic researchers from different fields of expertise, different branches of governments, and private companies. — Physical networks are complex. — Due to changing and emergent behaviours, it is impossible to model everything  I will review these aspects in more detail below.  2.3.2 Emergency Management Emergency management consists of different phases —typically categorized as before, during, and after the critical event. Different authors do, however, divide emergency management into different stages that can be summarized as follows:  — Mitigation — Preparation — Response — Recovery  8  The United Nation's International Strategy for Disaster Reduction defines Emergency management as: The organization and management of resources and responsibilities for dealing with all aspects of emergencies, in particularly preparedness, response and rehabilitation. Emergency management involves plans, structures and arrangements established to engage the normal endeavours of government, voluntary and private agencies in a comprehensive and coordinated way to respond to the whole spectrum of emergency needs 3 . The different stages in the emergency management cycle (Figure 2.1) are described below in detail.  Figure 2.1 - Disaster Management Cycle  3  http://www.unisdr.org/eng/library/lib-terminology-eng%20home.htm  9  2.3.2.1 Mitigation  The mitigation phase aims at reducing the likelihood of disaster occurrence, and/or minimizing the effects of disasters that cannot be avoided. Mitigation is a long term effort. Some of the measures that are taken in this phase include putting in place building codes to prepare buildings for certain types of earthquake, conducting infrastructure vulnerability and risk analyses, updating of emergency plans, and educating the public.  In this phase the political linkages between the local, provincial and federal governments should be developed. It is crucial to have a common language between the different levels of government involved. A successful mitigation phase will also depend upon the quality and availability of information on infrastructure, potential hazards, and the participants involved in the emergency cycle.  2.3.2.2 Preparation  In the emergency preparation phase, a specific disaster scenario is often targeted. The measures that should be taken in this phase could be described as logistics readiness to face the disaster situation. Preparation is an activity taken in advance of an emergency. The response tools, methods and procedures should be tested, and simulations conducted. In the preparation phase, the analysis of the strategic reserves (e.g., food, emergency equipment, water, medicines) that are needed to face the different scenarios is conducted. Warning systems are also developed and tested in this stage.  During the preparedness phase the different levels of government and other involved actors (Red Cross, civil organizations) develop plans to minimize human losses. Some additional measures that need to be taken are:  10  — Conducting emergency exercises/training - evacuations routes — Putting in place warning systems — Developing emergency communications systems — Preparing reserve inventories — Developing emergency personnel/contact lists — Establishing public information systems — Training  The preparation phase also relies on the coordination of efforts at the different levels of government. It also depends upon how accessible the information on hazards, risks, and the measures to be taken, is to the governmental agencies, non-governmental organizations and the general public. 2.3.2.3 Response The disaster has hit. Response is any action taken immediately before, during, or after an emergency occurs to save lives, minimize damage to property, and enhance the effectiveness of recovery. During an emergency response, the goal is to make available immediate aid to save lives and improve the conditions of the people affected.  Creating temporary shelters, transporting displaced people, supplying food, water, and medicines, and transporting emergency personnel are some of the activities in this phase. Other response measures include 4 :  — Activating the Emergency Operating Center — Emergency Alert System Activation — Emergency Public Information  4  http://www.hampton.va.us/eoc/em_cycle.html and http://www.fema.gov/plan/index.shtm  11  — Incident Command — Public Official Alerting — Shelter / Evacuation — Search and Rescue — Resource Mobilization — Mass Care 2.3.2.4 Recovery  The recovery phase is divided into short-term activities to repair vital life-support systems and long-term activities to return life to normal. There is no clear point at which immediate relief or response changes into short term recovery and then into longterm recovery. Recovery activities continue until everything returns to normality. Some of the measures taken in this phase include s :  — Public Information — Damage Assessment — Debris Clearance — Decontamination — Disaster Assistance Centers — Crisis Counseling — Disaster Insurance Centers — Disaster Insurance Payments — Disaster Loans and Grants — Disaster Unemployment Assistance — Reconstruction — Temporary Housing Reassessment of Emergency Plans 5  http://www.hampton.va.us/eoc/em cycle.html  12  2.4 GIS in the different phases of The Emergency Management Cycle  Geographical Information Systems provide the best method to efficiently support emergency management information needs. Emergency crisis events will impact more than people and facilities; they have an impact on the environment, agricultural crops, livestock, ocean food stocks, and economic dislocation of communities. GIS provides the means fore widely organizational and governmental agencies to participate in the full range of emergency management activities at all levels of government. - Roy C. Price, past president of National Emergency Management Association (U.S.), in Greene (2002, p. x). In this section I review some of the applications given to GIS in each of the Emergency Management phases described above.  2.4.1 GIS and Mitigation  The main applications given to GIS in the mitigation phase include:  — Hazard assessment: fire, landslide, earthquake, flooding (characteristics of the environment that could trigger an emergency situation) — Risk/damage assessment: economic, human, social consequences — Development of Decision Support Systems (DSS): improve strategies to minimize damage  The following are three examples of tools developed for use in the mitigation phase of the Emergency Management cycle:  13  a) HAZUS'- HAZUS is the Federal Emergency Management Agency's (FEMA) main risk assessment software program. It is mainly used to estimate potential losses from floods, hurricane winds and earthquakes. The software is a combination of various modules that allow the production of estimates of hazard related damage at different levels of detail, depending on the user's needs and the quality of the input data. HAZUS can be obtained for free. The software enables you to estimate damage in three different categories:  -  Physical damage: damage to residential and commercial buildings, schools, critical facilities, and infrastructure  -  Economic loss: lost jobs, business interruptions, repair and reconstruction costs  -  Social impacts: impacts to people, including requirements for shelters and medical aid  HAZUS is divided in three main components: The Loss Estimation Earthquake Model, the Hurricane Wind Model, and the Loss Estimation Flood Model. I will briefly describe the functionality of these three modules.  i) The Loss Estimation Earthquake Model incorporates information about building stock, local geology and the location and size of potential earthquakes in conjunction with economic data to estimate losses from a potential earthquake. HAZUS uses ArcGIS to map and display ground shaking, the pattern of building damage, and demographic information. Once the location and size of a hypothetical earthquake is identified, HAZUS will give estimates of the following variables:  — Ground shaking — The number of buildings damaged — The number of casualties 6  http://www.fema.gov/hazus/hz index.shtm  14  — The amount of damage to transportation systems — Disruption to the electrical and water utilities — The number of people displaced from their homes — Estimated cost of repairing projected damage and other effects  ii) The Hurricane Wind Model was developed for communities in Atlantic and Gulf coast regions of the U.S. and Hawaii. The current version of this module can estimate potential damage to residential, commercial, and industrial buildings. It also allows users to estimate direct economic losses. This module is currently being updated to enable to estimate indirect economic losses and impacts to lifelines.  According to FEMA's website, the new model will incorporate in its analysis variables such as wind pressure, windborne debris, surge and waves, atmospheric pressure change, duration/fatigue, and rain. Some of the model's characteristics include:  — A building classification system that depends on the characteristics of the building envelope and building frame — The capability to compute damage based on building classes and the effects of rain and progressive failure — The capability to compute damage to contents and building interior — The capability to estimate tree blow down and structure debris quantities — Loss estimates that include direct and indirect economic loss, shelter requirements, and casualties  iii) The flood loss estimation flood model is organized in two sub-modules: flood hazard analysis and flood loss estimation analysis. The flood hazard analysis module uses variables, such as frequency, discharge, and ground elevation, to estimate flood depth, flood elevation, and flow velocity. The flood loss estimation module calculates physical  15  damage and economic loss from the results of the hazard analysis. The results are displayed in a series of reports and maps.  In addition to the three modules described above, HAZUS contains an interface that allows the user to construct building databases to perform detailed analyses that cannot be done with the infrastructure information contained in the software.  Types of disasters considered: Natural disasters — earthquake, flood, hurricane winds Developer: FEMA under contract with the National Institute of Building Sciences (non profit organization)  Data bases incorporated: Infrastructure databases from the entire US, Technology: Simulators use ArcGIS 9.0; the Spatial Analyst extension is required for the Flood Model. b) Geo-spatial system for natural hazard assessment studies in Switzerland- An  ambitious project is being developed by the Research Network on Natural Hazards at ETH Zurich (HazNETH). HazNETH is an entirely academic and interdisciplinary effort. The network is formed by a group of professors and doctoral students with expertise in Atmospheric physics, Climatology, Hydrology, Hydraulic engineering, Water management, Risk engineering, Construction engineering, Forest engineering, Engineering geology, Geotechnics, Seismology, Geodynamics, Geodesy, Cartography, Environmental social sciences and Economics.  It is an ongoing project that delivered its first results in 2005. One of the deliverables was a geo-spatial hazard and risk information system for an alpine valley in Switzerland. The product contains graphical and numerical geo-spatial data, aerial and satellite images. The software outputs a hazard analysis and displays it on portal.  7  www.hazneth.ethz.ch  16  Figure 2.2 has been removed due to copyright restrictions. The information removed includes a diagram of the main components and structure of Haztool. Source: www.hazneth.ethz.ch  Figure 2.2 - Geo-Spatial System for Natural Hazard Assessment  Types of disasters considered: Landslides, natural dam collapse, debris flows Developer: Research Network on Natural Hazards at ETH Zurich Data bases incorporated: DEM, geology, soil, hydrology, meteorology, topography, vegetation  Technology: Arc GIS, Arc SDE, Arc 'MS  c) Community Vulnerability Assessment Tool — New Hanover County (North Carolina) $ - This project proposes a methodology to help communities to reduce  vulnerability to different hazards. The tool helps the emergency managers to conduct a community-wide vulnerability assessment. The software takes the user through the  8  http://www.csc.noaa.gov/products/nchaz/htm/stepl.htm  17  process of analyzing physical, social, economic, and environmental vulnerabilities at the community level.  New Hanover County was selected by FEMA as part of a group of seven communities for a pilot study: the Project Impact Initiative. The project is a long-range hazard mitigation planning effort that included the development of a community vulnerability assessment.  Types of disasters considered: Natural disasters defined by the user Developer: FEMA, New Hanover County, Coastal Services and Atmospheric Administration  Data bases incorporated: Previous earthquakes, erosion, floods, soils, wind, critical facilities (critical buildings + transportation and utility services), marinas, storage sites, demographic databases  2.4.2 GIS and Preparedness  GIS is mainly used in the preparedness phase to address the following topics:  — Design of evacuation routes — Simulation of emergencies and human reaction — Designing and setting a probable location of centers for emergency operations — Integration of satellite imagery with other relevant data in the design of disaster warning systems  In this section I describe two Geographic Information Systems developed for use in the preparedness phase of the emergency management cycle:  18  a) CATS: Consequences Assessment Tool Set- CATS was originally developed in 1996 and has been maintained and updated since. Its main focus is prediction of damage and analysis of consequences from natural and human caused disasters. The U.S. Defense Threat Reduction Agency (DTRA), and the U.S. Federal Emergency Management Agency (FEMA) hired Science Applications International Corporation (SAIC) to develop the application. The application works with ESRI's GIS.  CATS is composed of hazard, casualty, and damage estimation modules that can be used to approximate and analyze effects due to natural phenomena (e.g., hurricanes and earthquakes) and technological disasters (e.g., terrorist events and industrial mishaps). The software graphically displays geographical areas of damage, risk probabilities, and an estimated number of victims. According to the software's website, it is widely used in military and civil emergency management communities in the U.S. and worldwide 9 . It emphasizes the calculation and analysis of consequences and their impact on postevent resource requirements. Once spatial and temporal variables of hazard effects are determined, CATS converts these into probabilities of casualties and damage.  The GIS component of the system takes these probability distributions and, using appropriate databases, comes up with numbers of people affected (both fatalities and injuries), properties damaged, and amounts of resources required to mitigate the destruction.  Types of disasters considered: Hurricanes, earthquakes, hazardous materials emergencies, terrorism (bombs, biological weapons)  Developer: SAIC (Science Applications International Corporation), a private company hired by FEMA and by the US Defense Threat Reduction Agency (DTRA)  Data bases incorporated: Real-time weather data bases, population data base, infrastructure data bases (approximately 160 data bases)  Technology: Stand alone, requires ArcGIS 9 with Spatial Analyst 9  http://www.saic.com/products/simulation/cats/cats.html  19  The application is available to Federal, State, and local government emergency response organizations in the United States.  Figure 2.3 has been removed due to copyright restrictions. The information removed includes a snapshot of the CATS tool estimating the area of propagation of a toxic substance. Source: http://www. saic.com/products/simulation/cats/cats.html  Figure 2.3 - CATS - Estimation of Toxic Substance Propagation Using Real Time Weather Forecast  b) GeoServNet: A 3D web based model of the Santa Barbara Airport (Abdalla, 2004)The application was developed at the GeoICT Lab, Center for Research in Earth and Space Science, York University. It is a software application developed to visualize in 3D a particular area. A test scenario was created to simulate emergency response and to test emergency preparedness level. The software can be used both in the preparation and response phases.  In the emergency scenario, a high jacked plane with explosion risk is ordered to land in Santa Barbara Airport. The model can then help disaster mangers to explore the level of danger, and which terminals, buildings, and other infrastructures would be affected if an  20  explosion occurs. The software integrates shape files, LIDAR imagery and a digital elevation models to construct the 3D view.  Figure 2.4 has been removed due to copyright restrictions. The information removed includes a 3D model of the Santa Barbara Airport. Source: Abdalla (2004)  Figure 2.4 - 3D Model of the Santa Barbara Airport Runway and Buildings (Abdalla, 2004)  This tool is useful for very specific disaster scenarios. It highly depends on the quality and availability of information and, as with any 3D application, it is computer intensive. The application would be difficult to adapt to a new scenario at the time of an emergency.  Types of disasters considered: Man-made Developer: GeoICT Lab, Center for Research in Earth and Space Science, York University Data bases incorporated: LIDAR imagery, DEM of the area, infrastructure data bases  21  2.4.3 GIS and Response  Decision making during emergencies requires the rapid integration of complete and accurate data that drive user-friendly decision-support tools (NCRST). In the response phase, GIS can be used for the immediate planning of rescue operations and to effectively and rapidly combine and display large amounts of information about the disaster area. The following software tools represent a set of Geographic Information Systems developed for use in the response phase:  a) An Internet GIS prototype for emergency response (Herold et al., 2005)- This application is currently being developed at the Laboratory for Applied Geomatics and GI Science, Geography Department, University of Ottawa. It is a collaboration effort between the laboratory and DM Solutions Group Inc. Its purpose is to be implemented in developing countries where access to other type of GIS technology is expensive. The tool is based in Open Source Map Server Technology and Open Geospatial Consortium Standards. It is intended to function as a central repository of information during the response phase.  "Spatial reporting" is a characteristic feature of this application: the software's spatial data bases can be remotely updated at the time of the disaster by different users. The prototype system has an interesting characteristic — it concentrates the information in a powerful server that can be accessed from a remote location. Using a server diminishes the load put on the user's computer. The mapping engine is server-side. No software is needed on the client's side, an internet browser is enough to display the maps. Although this is an interesting feature, this makes the software highly dependent upon a functioning internet infrastructure in the moments after the disaster.  22  Types of disasters considered: All natural disasters Developer,: Laboratory for Applied Geomatics, Geography Department, University of Ottawa — DM Solutions Group Inc.  Data bases incorporated: Not specified Technology: Client-server  b) GIS-Based Spatial Decision Support System (SDSS) for Emergency Services: London's King's Cross Redevelopment m- This project is being developed by the Center  for Advanced Spatial Analysis at the University College London. It involves the development of a Geographical Information System (GIS) and a spatial decision support system (SDSS) to contribute to emergency services preparedness of a major disaster within London's King's Cross redevelopment. The system targets a relatively small area. It combines a GIS with an evacuation model that incorporates a pedestrian simulation and the route optimization tool in ArcGIS' Network Analyst. The system is composed mainly of the following modules (Castle, 2005): 1.An evacuation model, which incorporates current social systems, and network and infrastructure systems consisting of the required dynamic analysis and decision modeling components. 2. A GIS component, which includes the spatial database and geographical analytical tools. 3. An integration link interface, which consists of mechanisms developed for dynamic communication and data and information exchange between the GIS and evacuation model. 4. A user interface, which displays the current state of the evacuation process and allows the user to request information or run the simulation.  10  Project's website: http://www.casa.ucl.ac.ulekxsdsses/  23  The system is designed to provide help during the first 24 hours after an emergency event. Its main objectives are to give estimates of the best routes to evacuate, the best place to locate a temporary medical facility, the number of patients that will need to be treated onsite and outside the study area, the number of ambulances, and other transportation options for the evacuation.  Types of disasters considered: Mainly man-made disasters Developer: Center for Advanced Spatial Analysis, University College London Data bases incorporated: Not specified Technology: Network Analyst in ArcGIS, Pedestrian Simulator, stand alone application  2.4.4 GIS and Recovery  The recovery phase involves two periods, one in the short-term and the second in the long-term. In the short-term the vital systems are re-established to normality so that the affected population can cover its essential survivability needs. Temporary shelter, food and water, medicines, and fuel are some of the main needs that need to be covered as soon as possible. The main power and water supplies are restored, and the debris clearing process begins. In this short term phase GIS can be used to assess the damage, plan the reconstruction, estimate the amount of debris that need to be cleared, etc.  The long term period can take years; it concludes when the damage is no longer apparent and the reconstruction process is finished. In this second stage, GIS tools can be used as a cost estimator for the different reconstruction options. The activities and applications in this final stage of the emergency management cycle resemble the ones in the initial mitigation stage. The following are two examples of GIS tools used in the recovery phase:  24  a) Disaster Assistance Response Recovery Technology (DARRT)  1 I-  This application,  designed by Dewberry, a private company, is a technology solution for decision makers and planners in the recovery phase of a disaster. DARRT makes use of GIS technology and can also provide analysis and visualization in other phases of the disaster cycle: prevention, management, and response. DARRT can be integrated with a hand-held computer and GPS to input damage information in the field and determine the location of events, and can be upgraded with additional applications such as modeling software packages. DARRT can be run using different ESRI-based software (standalone, serverbased, and web-based), which allows it to suit different needs and interests. DARRT was developed to particularly help in the recovery activities occurring immediately after a disaster strikes, by:  — Predicting debris quantities for hurricane, flood, tornado, and bomb blast — Managing debris load ticket information — Displaying critical facilities — Tracking disaster event incidents  The software has been implemented in Palm Beach County, Florida, and Hoory County, South Carolina.  Types of disasters considered: oriented towards natural disasters Developer: Dewberry Data bases incorporated: buildings, infrastructure Technology: uses ESRI products  II  http://www.dewberry.com/mitigation.asp?id=626  25  b) The case of hurricane Katrina-  Figure 2.5 has been removed due to copyright restrictions. The information removed includes a satellite image of the city of New Orleans before and after Hurricane Katrina. Source: http://www.intermap.com  Figure 2.5 - Flooded Areas near New Orleans 12  Many GIS applications were used during the days, weeks and months after the hurricane Katrina hit the US. A large number of GIS users from all over the US and other countries volunteered to help in the recovery efforts. I will briefly mention some of the GIS applications or development companies that were put together during the short term recovery phase:  -  Tele Atlas: A digital map database of the U.S. road network (www.teleatlas.com)  -  Intermap: Satellite imagery, DEM (http://www.intermap.com/)  -  HAZUS: Wind and flood modeling  -  Mississippi Automated Resource Information System (MARIS), (http://www.maris.state.ms.us)  12  www.intermap.com  26  Figure 2.6 has been removed due to copyright restrictions. The information removed includes a photograph of a mobile emergency GIS lab. Source: http://www.rapidfireindustries.corn  Figure 2.6 - Bus where Different GIS Applications were used to Produce Maps  2.4.5 Summary  Table 2.1 shows a summary of the reviewed applications:  27  Table 2.1 - GIS Emergency Management Applications GIS Application  Developer/User  Main Use  Data Bases Used  HAZUS  Federal Emergency  Mainly used to estimate  Infrastructure networks  Management Agency's  potential losses from  (water, gas, electricity,  (FEMA)  floods, hurricane winds  buildings, critical  and earthquakes  facilieites) from the entire US, Wind, Geoglogy, Census.  Geo-spatial system  Research Network on  Geo-spatial hazard and  Digital Elevation  for natural hazard  Natural Hazards at ETH  risk information system  Model, geology, soil,  assessment studies in  Zurich (HazNETH)  for an alpine valley in  hydrology, meteorology,  Switzerland  topography, vegetation.  Hurricanes, Floods  previous earthquakes,  Switzerland Community  FEMA, New Hanover  Vulnerability  County, Coastal Services  erosion, floods, soils,  Assessment Tool —  and Atmospheric  wind, critical facilities  New Hanover County  Administration  (critical buildings + transportation and utility  (North Carolina)  services), marinas, storage sites, demographic databases CATS: Consequences  SAIC (Science  Hurricanes,  real-time weather data  Assessment Tool Set  Applications International  earthquakes, hazardous  bases, population data  Corporation), a private  materials emergencies,  base, infrastructure data  company hired by FEMA  terrorism (bombs,  bases (approximately  and by the US Defense  biological weapons)  160 data bases)  Terrorism  LIDAR imagery, DEM  Threat Reduction Agency (DTRA) GeoServNet: A 3D  GeoICT Lab, Center for  web based model of  Research in Earth and  of the area,  the Santa Barbara  Space Science, York  infrastructure data bases  Airport  University  28  GIS Application  Developer/User  Main Use  Data Bases Used  An Internet GIS  Laboratory for Applied  All natural disasters  N/A  prototype for  Geomatics and GI  emergency response  Science, Geography  Terrorism  N/A  Natural disasters  Buildings, infrastructure  Department, University of Ottawa GIS-Based Spatial  Center for Advanced  Decision Support  Spatial Analysis,  System (SDSS) for  University College  Emergency Services:  London  London's King's Cross Redevelopment Disaster Assistance  Dewberry (private  Response Recovery  development)  networks  Technology (DARRT)  2.5 Issues with Spatial Information and Emergency Management  As we saw in the previous sections, significant effort is being made to develop applications for emergency management. Many local and regional authorities are developing geographic information systems, spatial decision support systems and other similar tools in order to improve local disaster response and management capacity. Although such systems are useful, it is not uncommon that they lack interoperability, and they require substantial GIS/technical knowledge through each of the design, development and implementation stages. Moreover, their creation and maintenance requires significant human and financial resources, and frequently access to information derived from such systems is very limited during a disaster (Herold et al., 2005). Even though spatial data can be very helpful during the different phases of disaster management, there are always a wide variety of obstacles in the collection, access,  29  dissemination, and usage of the data. These obstacles become even more evident in the disaster response phase when time becomes a primary factor (Mansourian et al., 2006).  In this section I describe some of the most common issues found in the processes of acquisition and manipulation of spatial data and in the development of GIS applications for the different phases of the Emergency Management cycle.  2.5.1 Access to Spatial Data  The study of infrastructures and their behaviour in the case of an emergency necessarily involves multiple actors from different organizations: Academic researchers from different fields of expertise, different branches of governments, and multiple private companies. Within these organizations there are also different levels of actors involved: the users of the information, the administrators, and the political decision makers.  Most often there are conflicting interests between and even within the different organizations. There are thus many obstacles in the process of acquisition of spatial data. Data accessibility is one of the major issues when dealing with emergency management (Greene, 2002; Radke et al., 2000). Before any process of information sharing is undertaken, it is essential that the political actors involved come to an agreement that ensures collaboration. Once a political agreement has been reached, it is also crucial that, on the information operators' side, a clear language and specific information gathering processes are defined.  Emergency Management and Critical Infrastructure Protection are relatively new research fields that are evolving at a rapid pace; the technical jargon used in the field can have multiple uses and interpretations. It is important to define or follow previously developed standards in the information sharing processes (Rajabifard et al., 1999). It is also important to define a common technical lexicon that anybody in the development  30  of the project can refer to. The main issues related to the information flows in a GIS for EM can be summarized into two categories:  — Political/cultural issues: Information sharing policies among private corporations and different levels of government, information property issues, sensitivity of information, unwillingness to share or disclose known weaknesses — Technical Issues: Metadata standards, Information and system compatibility  2.5.2 Distributed vs. Concentrated GIS The most effective disaster management systems are those built on an enterprise, or centralized, basis. An enterprise GIS solution—in which all agencies have access to a centralized base of geographic data layers—leverages the public's already considerable investment in data by reducing redundancy in both data and processing (Greene, 2002, p. xiii). There is a general consensus about the nature of the GIS applications used for emergency management. It is important that information be concentrated in one single place with a strict control of the data base versions. This does not mean that redundancy must be lost, but it is important that an application be capable of running with a minimal dependence upon external sources (e.g., systems designed to run on thin clients); this is especially essential in the response phase. Integration of information in a robust information system for Emergency Management obviously requires inter and intrainstitutional coordination. There are, nonetheless, two opposed conceptions in the development of GIS for Emergency Management: a central governmental approach that will set the standards that any development should follow, and a more open approach, generally used in the academic projects. It is worthwhile mentioning that amongst the tools reviewed, there is a heavy reliance on commercial software such as ESRI's products.  31  2.5.3 High Dependence upon Qualified Human Resources One of the recurrent issues when dealing with complex systems that simulate emergency scenarios is the need for qualified personnel to manipulate them. Some of the solutions presented in the previous section approach this problem by concentrating all the analysis functions in a server and offering a simple user interface accessible via a common web browser. The disadvantage of these solutions is that they rely heavily in the existence of a functioning communication network to access the interne and, furthermore, these systems limit the capacity of a more experienced user, they are static systems in the sense that they can not be enhanced by an interaction with the user. Another way of approaching the problem is to consider these human resources as critical in the construction of the emergency plans. 2.2.4 Complexity in the Construction and Conceptualization of a System The development of information systems for any of the phases of the emergency management cycle imply different levels of complexity: — Complexity of the natural phenomena that will be modeled — Complexity of the human behaviour — Complexity of the physical networks — Complexity of the interrelations between the physical networks — Changing and emergent behaviours (Rinaldi et al., 2001), the impossibility to model everything — Differences in the conceptualization of the problem by the members of the interdisciplinary development teams All the developments reviewed above deal with more than one (if not all) of the issues listed here. Note, however, that the complexity of the problem is reduced once an area  32  of study is defined. An integrated tool designed to envisage a vast number of emergency scenarios at a national level that includes both infrastructure and human behaviour simulators does not exist at this point and is not likely feasible. I must point out however, that Hazus approaches this at a regional level, but does not simulate human behaviour. 2.6 Conclusions In this chapter I reviewed different GIS applications in the context of the Emergency Management Cycle and highlighted some of the issues that are common to all developments. Some solutions are designed to cover a wide variety of infrastructures and emergency scenarios, while others focus on specific cases and specific scenarios. Broadly, there are two approaches to the study of emergency events and their effects in people and infrastructures: ontological and case based.  Most ontological projects are long term (3-5 years) and are generally supported by different levels of governments. The endorsement and participation of the government is very important for these type of projects, especially with respect to the need to supervise and stimulate (if not enforce) the information sharing processes. Shorter projects are typically developed by research institutes or universities with fewer resources. These smaller, case-based projects are generally oriented towards the use of open source tools and interne mapping to tackle local problems. As I discussed in the last section, there appear to be recurring issues that are reported as problematic in all of these projects.  I believe that it is not realistic to try to protect all critical infrastructures and all people from all disasters possible; disaster managers can adopt informed strategies in order to effectively reduce the impact of disasters. These strategies include pre-disaster  33  preparedness, emergency response, disaster recovery and long-term mitigation activities.  The goals of critical infrastructure protection are more realistically set to minimize the consequences of a disaster through timely event notification, information-driven responses, prepared first responders and citizen pre-planned and rehearsed contingency activities (NCRST). Geographical Information Systems are crucial in each and every one of these phases. Real and recent examples of their value are evident: the fires in Kelowna (Entwistle, 2003), the Katrina hurricane, the Tsunami in Sri Lanka. However, efforts are needed to homogenize concepts and define standards for information sharing, and to define policies to increase the participation of all actors: government, researchers, and private companies. A culture towards the deregulation and globalization of the use of information is needed. This thesis falls within the intersection of two main areas of research—emergency management and critical infrastructure protection. In the following chapter I review some of the concepts and modeling approaches associated with the infrastructure interdependencies field.  34  Chapter 3: Infrastructure Interdependencies: A Review of Concepts and Modeling Approaches 3.1 Abstract  Through an examination of the available literature in the field of infrastructure interdependencies I explore the nature of the different types of relationships between infrastructure networks. In particular, I focus on the physical and geographical relationships between infrastructure networks, and identify the different methodologies used to classify infrastructure dependencies, and the tools and approaches that have been used to model these dependencies. I also give some examples of the dependencies that can be analyzed using a Geographical Information System. 3.2 Introduction  Infrastructure networks, such as power transmission and distribution, gas and water distribution, transportation and telecommunications, have become increasingly interconnected and interdependent, both physically and logically. The underlying susceptibility of these networks to disruptive events is in large part due to the increasingly complex pattern of intra/interdependencies, and hierarchies that tie these together (Dumas-Osorio, et al., 2007; Haimes, 2005). The study of these dependencies is not only a complex problem in terms of its nature (i.e., the difficulty of formalization) but also in terms of the intricacy required to test and validate the formalization of those dependencies. Furthermore, having access to the data necessary to validate the formal system is probably an even more complicated issue to resolve. It is, however, only through the study of the interdependencies among infrastructure networks that certain failures or weaknesses in the systems can be  35  discovered; weaknesses that could not be studied through the analysis of a single isolated system. As mentioned in Chapter 1, not only is it a complicated task to analyze the interconnections between infrastructure systems, but studying these at moments of stress, when the interdependencies become dynamic, is even more difficult. Unexpected outcomes occur. By studying the relationships between interconnected infrastructures and the way they operate at different stress moments, it is possible to come closer to a picture of what could fail or what should be subject to attention given a specific disruptive event. In this chapter I analyze the different types of interdependencies between infrastructure systems, describe some of the challenges that have to be dealt with when modeling interdependencies between infrastructure systems, and finally explore the possibility of modeling and visualizing some of these interdependencies with a Geographic Information System. 33 Infrastructure Interdependencies Taxonomy  Infrastructures are socio-technical systems—they have a physical or material component and a human component. Interactions between humans and objects are a necessary element of such systems. Rinaldi (2004) describes the different interdependencies between infrastructure networks according to the elements their state depends upon: — Physical interdependency: the state of one infrastructure depends upon the material output from another — Cyber interdependency: the state of one infrastructure depends upon information transmitted through the information infrastructure — Geographical interdependency: several infrastructures' states are modified by a local event  36  — Logical interdependency: a policy, legal or any other sort of regulatory regime that gives rise to a logical dependency  A description from a different perspective is proposed by Dudenhoffer et al. (2006):  -  Physical: The relationship is defined by supply/consumption/production of an asset  -  Informational: Infrastructures rely upon information transmitted from one to another  -  Geospatial: Infrastructures are located within the same defined space  -  Policy: a binding of infrastructure components due to policy or high level decisions  A summary of the different methods used to classify infrastructure interdependencies according to the criteria used to define the relationship between infrastructure networks is presented below (Table 3.1).  Table 3.1 - Interdependencies Taxonomy Relationship Defining Criteria  Dependency Instances  Nature of the involved entities  Human — Object (Physical network) Object — Object Human — Human  Direction of the relationship  Unidirectional Bidirectional  Nature of the relationship (what is shared  - Information (a flow of information is the link between  between the involved entities)  entities) - Physical (an element produced by one is consumed by the other) - Geographical (both entities share the same location) - Organizational/human/societal (established policies and procedures within organizations)  37  Relationship Defining Criteria  Dependency Instances  State of the relationship  Static (no variation before, during, or after a disruptive event) Dynamic (behaves differently according to circumstances) Cascading failure in associated entities  Type of failure if disrupted  Escalating failure Common origin  Different examples of infrastructure networks dependencies are presented in Figure 3.1.  Fuel  Compressor Statton  Supply  Oil/Gas  Electric Power Communications  Transportation Emergency Services  ,servoir  Banking & Vance (. -leek Processing Center  tation Bank  TM  Pens4aniServi ce Payments  Federal Reserve Legislative Offices  I reasury Uept.  Continuity of Gov't Services  Figure 3.1 - Infrastructure Interdependencies (Wimbish & Sterling, 2003)  3.4 Static vs. Dynamic Interdependencies Interdependencies are not static. They are dynamic relationships between objects or between objects and humans: they can change depending on the status of the whole system. Infrastructure interdependencies can be viewed as complex adaptive systems,  38  with emergent properties that can only be discerned by studying the system interactions in aggregate (Chang et al., 2007; Thomas et al., 2003; Hollman et al., 2007). Three of the four categories of interdependencies proposed by Rinaldi (2004) can be seen as dynamic: the physical, logical, and cyber interdependencies. The dimension of each one of these interdependencies can vary if the whole system is stressed. For example, the physical link between an electrical substation and a water pump can change (if power is redirected through an alternative circuit); the electrical substation could distribute a different amount of power at different moments of stress (before, during, or after an event that affects the system). Or, the information (cyber) interdependency that exists between a telecommunications network and an emergency crew would change if the crew switches from one communication technology to another in the case of an emergency (e.g., cell phones to internet to radio). Both the behaviour of infrastructures and the roles of the decision makers change according to the stage in the emergency. I suggest that most of the emergent interdependencies that are not apparent until the moment of a crisis are human interdependencies. The identification of human interdependencies is perhaps the most difficult aspect in terms of discovery, mapping, and validation. Identifying a multicultural response and the duration of impacts on a society is challenging. The impact of fictitious events can be speculated, but drawing inferences to unforeseen and rare events relative to the other infrastructure sectors is a challenging area of research (Pederson et al., 2006). On the other hand, geographical interdependencies can be seen as static; in the time window of a disruptive event these do not change. 3.5 Methods to Analyze/Simulate the Different Types of Interdependencies  There are four clear objects of study when dealing with infrastructure interdependencies (Figure 3.2):  39  — The infrastructure network and its internal structure and state -  The relationship between one infrastructure and another (the interdependency)  -  An internal event that triggers an abnormal state in one infrastructure network  -  An external event that triggers an abnormal state in one or more infrastructure networks  Water Network  Emergency Services  Emergency sheep Fire trucks  Hospttal  O  Systems' internal structure Interdependencies between systems An external event that perturbs the normal state of things An internal event that perturbs the normal state of things  Figure 3.2 - The Four Objects of Study  Given these four elements, the following are some problem instances that can be analyzed:  1. Given infrastructure A's internal structure, what external events would affect it, and how?  40  2. Given an internal or external event that triggers a failure in infrastructure A, and given a set of rules that define the relationship between infrastructures A and B, how does this affect infrastructure B? 3. Given a dependency of infrastructure B on infrastructure A, what event affecting A, and what state of A, could cause a given disturbed state of infrastructure B? 4. Given a dependency of infrastructure B on infrastructure A, what is the minimum performance of A that would keep B functioning? 5. Given an internal or external event, and given abnormal states of infrastructures A and B, what are the set of rules that define the relationship (the interdependency)? 6. Given an event, and given the interdependency between infrastructures A and B, what decision in infrastructure A maximizes the functionality of infrastructure B. According to these 6 instances of the problem, and the types of interdependencies to be analyzed, a variety of tools and modeling approaches (ranging from simulation models, analysis of risks, decision support systems, etc.) have been developed in the past few years with the purpose of studying the relationships between infrastructure systems 13 . In general, however, there are two approaches that can be taken when studying the interdependencies between infrastructure networks (Figure 3.3):  13  For an extensive survey of infrastructure interdependencies applications, refer to Pederson et al. (2006)  41  Infrastructure netwo Internal configuration  Infrastructure netwo Internal configuratio  Infrastructure netwo Internal configuratio  Figure 3.3 — Integrated (A) vs. Coupled (B) modeling approaches  a) A top down or integrated approach in which various infrastructure networks are modeled in the same system. Although this second approach would seem naturally a better way of tackling the problem, designing a system that contains each infrastructures' network topology and the definition of the relationship rules between the different layers is very complicated. Using this approach necessarily implies a higher level of abstraction in the modeling process.  b) The bottom-up or coupled approach (Abdalah, 2006; Pederson, et al., 2006) in which the internal structure of an individual infrastructure system is studied, a failure is then simulated within it, and then the results of that simulation are extended to other individual infrastructure systems to study cascading effects. An example of this would be a simulation of a substation breaking down resulting in a certain area with no power service for 6 hours. This information is passed onto a water system that estimates the areas where no water will be delivered, and to a telecommunications system that calculates the effect on the telephone/cell phone network. These results are then passed  42  onto an emergency operator (e.g., a fire chief) that evaluates the situation and decides which actions she would to take.  A coupled or bottom-up approach is generally more viable in a short/medium term project. The data sharing can be minimized in this approach. In an integrated model, a complete data sharing between infrastructures is necessary. This is a major obstacle because most of this information is sensitive (i.e., location of critical infrastructure assets, types of technologies, etc.) and many of the owners of the data are usually competitors. In an integrated model, a common framework--a cross organizational and multi-disciplinary ontology, needs to be defined. A coupled model can be very precise, with the internal structure of each one of the systems defined at the finest available granularity. On the other hand, it would be practically impossible to construct an integrated model with the finest granularity available for each of the infrastructure networks. Some of the advantages and disadvantages of each of the approaches are presented in Table 3.2.  Table 3.2 - Advantages/Disadvantages of Integrated and Coupled Modeling Approaches Coupled  Integrated  Utilizes existing models developed for individual  A completely new development needs to be  infrastructure networks  undertaken  Requires less data sharing between organizations  Access to critical data from multiple infrastructures is essential  A common framework is desirable but not essential  A common interdisciplinary/cross-organizational ontology needs to be developed  A very detailed model can be achieved within each  Integrated models are necessarily of higher level  infrastructure system  of abstraction (it is impossible to model everything at the maximum level of detail)  Interdependencies are not parameterized in the  Interdependencies are parameterized within the  system, they can be discovered while using the  system. Their discovery process occurs in the  system. This gives an added flexibility to this  conceptualization of the system, not in its use.  approach.  43  Coupled  Integrated  The consequences of the interdependencies are  Interdependencies between infrastructures are  obtained; interdependencies are not fully formalized.  formalized.  A common data sharing model needs to be  Data model is inherent to the system  developed for information flow between systems  I believe both approaches are complementary: a bottom-up approach is needed to analyze each infrastructure's internal structure in detail and look for weaknesses at that level; it can also be used to analyze the consequences of the interdependencies between infrastructure systems. A top-down approach, however, is needed in order to obtain a holistic view of the problem and a formalization of the interdependencies. In an integrated approach the discovery and formalization of the interdependencies occurs during the conceptualization of the system, not during its use. The opposite occurs in the bottom-up approach: the interdependencies must be discovered based on the consequent cascading failures that are found during the utilization of the system. In their survey of applications that model infrastructure interdependencies, Pederson et al. (2006) describe the different simulation methods used in 28 different projects around the world. The modeling and simulation methods include Markov chains, Petri Nets, dynamic simulation, agent-based, physics-based, ordinary differential equations, and input-output models. These simulation methods approach the problem in one of the two approaches mentioned before. 3.6 The Granularity Issue —Spatial and Temporal Resolution  The scale at which a model of infrastructure interdependencies is conceptualized is critical. It is important because the scale defines the quality of the data needed to construct the system and make it operable. The scale will determine the data needs and the level of data sharing between infrastructure owners. If the purpose of the system is to model interdependencies at a local level (e.g., a substation, a hospital, a water  44  reservoir, and some local decision makers), the information required might be very detailed (the specific connectivity between the substation, the hospital, and the water pumps; the functionality of backup generators, etc.). If the scale of the model is wider, for example at a city level, the level of detail should be aggregated to neighborhoods, substations, etc., in order to make the model usable. Although this concept seems obvious, I believe it is essential to emphasize its importance, especially when planning for the data collection. There should be a consistency between the scale of the disruptive event that is being modeled and the scale of the study area. For example, if an earthquake or a large flood is simulated, the study area should be a city, a municipality, or a large region, and the degree of detail at which data is required is general. If the event modeled is a fire in a building that contains critical infrastructure elements, the level of detail at which data is required is higher. The granularity question is important when defining the finest infrastructure unit/element. This is true for physical assets as well as for the human components. Table 3.3 - Granularity and Finest Element of Infrastructure Scale Infrastructure layer  Water  Local  City  National  Water pumps,  Water sources, source to a  Water sources, source to  valves, local water  point of treatment  a point of treatment  mains  transportation (piping,  transportation (piping,  aqueducts, tunnels), water  aqueducts, tunnels),  purification, transmission to  water purification,  reservoirs, local distribution  transmission to reservoirs, local distribution  Power  Distribution  Transmission network  network Emergency responders  Local emergency  Generation and Transmission  City level  Federal level  responders  45  The temporal resolution is another critical factor that adds complexity to interdependency modeling. Different infrastructures have completely different concepts of time units. In an electrical network actions such as the rerouting of power are done in fractions of a second, in a water network the time window in which events happen are much larger. In a human layer, such as the one formed by the emergency operators, decisions are taken in an even larger time window. This presents an additional challenge when creating a model that includes multiple infrastructures. The granularity question brings up one of the most important issues when modeling interdependencies: data quality and accessibility. This is the subject of the next section.  3.7 Data Issues  As in any other computer system, the modeling of interdependencies depends highly upon the quality of the data available. Any project that encompasses multiple infrastructures has the need to deal with multiple data owners. Different levels of government, and often, different private companies (often competitors) have to agree in releasing information that is critical to their businesses. This is a major challenge that needs to be overcome. Not only is the data sensitive, but many times it is laid out in a highly technical language that hinders the process of interpretation by other nonspecialized users. A system that deals with multiple infrastructures necessarily implies that the developers will have different backgrounds (e.g., electrical engineers, civil engineers, computer engineers, emergency managers). The definition of a common terminology amongs those involved in the project, one that permeates to the structure of the data that is being interchanged, is of great importance (i.e., a common ontology).  Interoperability issues are always present when systems that were developed for different purposes need to share information. There are three important aspects of interoperability (Sotoodeh, 2007):  46  — Technical: Compatibility of message formats — Semantic: Terminology and definitions — Organizational: Practices and procedures  I present here some of the most common issues associated with data access and data quality in the development of cross-infrastructure systems.  3.7.1 Data Accessibility Issues a) Policy issues: These arise when there are different information sharing regulations amongst the owners of the data. It is common that some of the infrastructure owners are private companies that have rights over the information of their property. Other infrastructures are public and have different policies towards information sharing. It is also common that some of the involved actors in a project of this type are competitors and, thus, releasing information on their own assets may be seen as a dangerous move in terms of competitiveness.  Another policy issue is the degree at which information is consider sensitive in the different organizations. An organization might be willing to share the topology of an infrastructure network, but not the location of specific infrastructure components. The opposite case is also possible.  b) Operative and cultural barriers: As with any development that deals with sensitive information, many of the users of the data (the actual operators) are not necessarily willing to cooperate with the project. They worry they could be reprimanded if glitches in the data are discovered; they also worry that they will lose control over the functions they perform in their job; finally, and partly as a consequence of so much propaganda  47  flooding the media, it is not unexpected that people fear that the data could be used for harmful purposes. 3.7.2 Data Compatibility Issues Once the policy, operative and cultural barriers are surmounted, technical obstacles appear. Some of the most common problems include different data formats, varying granularities/aggregation units, mixture of qualitative and quantitative data sets, different technological platforms, and spatial vs. non spatial data. Some of these problems are time consuming but solvable. Others leave no alternative but to reconstruct complete data sets from scratch. 3.7.3 Data Quality Issues  a) Redundancy: The question of whether it is better to concentrate or distribute data carries the problem of data redundancy. Many organizations have different versions of the same infrastructure data sets with distinct modifications and additions made to each of them. Problems inevitably arise when trying to reconcile the differences.  b) Metadata: Data is useless without proper metadata. It is not uncommon to find huge data sets with numbers associated to meaningless (without comprehensive metadata) variables. 3.7.4 Inexistence of Data or Non-Systematized Data Critical information about the infrastructure's day-to-day usage is non-systematized or may still be in the operators' heads. There is a need to formalize and document the data.  48  Data acquisition can be as complex and as challenging as the system's modeling stage. Before any process of information sharing is undertaken, it is essential that the actors involved come to an agreement that ensures collaboration. Emergency Management and Critical Infrastructure Protection are relatively new research fields that are evolving at a rapid pace; the technical jargon used in the field can have multiple meanings and interpretations. Therefore, it is important to define or follow previously developed standards in the information sharing processes (Rajabifard & Williamson, 1999). It is also important to define a common technical lexicon that anybody in the development of the project can refer to. 3.8 Modeling Interdependencies Before/During/After an Emergency As described above, in section 3.5, the objects of study in a multiple infrastructure system are: the event that triggers the emergency, the failure propagation in a single infrastructure system (the behaviour of the system immediately after the event), and the failure dynamics at the inter-infrastructure level (the interdependencies). Most systems that model these objects are utilized in the planning and mitigation stages of the emergency cycle. They can be used to look for potential consequences of a failure as well as for training purposes. Another approach is followed by systems that have the ability to run during an emergency and simulate faster than real time. An additional complication in these types of systems is that real time information input is needed 14 . 3.9 GIS to Study Geographical and Physical Interdependencies As seen in Chapter 2, Geographic Information Systems have proven to be useful in all stages of the emergency cycle. For the purpose of modeling interdependencies between infrastructure networks, GIS are used mainly in the planning and mitigation stages. Examples at the U.S. National infrastructure Simulation and Analysis Centre: (http://www.sandia.govinisac/) (http://www.sandia.govimission/homeland/factsheets/nisac/FAIT_factsheet.pdf) 14  49  Although GIS are not developed to interact with real time simulators (their architecture is not designed to support refreshing several times per second), they can be used to display intermediate states of infrastructure systems based on estimations made by individual infrastructure simulators. They can also be used to combine the results of these estimations with other geospatial data (population, weather, road networks, etc.) and produce attractive visual representations of (potential) failures and their consequences. GIS can play an important role in the analysis of two of the four objects of study in the domain of infrastructure interdependencies (as described in section 3.5): scenario developing (hazard and risk assessment) and interdependency modeling. GIS are not used to model individual infrastructure network behaviour; other much more powerful and customized tools are used by utility companies to analyze the functioning of their infrastructure networks. However, the scenario development done in a GIS can be used to estimate the initial conditions under which an individual infrastructure simulator starts running.  Scenario development is probably the area where GIS can contribute most. In a GIS topographic, climate, and population data from different sources can be easily combined. GIS have been used for many years now to develop these sorts of analyses (e.g., avalanche prediction, forest fire prediction, risk management, immigration patterns).  A more innovative application of GIS is for interdependency analysis and discovery. As shown in section 3.3, infrastructure interdependencies can be categorized into 4 major types: geospatial, physical, informational, policy. GIS can be used in the analysis and/or visualization of the consequences of geographical and physical interdependencies. In a GIS abstractions and representations of real (physical) objects are made. However, interdependencies between infrastructure systems are not real objects, they are abstractions themselves. Thus, with a GIS it is not possible to represent the physical  50  interdependencies per se; what can be represented are the consequences of these interdependencies. 3.9.1 Physical Interdependencies The consequences of basic physical dependencies can be modeled in a GIS. Given that the topology of an infrastructure network is integrated into a spatial database, it is then possible to represent which areas in a region would be affected by a disruption in one or more of the elements of one infrastructure layer. The high detail to which individual infrastructure systems model their networks (e.g., a power grid with transformers, substations, loads, switches) is not something that can be done in a GIS. However, simplifications of the infrastructure networks can be made and modeled in a GIS. An estimation of how a failure would propagate and the visualization of the areas affected is something that can be done with a GIS. Another application of GIS for physical infrastructure interdependencies is the visualization of the results that are produced by other systems. Most of the systems developed by individual infrastructures have much higher detail than what most GIS would support, and produce results at a rate difficult to manage for any GIS (e.g., a power or water network simulator). However, GIS can be used to display intermediate states of infrastructure systems based on estimations made by individual infrastructure simulators. 3.9.2 Geospatial Interdependencies Abdalla (2006) suggests the use of GIS to model what he calls location-based infrastructure interdependencies (LBII). GIS can be used to model infrastructure elements from different systems that share a common location and could potentially fail due to a common cause (an event affecting the area in which these are located). One  51  other way of using GIS to look for geospatial interdependencies is by assigning a weight to each element in a spatial inventory of infrastructures and to look for clusters of elements with high values (a weight based on a parameter such as significance, cost, etc.). This type of analysis can help to locate areas where multiple infrastructures have important assets within a region. The result of this analysis could be then overlaid with a risk analysis to come up with areas of high potential loss. Another example of a geospatial interdependency that could be analyzed with a GIS is the location of the emergency personnel right before an event occurs. For example, by combining the areas affected by an earthquake with the location of the emergency personnel, one could estimate their availability during the actual emergency. As reviewed above, GIS can be used for the analysis and visualization of geographical and physical interdependencies. GIS can also be used in both integrated and coupled modeling approaches described in section 3.5 (Figure 3.4). GIS A)  Geographic Interdependencies Analysis  modeling Infrastructure networks Spatial DB inventory Population  B) GIS  Mr Visualization of interdependency consequences  Figure 3.4 - GIS in an Integrated (A) and Coupled (B) Infrastructure Interdependencies Model  52  In both modeling approaches a GIS works as an integrator of different platforms. In the integrated approach (A) the scenario modeling (earthquake, flood, fire, etc.) is overlaid with different infrastructure networks as well as with a population layer. All models are based on spatial data; a series of analysis (as explained above) can then be undertaken to discover and analyze interdependencies. In the coupled approach (B), a GIS works as a tool to initialize the conditions under which individual infrastructure simulators will start running. A GIS is also the end of the cycle, when the results produced by some of the individual infrastructure systems are transferred to it to be visualized or combined with other spatial data sets (visualization of final losses, areas with no service, affected people, etc.). 3.10 Conclusions The problem of modeling infrastructure interdependencies has many faces: the conceptualization of the model, the approach, the methodology, the quality of the data available, and the tools used to represent the interdependencies. One of the most difficult questions to answer when dealing with the problem of infrastructure interdependencies modeling is: "to what detail should we model?" No matter how resourceful a project is, it is impossible to model all infrastructures at the highest detail. A model that deals with multiple infrastructure systems necessarily carries complications such as time and space granularity at which the individual systems work. A model that encompasses several infrastructure networks needs to find a "least common multiple": a cross-infrastructure common granularity.  Another important problem in the conceptualization of an infrastructure interdependency model is the availability of data. Most of the physical interdependencies can be obtained from experts in each one of the individual  53  infrastructures. Many of these interdependencies and others (operational, policy) have not been yet formalized or systematized, they are only known by the operators of the infrastructure systems. Creating a model that accounts for all this knowledge at a local scale is difficult, but doing so on a large scale represents a significant challenge. In this chapter I have reviewed concepts in the infrastructure interdependency modeling field. I have analyzed the different objects that need to be considered in a multiple infrastructure model, and some of the approaches taken to model these. I have also touched upon the main data issues encountered in the process of constructing a system that models infrastructure interdependencies. Furthermore, I have suggested some of the ways in which GIS can be used in the analysis and visualization of interdependencies. A summary of the different factors that need to be considered when modeling infrastructure interdependencies is presented below (Table 3.4). Table 3.4 - Factors Affecting Interdependency Analysis Types of failure propagation  Cascading, escalating, or common origin failure  Time resolution of interdependent systems  Infrastructure dynamics vary from milliseconds (e.g., electrical grid disturbances) to decades (construction of major new facilities). Different infrastructures will have varying time scales of importance. (Rinaldi, 2004)  Space resolution of interdependent systems  The aggregation of infrastructure elements (the infrastructure unit) is different across infrastructure systems.  Geographical extent of the model  The model's approach and data requirements can significantly vary depending on the extent of the model.  Scenario definition  Infrastructure systems will react differently depending on the location, intensity, and type of disruptive event (fire, flooding, earthquake)  54  Types of failure propagation  Cascading, escalating, or common origin failure  Types of interdependencies  Geospatial, physical, policy, informational  Data issues  Accessibility, quality, compatibility, systematization  Modeling approach  Integrated vs. Coupled  Static vs. dynamic interdependencies  Interdependencies between systems under normal operation vs. interdependencies of systems when operating after an event that changes the normal state (Hollman, et al., 2007)  Objects of study  Internal system structure, disruptive scenarios, interdependencies  Purpose of the model  The interdependencies system is used during an emergency or before the emergency for planning purposes  Emergent behaviours will always arise as a consequence of the relationships between the different infrastructures and the people in charge of taking decisions during an event that perturbs the natural state of things. Although these emergent behaviours will never be determined with exactitude in advance, studying multiple infrastructures and its interdependencies is a good approach to estimate the consequences of an event and to be better prepared. It is a step forward in the creation of a culture of preparedness.  55  Chapter 4: An Infrastructure Geographical Information System as Part of a Model to Analyze Infrastructure Interdependencies 4.1 Abstract This thesis is in part the result of the work done for the Joint Infrastructure Interdependencies Research Program (JIIRP) conducted at the University of British Columbia. The JIIRP at UBC 15 is a three year multidisciplinary project. Eleven professors and eighteen graduate students from different disciplines (Electrical & Computer Engineering, Business, Computer Science, Geography, Psychology, and Civil Engineering) have been involved in this project.  One of the tasks faced by the JIIRP-UBC was the incorporation of a GIS into a model of infrastructure interdependencies. In this chapter I provide an overall picture of the JIIRP project and describe in detail the methodology used to construct an Infrastructure GIS. Furthermore, I document the processes and obstacles found during the process of information acquisition in light of the observations presented in Chapter 3.  4.2 Introduction The JIIRP - UBC team was formed by a group of researchers from six departments. It received funding from the former Public Safety and Emergency Preparedness Canada (PSEPC) and the Natural Sciences and Engineering Research Council (NSERC). Besides UBC, five other research groups in Canadian universities were awarded funding as part of the this programme (York University, University of Saskatchewan, tcole Polytechnique de Montreal, University of Toronto, and the University of Guelph). The overall purpose of the JIIRP at UBC is to study infrastructures, their interdependencies, and to develop "simulation and human interaction tools to better 15  http://www.i2sim.ca  56  coordinate joint actions by various organizations before and during situations of large scale emergencies". The JIIRP at UBC also received support from the British Columbia Transmission Corporation (BCTC), Telus, the Vancouver International Airport, and the Greater Vancouver Regional District.  In this chapter I first describe an overall picture of the project, and then I focus on the task of the project that I am responsible for: the incorporation of a Geographic Information System to an infrastructure interdependencies model. In order for the overall interdependencies model to be tested, the participants in the project undertook the development of an earthquake scenario at the UBC campus. Several factors influenced the decision to develop a test case based on the UBC campus; I describe these in detail in this chapter.  4.3 The JIIRP at UBC — Background and Structure The JIIRP - UBC project is divided in seven main tasks or modules (Figure 4.1):  -  A damage assessment module that quantifies the likelihood and impact of an earthquake in a set of physical infrastructure networks (buildings and lifelines) and the probable damage to those networks.  -  A physical interdependencies simulator that estimates the functionality of any infrastructure element based on a set of partial inputs from other infrastructure networks.  -  A human interdependencies system that models existing policies and human interactions during emergencies.  -  A data visualization module that allows for multiple systems to be visualized.  -  An infrastructure GIS that assembles information on buildings damage, infrastructure network topology, and population.  57  — A data integration module that serves as a common database platform for all the modules. — A study that analyzes the different psychological responses to disasters.  JIIRP - UBC Project Overview  Damage Assessment Civil Engineering 1 Professor 2 Students  A  Physical Interdependencies Simulator Computer & Electrical Engineering 3 Professors 10 Students  Human nterdependendes Simulator Computer & Electrical Engineering + School of Business 2 Professors 2 Students  Data Integration omputer Scienc 1 Professor 1 Student Data Visualization Computer Science 2 Professors 1 Student  GIS Geography 1 Professor 1 Student Panic assessment Psychology 1 Professor 1 Student  Data Flow  Figure 4.1 - An Overview of the JIIRP at UBC The main purpose of the overall project is to study the way in which a set of infrastructure networks are interconnected and behave when disrupted. For this purpose, a theoretical model of infrastructure interdependencies was formalized by the JIIRP electrical engineering team (Marti et al., 2006). They defined four key concepts: -  Tokens: An asset (goods or services) produced by one entity and consumed by  another -  Cells: An entity that consumes the products of other infrastructure networks and  produces a function -  Nodes: A cell or a group of similar cells separated by time or distance  58  — Channels: transportation ways for tokens. Cells are connected through channels and carry tokens  Broadly, the interactions between these four components are what constitute the physical interdependencies simulator (Liu, 2007) depicted in Figure 4.1.  4.3.1 Description of case study In order to test the validity of the above mentioned model, the team decided to pursue the following steps:  1. Develop a scenario in which the infrastructure elements were disrupted. 2. Gather relevant infrastructure data (buildings use and occupation, infrastructure network topology, functionality, consumption). 3. Transform the infrastructure data into the "tokens-cells-channels-nodes" formalization. 4. Visualize the different states of infrastructure networks. 5. Enhance the functionality of the physical interdependencies simulator by modeling geospatial and human interdependencies.  A suitable study area needed to be established. The desired area would be sufficiently complex to test the concepts but with an important constraint: very specific and sensitive infrastructure data had to be made accessible to the team. After discussing the options with the project's partners and with the UBC authorities, and after considering the data accessibility, we decided to choose the UBC campus as our test case.  The geographical location, diversity of stakeholders and infrastructure complexity of the UBC campus provide interesting characteristics with which to perform the study. The university has almost 10000 residents and about 47000 daily transitory occupants-  59  students, faculty, and staff—interacting in a small area. As such, UBC functions as a scale model of a small city. The 402-hectare campus on the outer western edge of Vancouver is geographically isolated from the urban area by the Pacific Spirit Park. None-the-less, UBC's strong dependencies to its neighbors, the daily high traffic of people and goods, the presence of well defined residential, recreational and business areas, and its own utilities' providers, create a valid scaled-system to test the analysis methodology. Moreover, accessing detailed information on infrastructures is less difficult, or so we thought, within UBC than at the city or provincial level. 4.3.2 The Disruptive Scenario  The first step in the development of our methodology was to choose a disruptive scenario that would trigger our different analyses. After reviewing UBC 's risk priority matrix produced with the Hazard, Risk and Vulnerability Analysis Tool Kit proposed by the Provincial Emergency Program 16 — PEP, we decided to choose an earthquake as the most likely scenario that would significantly affect the university's infrastructure networks and the community. The results of the vulnerability analysis are presented in Figure 4.2. For the purpose of the study three earthquake intensities in the Modified Mercalli scale 17 were the selected scenarios (Intensities VIII, IX, and X) (Thibert et al., 2007).  16 17  http://www.pep.bc.ca/hrvahoolkithtml http://earthquake.usgs.gov/learning/topics/mercalli.php  60  UBC - Risk Priority Matrix Low  ^  Very Low  ^  High  ^  Very High -yr  Dangerous Goods Spill  .1 .  e  Critical Facility e ".• Failure. 'Human Epidemil Animal Epidemic)! . Riot/Strike'  Frequent, Very Likely  Moderate or Likely  /  r Explosion/  Severe Weather  emission. Inteerface Wildfire ■  Frequency  e  0 e''' :  ,:zy  ,  Earthquake  Terrorism  ..  ,' Storm surge Land slide Air accident Road Accident''  . ■  ■  .  .  Unlikely, Improbable  ,'  I  .  Occasional, Slight Chance  Urban/rural Fire  Highly Unlikely, Rare Event  .  Very Rare Event  .  Severity  Figure 4.2 - UBC's Risk Priority Matrix  4.3.3 Objects of Study and Problem Instances  In the previous chapter I defined four objects of study in the critical infrastructures field:  1. The infrastructure network and its internal structure and state. 2. The relationship between one infrastructure and another (the interdependency). 3. An internal event that triggers an abnormal state in one infrastructure network. 4. An external event that triggers an abnormal state in one or more infrastructure networks.  61  All four objects of study are tackled in the JIIRP-UBC project:  1. The infrastructure network and its internal structure are modeled at different levels of complexity in both the interdependencies simulator and the GIS. 2. The physical relationship between one infrastructure and another is modeled in the interdependencies simulator. Geospatial dependencies can be inferred from the GIS. 3. The external event that affects the infrastructure (causing failures in some of the infrastructure elements) is modeled by the structural assessment module. The results of the assessment are fed to the GIS for visualization purposes and to the simulator for an estimation of the performance of the cells and channels.  Similarly, in the previous chapter I defined the different problem instances that could be studied in the field of infrastructure interdependencies. In the UBC campus case study we focus our attention on the following instances:  1. Given an internal or external event that triggers a failure in infrastructure A, and given a set of rules that define the relationship between infrastructures A and B, how does this affect infrastructure B? The set of rules that define the relationships between infrastructures are embedded in the interdependencies simulator. The initial consequences of the disruptive event are modeled in the structural assessment module. 2. Given a dependency of infrastructure B on infrastructure A, what is the minimum performance of A that would keep B functioning? In the interdependencies simulator, the functionality of each cell is defined in terms of the inputs from the different external infrastructures. 3. Given an internal or external event, and given abnormal states of infrastructures A and B, what are the set of rules that define the relationship (the interdependency)? Interdependency discovery is the most difficult task in infrastructure modeling. It is always possible to model or estimate "what you know you do not know" but very  62  difficult to model "what you do not know you do not know". With the GIS component of the project, geospatial interdependencies discovery can be done by overlapping the different layers of infrastructure elements and by looking for areas of high risk (clusters of different infrastructure elements with high relative importance). Physical interdependencies discovery is something that can not be done with a deterministic approach like the one used in the simulator. 4. Given an event, and given the interdependency between infrastructures A and B, what decision in infrastructure A maximizes the functionality of infrastructure B? This last point is what the physical interdependencies simulator solves the best. Given an abnormal state in one infrastructure, what action should be taken to maximize the productivity of the second order affected infrastructures.  The infrastructures being modeled in our UBC test case included the electrical, water, steam, gas, and road networks, as well as a building inventory.  4.3.4 Bottom-up or Top-down Approaches  As I described in the previous chapter, a top-down or integrated approach is a method where in several infrastructures are modeled within one single system. This method implies finding a common level of abstraction for all of the infrastructures modeled. A bottom-up or coupled approach is one where several independent computer systems are interconnected for the purpose of establishing the dependencies between the infrastructure systems they represent. Both approaches are used in our project. The physical interdependencies simulator aims at modeling all physical infrastructures in one common platform, utilizing the "cell-channel-token-node" formalization.  The project as a whole, however, utilizes a bottom up approach: a flow of information is interchanged between systems with different purposes. In Figure 4.3 the detail of the information flow between the project's sub-modules is presented.  63  ^  Project Modules - Functionality Life line Assessment Building Inventory  Building Assessment  Earthquake Assessment  Physical Interdependendes Simulator  A ^ 41  Casualty Estimation  Human Interdependencies Simulator  Central^ Database  ° Building Assessment Visualization Occupation Data  Cell definition  Visualization of Multiple systems  1 - GIS  Infrastructure Network Connective  Building  Use  Power World  Electrical Simulatio Data Flow  Figure 4.3 - JIIRP-UBC Sub-Modules 4.4 The Development of an Infrastructure GIS at UBC An important component of the JIIRP-UBC was the creation of an Infrastructure Geographical Information System (I-GIS). As I mentioned in Chapter 2 of this thesis, GIS are one of the recurrent tools employed by researchers when studying critical infrastructures and when trying to simulate and calculate risks and occurrence probabilities of different disaster scenarios. Geographical Information Systems are data integrator systems by nature (aerial photography, satellite imagery, GPS data, Census information, etc.). In this section I describe the process of data acquisition for the construction of an I-GIS for the UBC campus. I also describe how the I-GIS became a central component in the functioning of the project as it turned out to be a valuable source of information for most of the other modules in the project.  64  4.4.1 Data Gathering At the beginning of our conceptualization of the project the team aimed at obtaining information solely for the physical networks on campus, rather than obtaining information related to the organizational structure and the policies and procedures that would be implemented in an emergency. It was during the first interviews that we realized that it would be very relevant to also collect information related to the organizational structure, behaviour, and policies, and to model that on top of the physical layers (buildings, water, gas & electricity networks). As a matter of fact, one data gathering process was related to the other: the more we got to know the physical layout of the infrastructures on campus, the more we knew about the people operating them, and the more we understood the importance—and complexity—of the human component. Our data gathering process was much more complicated than its name suggests. "Data digging" would be more accurate. We began by contacting the campus and community planning office which is responsible for the records office and the recently created GIS department. That original interview was followed by many others with the people responsible for the different infrastructures on campus: — Campus Planning — GIS department — Electrical — Mechanical (gas, water) — Power plant (steam, water pumps) — Records office — Infrastructure technology — Hospital — Fire Hall  65  — Ambulance Services — University Endowment Lands  The team obtained different levels of response to our data requirements, going from full cooperation to closed doors. I believe there are several factors that influenced the different types of reaction we obtained. Some of the interviewees were able to see the benefit of our project to their own work. Those were the ones that automatically opened their doors. Others were not sure of the value of our project; they saw it merely as an academic exercise. The negotiation with this group of people was difficult but accomplishable. Finally, there were those who from the first moment closed their doors. The most common stated reason for their refusal to share information was security and privacy concerns. In those cases, however, I believe that the resistance came more from an attitude of trying to protect a space of power, or trying to conceal a known deficiency in the system (e.g., an outdated infrastructure inventory). We interviewed people broadly at three different responsibility levels: director, middle manager and data analyst. In general it was easier to obtain cooperation from the upper and lower organizational levels than the ones in the middle.  We decided to create an Infrastructure Geographic Information System (I-GIS) in order to concentrate the gathered information. We were able to collect the following infrastructure information at the campus level:  Buildings (GIS-shape file) — 1995 Building Seismic Assessment (Excel file) — Electrical network (Auto Cad drawing) — Water network (Auto Cad drawing) Gas network (Auto Cad drawing) IT (Auto Cad drawing) — Road Network (GIS — shape file)  66  We were also able to obtain reports on previous emergency simulation exercises and procedures from some of the above-mentioned departments. Additionally, individual structural and non-structural assessments were performed in some campus buildings in order to quantify seismic vulnerability. For a detailed description of these tests refer to the JIIRP Civil Engineering team (Thiebert et al., 2007).  4.4.2 Data Conversion, Standardization, and Simplification As identified above, the geographic data obtained from the different sources at UBC came mainly in the form of AutoCAD format (.dwx files). We used ArcGIS's embedded translator to transform these files into ArcMap shape files (.shp). This conversion process is simple, but does not create an attribute table with appropriate content. In other words, the files continue to be "flat" in the sense that all the data associated to the features displayed is drawn in the map (e.g., pipe dimensions, materials). A spatial database can not be automatically created through this process. This left us with a major problem: we had to manually update the geographic database, and manually remove annotations from the new shape files. If one considers that there are thousands of segments of pipes in some of the infrastructure networks, it is easy to imagine the amount of work that this represents.  Given the impossibility of producing a fully populated GIS database of the campus, we decided that it was better to create a simplified GIS model of five infrastructure networks on campus (buildings, water, gas, steam, IT) and give the electrical network (the most intricate of the layers) a different treatment. We would model the electrical network in a specialized program (Power World) and find a way of communicating between that program and the GIS database. In section 4.4.6 I describe the interaction of the GIS with other modules in the project.  67  4.4.3 Infrastructure Hierarchy/Layers  The water, gas, steam, and fiber optics (IT) layers in the GIS were constructed using the AutoCAD drawing as the base. Only the main conduits were considered. A hierarchical notation was given to each of the components in the infrastructure network, an example is presented in Figure 4.4. The child elements in the tree depend upon the parent infrastructure elements. Currently all of these tables have to be constructed by hand; if network topology were available, then these tables could be generated automatically.  Water Laver Hierarchy Model  Waterl  Waterl  Waterl.1  Water1.2  Water1.3.1  Water1.4.1  Waterl.3  Waterl.4  Water2.1  Water2.2  Water1.3.2  Water1.4.2  Water1.4.3  Water1.4.4  Figure 4.4 - A Layers' Hierarchical Structure  In the Figure above "Waterl" is a parent infrastructure element, and any failure in that element would result in a service suspension in the buildings connected to the child infrastructure elements (Waterl.1, Waterl.2, Waterl.3, Water 1.3.1, etc.). This hierarchical structure was then mapped to each of the infrastructure network's attribute  68  tables and also to the buildings layer attribute table. The structure of the attribute table of the water network is presented in Table 4.1 Table 4.1 - Water Layer Attribute Table Name  ID  Parent  Level  0  Waterl  1  1  Water2  1  2  Water1.1  Waterl, Power House  2  3  Water1.2  Waterl, Power House  2  4  Water1.3.1  Waterl.3  3  5  Waterl.3  Waterl, Power House  2  6  Water1.4  Waterl, Power House  2  7  Water1.4.1  Waterl.4  3  8  Water1.4.1.1  Water1.4.1  4  9  Water1.4.2  Waterl.4  3  10  Water2.1  Water2  2  11  Water2.2  Water2  2  12  Water1.4.3  Waterl.4  3  13  Water1.4.4  Waterl.4  3  Each of the network's infrastructure elements, its name, the names of the parent elements, as well as the level in the hierarchy, were identified in the table. The buildings' layer attribute table is also updated with the name of the circuit (or infrastructure element) to which each building is connected (an example is presented in Table 4.2). This allows for a quick visualization of the buildings left without water (or steam, IT services, gas), if an infrastructure element were to fail.  69  Table 4.2 - Buildings Layer Attribute Table with Updated Water Circuits ID  Building Name  Water Circuit  0  Library Processing Centre  Water1.4.3  1  Biomedical Research Ctr  Water1.4.B  2  Health Sc. Parkade  Water1.4.3  3  Koerner Pavilion (ACU)  Water1.4.B  4  Purdy Pavilion (ECU)  Water1.4.B  5  Detwiller Pavilion (Psychology)  Water1.4.B  6  Engineering High Head Lab  Water1.4.3  7  D.H. Copp Building  Water1.4.B  8  Medical Sciences Block C  Water1.4.B  For a full version of the layers' attribute tables please refer to Appendix A.  4.4.4 The Different Processes in the Construction of the I-GIS The construction of the Infrastructure GIS can be represented as a flow of activities with information transferring from one activity to an other.  A diagram with the processes and data flow is presented in Figure 4.5. The data gathering process is divided into three sub-processes: interviews, infrastructure data collection, and emergency data collection. The infrastructure data collection process is what triggers the process of construction of the GIS database. Specifically, it triggers the data conversion process, followed by standardization and simplification. Once the construction process is finished (as explained in the previous section), the analysis or interdependencies search begins.  70  2. Modeling  1. Data Gathering  2.2 GIS Construction 12 Infrastructure Data Collection 1.1 Interviews -Carpus Planning -GIS Department -Electrical Manager -Mechanical Manager. -Records Office npus IT -Carpus -Hosp -Fire Hall -Ambulance Svcs  2.2.1 Data Conversion  1.2.1 Buildings 122 Electrical 1.2.3 Water 1.2.4 Gas 1.2.5 IT 12.6 Road Network  2.2.3 Data Sirrph ication  2.3 Interdependencies Search  1.3 Emergency Data 1.3.1 Emergency plans 1.3.2 Emergency procedures 1.3.3 Emergency simulations - exercises  22.2 Data Standardization  2.3.1 Physical  232 Functional Within a network  2.3.3 Geographical  2.3.4 Organizational  3. Visualization  Figure 4.5 - Data Flow  The I-GIS ended up being an important element that interacted with all of the other modules in the project. For some of the modules it became a valuable source of information, and for others a way in which their results could be visualized. The I-GIS is a valuable tool to model the three stages--before, during, and after--of a disruptive event (Figure 4.6).  71  GIS Functionality within the Project  Infrastructure Networks Analysis a. Power Flow Model b. Gas Network Analysis c. Water Network Analysis d. Steam Network Analysis e. Buildings Model f. Building Functionality Analysis g. Occupancy analysis  Earthquake Modeling  Damage Analysis  a. Structural Assessment b. Non Structural Assessment c. Life Lines Assessment  a. Simulation of failure b. Quantification of functionality  Visualization of damage and estimation of replacement costs  Visualization of areas with no services  GIS Component  Modeling of normal operation  Disaster scenario  Modeling of consequences  Figure 4.6 - GIS Functionality within the project  4.4.5 Analysis and Visualization of Individual Infrastructure Networks After gathering, transforming, and simplifying the data, an analysis of the individual infrastructures was conducted in order to establish the main infrastructure elements, their location, and the dependence upon external sources. In this section I present a visualization of the studied infrastructure networks as well as a description of its most important elements. 4.4.5.1 The Water Network The water network on campus (Figure 4.7) is fed through three main conduits, one coming through 16 th avenue, and two coming through the forest, directly from the reservoir in the Pacific Spirit Park (called "Waterl", "Water2", "Water1.4" in our simplified model). "Waterl" runs under the Acadia housing complex to East Mall,  72  ^  University Mall, and Main Mall and finishes in the Power House building. Water pumps to stabilize the water pressure and to feed the steam network are located within the Power House building. From there, water is pumped to most of the buildings in the north end of the campus. The South campus buildings as well as the new constructions in the west side of the campus are fed through "Water2". Most of the residential areas are fed through circuit "Water1.4".  UBC Campus - Water Circuits ^,--  -^.,.  ^un  ^...de  S  ....," )  •  ,, ...,.  •  tot  \  ^. -::-,^  \  ^0 A^i% Spa A ( • ^k* ‘,k ,A ^S^* ^‘.^ ^••  ^N..  ®„'j 1/4 ^\  ■  ,  ..... ...^  I” 1,  ,,,11  ■•  t.v. ^. } oto  ^11.,1,t ^,  t ^..... ^i.-^#1 1 •  ‘..  ter  Olt  .. • \^,^s -4' ^sir^s‘ •••■e'^A^r a15 ^., ^I^.. .,..^te ^so ,  ^**:''''‘  .,.6,  ,  •-. -  ^I. ^.  yM  Water Circuit 1.1 - 1lIlliIllIllIlIlMlr ---- "IIIIIIIMIIII.IIMIM b  P^p0  3,, I'C' ,‘ '.9 0,'''- i'''' , , l'"?' ,..(1"9 ,^,i '^°'''' / ,i''^ ,/,,,' ,s ,‘ , , ,P ,,,e^e s,'^,e^e e '4V,,, ,,,> et• e, „vi ^,,x ^,,,,,^,,,,,, ,se^e^e^ Water Conduit -^  500 I^  'Meters  16,000 .111131.-USC =n7o=vIsf=r"  Figure 4.7 - Water Network  73  A map of the main water circuits on campus is presented in Figure 4.7. The different clusters of buildings sharing the same circuit are shown in the same colour. The tables with the detailed information of the circuits and the buildings belonging to each are presented in Appendix A.  4.4.5.2 The Gas Network Gas Circuits - UBC —  VA ...,^f  o \  •  ,'.  ol-'1"."^•.  Terasen4  ,  Terasenl  --1  Terasen3  0, V11^ P  ,^1.■,-^N ,  Nr. \^'  .^, ^  ^t -  _  '  ,,,  C3(,...^A ^A  „^  4"...  _Vore4k6 • '11 .  P..  w.  ^4?  4 ,----:. c^  0^•  Terasen2  ''.''  r 4,  \ .^• •..  lb\  ks  ' ,\ ,,,,,„^flik  .0^' J^‘•, •  \,  ''' ‘..:  00 \^\^t  ,  4, ix •4•0\  \^--  Ir.  ?  '::`,  ,.:.., ...:.,.  z co .  ^,  i. ^N,....  -,..iii \i. ..  ,  , . \  _:*-=  \.,..-' o^) P^.  t10  INI,ters  ARP-UBC  ...--\ N  Figure 4.8 - Gas Network  18  The database associated with this map was produced in collaboration with Jorge Hollman.  74  The gas network is fed through four main lines. The first one comes through University Boulevard and goes directly to the UBC hospital and to the Power House. In our simplified model, we call this line "Terasenl". Most of the buildings in the northern part of the campus are fed through this line. One other line ("Terasen2" in our model) runs along 16 th avenue and feeds the Hampton Place residential complex as well as most of the buildings in the southern part of the campus. A third line ("Terasen3") feeds directly the southern part of the Acadia residential area. The fourth and final gas line feeds the residential areas located in the northern part of the campus (St. Andrews). A map of the gas network is presented in Figure 4.8. The buildings sharing the same circuit are also in the same colour. For a complete version of the tables with the detailed information of the circuits and the buildings belonging to each one refer to Appendix B. 4.4.5.3 The Steam Network The steam network at UBC (Figure 4.9) is a closed circuit that starts and ends at the Power House. Although the system is not efficient in terms of energy production/conservation (almost 30% of the steam produced is lost (up to 75% in previous years), most of the old buildings on campus still use it for heating purposes. A building for which steam is crucial is the hospital. The UBC hospital has a long term patient unit which heavily depends upon the heating system. If the steam production were to be suspended for more than 24 hours (during winter), the long term patients would have to be evacuated.  75  Steam Network - UBC  41 — -. Imo.i ►-,...-7,--  --75,  '  •  '^'  411  r  ,-. . .•  1,  \‘ "I' (  Ike  •  "  13,, ),  ,  ^IlL ....  ,---  .„.„- „-  ,^-,,,,::-..-.  \\  ' 91  3 ^, .^  ''.-., i, k^ :,-",-.^.--.^ < -1Vs  AgOk 500 I  JIIRP - UBC  I Meters  -  Steam Network  A Power House  N  Figure 4.9 - Steam Network  During the course of this project the steam production at the power house was shut down on at least two occasions. One during the snow storm in November 2006 and again in January 2008. During the first failure the hospital considered moving the patients out. During the second failure the service was reestablished after only a couple of hours. An evident interdependency exists between the hospital and the steam network/power house building.  76  4.4.5.4 The Electrical Network  As I mentioned in the data collection section, the UBC's electrical network topology was not modeled in the GIS. A different program (PowerWorld) was used to capture the needed detail. PowerWorld Simulator is an interactive power systems simulation package designed to simulate high voltage power systems operation on a time frame ranging from several minutes to several days. The detail in which PowerWorld can model an electrical network is much higher than what can be done in a GIS. However, we designed a method of communicating both systems. The topology of the electrical network is embedded in the PowerWorld simulation. Once the simulation is run, snapshots of the results can be mapped back to the GIS. This allows for a GIS visualization of buildings with no electricity.  In the PowerWorld simulation each building on campus is associated to a certain number of electrical buses. A shared table between the two systems, in which the GIS buildings are related to PowerWorld buses, allows the interchange of information between the two systems. The interaction of the GIS with other modules in the project is explained in further detail in the following section.  77  Electrical Network - UBC  625 Meters JIIRP - UBC  Secondary Electrical Conduits - Main Electrical Conduits Substations  Figure 4.10 - Electricity Network —South Campus  The electrical network on campus is fed through three substations. The main substation is the link between BC Hydro transmission network and the UBC campus power network. The electricity is transmitted from BC Hydro via two high voltage 64KV overhead lines (Rao Singupuram, 2007). The key components of the Substation are transformers, switch gear equipments, circuit breakers, feeders, etc. There are two other substations on campus (4KV and 12 KV). The first one is located next to the Life  78  Sciences building and the second one is located in the southern most part of the campus. A map of the electrical conduits on the south campus as well as the substations is presented in Figure 4.10. A representation of the campus electrical network made in PowerWorld 19 is shown in Figure 4.11.  ^Ir ^  ^  111110 *  r  ^  NWMI !lilt _  NM SEM  oQ  Figure 4.11 - PowerWorld Simulator  4.4.6 Interaction of GIS with other Systems and Databases  The I-GIS shares data with many of the modules in the project as shown in Figure 4.3. At the moment of the writing of this thesis, most of the interactions between the I-GIS and the other systems require manual manipulation of the data. However, it is within the scope of the project to automatize as many of these links as possible.  19  Ozog, N. (to appear in 2008). M.A.Sc. Thesis.  79  4.4.6.1 Interaction with the Damage Assessment Module  The damage assessment module requires certain building attributes from the I-GIS database (e.g., the building area, the number of floors). The damage assessment module reads this data from a GIS table and outputs a damage estimation that is mapped back to the I-GIS for visualization purposes. The interaction is made through dbf files. DBF files are manipulated manually for both the damage assessment module and the I-GIS (Figure 4.12). This approach is not integral and could lead to synchronicity problems if the databases were updated by multiple users.  GIS .---buildings, gas, water, fiber & steam networks  •  1■■■■■■ ■ ■■■ 1■■■■■■ ■■■ ■ 11■■■■■■• •■ MI^• Il•^• dbf file 1111^• I.^• III^■ ■■■■■■■■■■■ II■■■■■■■■■■ II■■■■■■■■■■  11■■■■■■■■■r Manual interaction  -  Structural Assesment buildings, damage indices  Figure 4.12 - Interaction with Structural Assessment Module  4.4.6.2 Interaction with PowerWorld.  The PowerWorld model reads from the I-GIS the damage assessment associated with each building. It then estimates the buses that will be out of service due to a failure in the building and outputs a file containing building numbers with no power. This output  80  is then mapped back to the I-GIS for a visualization of the buildings with no service (Figure 4.13).  GIS  buildings, gas, water, fiber & steam networks  Lookup table Buildings - Buses  PowerWorid Model Semi - automatic interaction  buses, generators, loads  Figure 4.13. Interaction with PowerWorld Simulator 4.4.6.3 Interaction with Interdependencies Simulator (GIS and the Cell Model) The interaction between the I-GIS and the interdependencies simulator is a one way relation (Figure 4.14). The simulator bases its definition of "cells" and "channels" on data extracted from the I-GIS. A cell is defined as a building or set of buildings with the same functionality and that are fed through the same infrastructure sub-networks. The level of granularity at which the cells are defined can be variable. In a small scale simulation, the whole campus could be categorized as one single cell. At a large scale simulation each individual building on campus could be defined as a cell. Many intermediate approaches can also be taken. In any case, information from the I-GIS spatial database is manually retrieved to define the parameters needed for the Interdependencies Simulator to start running.  81  GIS ----"' buildings, gas, water, fiber ......._, & steam networks  ■■■■■■•■•■11 ■■■■•■■111■■■ ■■■■■■■■■■■ • MN • MI dbf file M N  •• MENE • MN ••••••••••11 ■■■■■■■■•■■  ■■■■■•■■■rr  -  1^  Manual interaction  Interdependencies Simulator l cel cells, channels, token  4.14 - Interaction with the Interdependencies Simulator (I2Sim)  4.4.7 Objects of study and problem instances attacked with the I-GIS Although four objects of study have been identified in the critical infrastructures field, as explained in Chapter 3, the GIS component of this project dealt with the following three:  1. The infrastructure network and its topology—modeled (simplified) in the GIS. 2. Geospatial dependencies—inferred from the GIS. 3. The external event that affects the infrastructure (causing failures in some of the infrastructure elements)—modeled by the structural assessment module. The results of the assessment are fed to the GIS for visualization purposes. The fourth object of study defined in the previous chapter is an internal perturbed state of one infrastructure network. This is something that was not modeled with the simplified utilities data set that was produced in the I-GIS.  82  In the previous chapter I also defined the problem instances that could be studied in the field of infrastructure interdependencies. With the I-GIS we are able to study the following instances:  1. Given an internal or external event, and given abnormal states of infrastructures A and B, what are the set of rules that define the relationship (the interdependency)? With the GIS component of the project, geospatial interdependencies discovery can be done by overlapping the different layers of infrastructure elements and by looking for areas of high risk (clusters of different infrastructure elements with high relative importance). Physical dependencies, within one single network, are also modeled within the I-GIS (the hierarchical structure). 2. Given an infrastructure A's internal structure, what external events would affect it, and how? Although the analysis to define and quantify the damage caused to the infrastructure networks and buildings is done by the damage assessment module, its results are passed onto the I-GIS for visualization purposes.  4.4.8 Methods used to look for Interdependencies A summary of the overall methods used in JIIRP to look for interdependencies is presented in Table 4.3.  Table 4.3 - Interdependency Modeling Type of dependency  Evaluation method  Physical/functional  Simulator developed by Electrical Engineering team  Geographical/common origin  I-GIS  Within a network  Hierarchical analysis (GIS)  Logical/organizational  Interviews - diagrams  83  Physical and functional interdependencies are modeled by the interdependencies simulator in the cell-channel-token formalization. Individual snapshots of these simulations can be visualized with the I-GIS: the status of the "cells" can be mapped back to the buildings within the GIS. The geographical interdependencies are evaluated with the I-GIS: by assigning weights to infrastructure elements of different networks, an analysis of areas with high weights across infrastructures outputs the regions of high risk. Dependencies within one single infrastructure network are easily mapped by the IGIS, due to the hierarchical nature of the infrastructure spatial databases. Organizational interdependencies were evaluated by analyzing the emergency plans and procedures. I will give practical examples of the four types of interdependencies in the following chapter. 4.5 Conclusions In this chapter I reviewed the general structure of the JIIRP-UBC project and I described in detail the construction and conceptualization of the I-GIS, its main components, and its relationship with other modules in the project.  The I-GIS became a central component in the functioning of the project as it turned out to be a valuable source of information for most of the other modules. Since the conception of the project, a multi/interdisciplinary approach was undertaken. One of the main areas of controversy amongst the different participants in the project was the definition of a common ontology. I believe the GIS precisely worked as a common communication platform amongst the members of the team.  In the next and final chapter, I describe other analyses that we undertook with the I-GIS that allowed us to discover some interdependencies on campus. Furthermore, I comment on the importance of continuing the effort towards constructing a complete I-GIS of the UBC campus.  84  Chapter 5: The UBC Infrastructure GIS: Results, Limitations, and Recommendations for Future Research 5.1 Abstract In this, the final chapter, I describe in higher detail the types of analyses we undertook with the I-GIS that were used to visualize some interdependencies on campus. I also comment on the importance of continuing the effort towards constructing a complete and up-to-date I-GIS of the UBC campus. I conclude by identifying some of the limitations of the I-GIS and by suggesting some of the ways in which it could be improved.  5.2 Introduction The final chapter is divided in two main sections, in the first one I describe the types of analyses that were done given the combination of layers in the I-GIS. I present examples of interdependencies found on campus and I define three centers of high risk on campus, given their functional importance, their location and the location of the surrounding infrastructure elements, and the risk of damage given an earthquake. In the second section I emphasize the importance of continuing an effort towards the maintenance of an I-GIS for the UBC campus. In this same section I summarize some of the major challenges that had to be overcome in the project, as well as others that could not be solved. As a final point, I share some of the lessons I have learnt after working in a multi/interdisciplinary project.  5.3 Results In this section I describe the results obtained after integrating the different layers that constitute the UBC I-GIS. Many types of exercises can be done with the I-GIS, by no  85  means we have given all the possible uses to the data. I will discuss in the last section of this chapter other uses and other types of analyses that can be undertook with the collected data.  5.3.1 Integration of layers As mentioned in the previous chapter, the I-GIS became an important component in the functioning of the project as it turned out to be a valuable source of information for most of the other modules. It also turned out to be a natural integrator for the multidisciplinary efforts; the different members of the project contributed their data for the construction of the UBC I-GIS. At the stage of the project in which this thesis was written, the I-GIS integrates the following layers of information in a Geodatabase (ArcGIS format):  Table 5.1 - UBC I-GIS Geodatabase File  Description  Type  Campus Buildings  2006 building inventory  Polygon feature class  Buildings Structural Assessment for  Structural damage index for  Table  three different intensities of  Mercalli intensity VIII, IX, X  earthquake 2° Buildings non structural assessment'  Non structural damage index for  Table  Mercalli intensity VIII, IX, X Life lines assessment'  Estimation of number of breaks  Table  per lifeline (water, gas, roads) Table  Building use Electrical Connectivity:  Building to bus mapping  Table  (Building GIS ID vs. PowerWorld bus ID) Water network  Connectivity at main pipe level  Line feature class  Gas network  Connectivity at main pipe level  Line feature class  20  Data provided by Hug& Juarez and Kate Thiebert as part of the UBC-JIIRP project.  86  File  Description  Type  Steam connectivity  Connectivity at main pipe level  Line feature class  Roads  Campus road network for  ArcGIS network dataset  network analysis Fiber Optics  Connectivity at main circuit level  Line feature class  Cells and channels  Cell to building mapping  Table  EOC personnel location on campus  Location of EOC personnel  Table  according to UBC 2006 emergency exercise  For a full description of the Geodatabase structure please refer to Appendix C. 5.3.2 Day Time vs. Night Time Campus Population  The time of the day is the most important variable that affects any analysis that looks at affected people on campus (Thiebert, 2008). Figures 5.1 and 5.2 show a comparison of the population on campus during office hours in a weekday vs. the census population (night time population). There are approximately 40,000 people on campus during office hours on a week day. During the school year Approximately 10,000 live within the limits of the UBC although only approximately 6000 live on buildings managed by UBC (displayed on Figure 5.2). If an earthquake was to occur, and some buildings were affected, these maps are a useful tool to estimate the amount of people that could be affected. The way the authorities would have to deal with evacuation procedures would highly depend upon the number of people that would be displaced.  87  Estimated Day Time Population - UBC campus  Estimated day time population 0-10  um  JIIRP-UBC  500  - 100  Meters  101 - 500  1:10.000  501 - 1000  Map cleated by Alejandro Cervantes Data provided by UBC planning. Kate Thiebert. and Hugon Juarez as part of the JIIRP UBC project  - 2500  Figure 5.1 - Day Time Population  Estimated Night Time Population - UBC campus  Estimated night time population 1 - 20 51- 100 -101 -150  A11.151300  JIIRP-UBC  500  - 50  Meters 1:10.000  Map created by Alejandro Cervantes Data provided by UBC planning, Kate Thiebert. and Hugon Juarez as part of the JIIRP UBC project  Figure 5.2 - Night Time Population  88  5.3.3 Building to Cell Mapping  As I pointed out in the previous chapter, the interaction between the I-GIS and the interdependencies simulator developed by the electrical engineering team in the JIIRP UBC project is a one way relation. The simulator bases its classification of "cells" and "channels" on data extracted from the I-GIS (buildings and conduits). In the simulator, a cell is defined as a building or set of buildings with the same functionality and that are fed through the same infrastructure (sub)networks.  The level of granularity at which the cells are defined can be variable. In a small scale simulation, the whole campus could be categorized as one single cell. In a large scale simulation each individual building on campus could contain multiple cells. For the purpose of an earthquake exercise that comprises the whole UBC campus, the number of cells is in the same order as the number of buildings. On Figure 5.3 I display 6 out of the 19 types cells defined by Liu (2007). It is interesting to note that the main campus can be clearly divided in 3 main areas according to the building use. The residential areas are well defined, and although the administration and classroom/research buildings are mixed, it is easy to spot clusters of administration buildings.  89  Building Use - Cell classification  as  Hospital  MI Public buildings  500 Meters  Research/Teaching  1:6.000  Residences  MI RCMP  .111R,000  EMI Power House/Elec. substations crearotl 6,1..10 Cervantes Dale provullad by MC Oan" , ^9 Aleprttlro Cervantes as of 11-58 .111131,^pro,act  Figure 5.3 - Cell Classification 5.3.4 EOC Personnel Location and Availability  One other interesting thing to look at is the location of the people who would be involved in the managing of a critical situation. The UBC has conducted an annual emergency exercise for the past 15 years. Based on an exercise conducted in 2005 and  90  coordinated by the UBC Department of Health, Safety & Environment 21 , the location of the personnel involved in the exercise can be mapped (figure 5.4). One could assume that at least the same number of people involved in an exercise would be involved in the managing of a real emergency. In the 2005 exercise, 61 people were involved. In previous exercises, a similar number of people were involved (48 in 2004, 57 in 2006). The participants in emergency exercises are divided in four groups according to their function during the emergency: policy, EOC staff, emergency coordination, and emergency personnel. In developing Figure 5.4, a score was given to each of the participants in the exercise according to their function and to their coordination/decision making level. Each member of the emergency exercise receives a score. Individual scores range from 1 to 5, where 1 is someone that can be replaced easily (e.g., emergency operator) and 5 is someone who can not be easily replaced (emergency decision maker). The total score for the building is the sum of all individual scores in that building 22 . Even though the 61 participants on the exercise are all scattered on campus, there are 6 buildings that have by far the highest scores: The general services administration building The public safety building -  The UBC hospital  -  The old administration building The university services building  — The Power House  http://www.hse.ubc.ca/mgmt systems/emergpin/files/exercises/EmergencyExerciseReport2005.pdf Hollman J. (Presenter) and Alejandro Cervantes-Larios,. Presentation at the 2007 JIIRP Symposium, Ottawa.  21  22  91  EOC Personnel on Campus ,-.  Y  4  ,^\e', i ' ., Ai',,,,,  4  ''''  ^1, ^  ..4 ..  .  1-.°  AliSN^ •  .-  il  '1•A  •I^fo•A .,.  • .`a?  "A....  ,^'A..^•  ...,  "  ...!. "S "In  1......•'  •  -  ^0.4."^'^0..;  ^'  ^_...-.. •  .11.4  ^•  ,^. '•  If  ^"V^4^st --s.‘^■-,  .4^'^:','^.!3 ^AV 1 ,.y^4 1  ^.  ^'  ^1 4^A,..-e77^A ^z  AA^''^4-  t  '''  ,...L  .  ,  • ,  ^\  4^014,^«  ^4 x  \^'  ..-  \•:/‘• ,.\....  ••‘ •  '  •?.• I-;^,^•^  .."^\ .• ,..  ^  Score  490  AI=^I^ 5^,,  ^N'  , 4.4,410°  •  ^<1^13^ s '^,, .  IMeters  1'8,000  N JIIRP-UBC  Each member of the emergency excercice receives a score based on the role played during the simulated emergency. Individual scores range from 1 to 5, where 1 is someone that can be replaced easily (e.g emergency operator) and 5 is someone who can not be replaced (emergency decision maker) The total score for the building is the son) of all individual scores.  Map created by Alejandro Cervantes -Emergency Personnel data based on a 2005 emergency excercise run by UBC  Figure 5.4 - EOC Personnel on Campus These 6 buildings are then the most important ones when it comes to decision making in the case of an emergency. One other important analysis that would have to be made is the availability of these decision makers if the emergency occurs in a time of the day where reduced activity is happening on campus (i.e., night time, summer). In a conversation held by myself and other members of the team, and personnel from the  92  UBC hospital 23 , the issue of how far people who work at the hospital live from campus arose. A large percentage of the hospital employees actually live in Richmond. The structural integrity of the 6 illustrated buildings as well as the accessibility to the resources in the case of an emergency are issues that needs to be taken into consideration when developing the emergency plans and procedures.  5.3.5 Road Network Analysis One interesting use that can be given to the road network data set in the I-GIS is for route planning in an emergency. On Figure 5.5, I present an example of the way the network data set can be combined with the building and lifelines assessment, in particular the road assessment. The assessment outputs the likelihood of damage to roads and buildings on those roads. Assuming that the road segments that are close to a highly damaged building will be closed, using the ArcGIS network analyst we can input those closures as barriers in the roads and then plan evacuation routes. On Figure 5.5 ambulances entering the University through University Boulevard, need to pickup people at the stadium and drop them at the UBC Hospital. Given the road closures, the network analyst calculates the shortest available path to complete the route.  This same network dataset has other applications such as the delivery of food, water, medicines to several points (e.g., shelters) in a city after an earthquake, given a certain number of barriers. In the case of the UBC street network, the network dataset is small and often the solutions seem evident. But at a larger scale, the solutions to the shortest route become more intricate.  23  Conversation with John Manougian (UBC Hospital, Facilities Manager) held on Feb. 2007  93  Ambulance Emergency Route Analysis  0  Stops  0 Damaged Roads ;closed)  300 Meters 1:5,500  JIIRP-UBC Map created by Alejandro Cervantes Data provided by Geography Department UBCIDMTI  - Shortest Route  Figure 5.5 - Ambulance Emergency Route: University Blvd. to UBC Stadium to UBC Hospital  5.3.6 Examples of Interdependencies In this section I describe some of the ways in which the UBC I-GIS can be used to analyze dependencies between infrastructure elements as well as interdependencies across infrastructures. Abdalla (2006) suggests the use of GIS to model location-based infrastructure interdependencies (LBII). Geographic information systems can be used to model elements across infrastructure networks that share a common location and/or could potentially fail due to a common cause (an event affecting the area in which these are located). Furthermore, GIS can also be used to analyze dependencies within individual infrastructure networks: propagation of a failure within the system. This can only be done if the infrastructure network topology is embedded within the GIS. of  94  course. The following are some examples of dependencies and interdependencies that can be visualized with the UBC I-GIS: 5.3.6.1 Physical Dependencies The consequences of the physical dependencies within three infrastructure networks are presented in Figures 5.6, 5.7, and 5.8. On these Figures I show the buildings on campus that would be left without water, gas, or power service, if certain components in each of the infrastructure networks were damaged or disconnected. As I mentioned in the previous chapter, the UBC campus water network is fed through three main lines, one coming through 16 th avenue, and two coming through the forest parallel to 16th avenue, directly from the reservoir in the Pacific Spirit Park. On Figure 5.6 I show the buildings that would be left with no water if two sub circuits of the main line coming from 16 th avenue are damaged or shut down (these sub circuits are called Water1.1 and Water1.3 in the I-GIS database).  95  UBC Campus - Water Conduits Failure  The buildings with no water service if circuits Water 1.1 and Water 1.3 are damaged are displayed in the map 500 - Water Network -  Water!  I  1 Waled 3 I ^  A  Water!  3  wwer,  3B  Meters 1.6,000 JIIRP - L1133  P  eta meled by uac Fmne JO■ge NoPmen Alomdro Careantet as ! part ot the JIIIRP UBC  Figure 5.6 - Damage to Water Network — Buildings Affected  Similarly, on Figure 5.7, I show the buildings on campus that would lose gas service if one main circuit and one sub circuit (called terasen4 and terasen2.2.15 in the I-GIS table) were damaged.  96  UBC Campus - Gas Conduits Failure  The buildings with no gas service if circuits Tenses 4 & Terasen 2.2.15 are shut down are displayed in the map - Gas Conduits Terasen 22.15  500 Meters 1:6,000  Terasen 4.1.1 Terasen 4.2.1  JIIRP - UBC  Terasen 4.2 2  I^I Terasen 4/.3  1mge Haman AIM,. Ow, P.... A.. 0.0 p■o/act  Figure 5.7 - Damage to Gas Network — Buildings Affected  Finally, on Figure 5.8 the same type of visualization is presented for the power network.  97  UBC Campus - Power Outage  The buildings with no power if circuits 1 to 9 are damaged are displayed in the map 500  Meters Pot e^ante  1:6.000  Buildings with no power  tee M yC CC0 0.00 z. degMUac Nathan 0,8 Plejnn.Cante, 0.1,111eJIIRP^p■oject  Figure 5.8 - Damage to Power Network — Buildings Affected  These circuits were arbitrarily selected, but at the time of the writing of this thesis an estimation of the likelihood of damage due to an earthquake to lifelines is still being done by some of the members of the JIIRP-UBC civil engineering team. Once the results of that assessment are incorporated into the I-GIS, a more realistic picture of the buildings that could be left without services can easily be produced.  98  5.3.6.2 Geographical Dependencies  In this section I present two types of geographical dependencies that can be analyzed with the UBC I-GIS. In the first one (Figure 5.9), it is assumed that a building on campus has collapsed and all infrastructure elements within a radius of 10 meters are damaged. This assumption can then trigger an analysis like the one presented on Figures 5.5 to 5.7, in which the cascading failures across infrastructures are visualized.  ,s.  A  \  ,,- 0 -  ^-  ...  %  s  ----  -  .  L  \  -----. GAS CONDUITS  ^ WATER MAINS ELECTRICAL NETWORK Angus Building - damage  ,../....\  Angus Building - affected infrastructure within 10 m N  Figure 5.9 - Affected Infrastructure 10 meters from the Henri Angus Building  One other way of visualizing a geographical interdependency is shown on Figure 5.10. Two datasets are combined in this Figure, the first one is the location of the emergency operators on campus (as seen on section 5.3.4 of this chapter), and the second one a structural assessment of the UBC campus buildings(Thiebert, 2008). By combining  99  ^  these two datasets it is possible to estimate which emergency operators will be available or not, in the case of an earthquake. The emergency operators that work in the buildings with a very high estimated damage are less likely to be available to perform their duties as emergency coordinators/operators.  Structural Assesessment & Location of EOC Personnel  34p. ovvo ,„  ^•  ,  go  lit  e.i  '^  ^■^1,...,  (---,---^  0  \\  ^1  ^,...-,..---.. .....,^-_  ,.. .:  ifirD \^c:)  .---.  ,  ''''-'e^3^Ik.'^000v. 1111■.---f*.^\  1  ^-;\  c'‘)^'''^16'.C%% \  ^,  ^0).  ...a ‘^\ skie. ^\\  \\0)\\*  -,,,  A10.-• ..^".,Sk^.^\  ,.  Y''''  mentage of damage offilakers^based D ecision on replacement cost) Policy^  I Emergency Operations _  ;  ^t^•  A^, A,^c,:-.<• -:. "ei,3  ...--\  I^I ..  N  1^10.1-150 ..,,  ,5, ..  JIIRP-UBC  IME JO 1-500  Emergency Coordination^501+ EOC staff  4 Number of people^  500  I^  1:&,000  (Meters  Map created by Alejandro Cervante s -Assessment data provided by Kate Thiebert & Hugon Juarez as pact of the JIIRP UBC project -Emergency Personnel data based on a 2005 emergency excercise run by l_IBC  Figure 5.10 - Location of Emergency Responders and Estimated Damage to Buildings — Intensity X Earthquake  100  5.3.6.3 Organizational Interdependencies  Organizational dependencies are probably the most difficult to study. These interdependencies arise from conflicting policies, procedures, or ways of operating between the different players in an organization. One area in an organization works under the assumption that other areas will respond according to their needs in the case of an emergency. This is not necessarily always true.  In the case of our UBC Campus study, it was not until we started understanding the way in which UBC was organized, and after several interviews with people involved in the planning office, emergency services, and utilities offices, that we started to identify some potentially conflicting links between the actors during an emergency. Although these weak links between organizations members are difficult to identify, they are most of the time more easily fixed than a physical dependency (e.g., it is easier to establish a communication link between two offices in an organization than to retrofit a building). We could identify four types of organizational dependencies on campus: in Table 5.2 I show the type of dependency as well as an example of it.  Table 5.2 - UBC Organizational Interdependencies Information flow (deficiency of)  Potentially conflicting policy or procedure  Conflicting day to day practice  Campus planning + fire  Different actors on  Ambulance vs. Fire hall  Physical and organizational dependency Power House-Hospital  hall  campus respond to  conflicting cultural  (steam during winter)  Systematized lifeline  different authorities:  practices  Morgue — dependency  data not available  Coastal Health  (paper maps instead)  Authority, PEP, PSC  RCMP — Campus  Hospital evacuation  Hospital's internet  security data sharing  plan (Winter)  reliance for medicine  on power (cooling)  inventory  101  The first type of organizational interdependency is related to a lack of reliable communication links between two or more parties involved in an emergency situation. An example of this would be the case of the fire hall at UBC that does not have the most recent version of a map of the university. The university is constantly changing due to the new developments and these changes are not always updated to all the organizations that need them. An updated map would certainly be of good use to a fire truck driver. The communication link between the producers of the maps and the users is broken.  One other example of the same type of organizational interdependency is the reliance on paper maps for the purpose of all maintenance of water, gas, and electricity conduits on campus. This same type conflicting communication link exists between RCMP and campus security. Some of the crimes reported to the RCMP offices on campus are not reported to campus security and vice versa, their databases are not crossed so evidently there is room for improvement in the communication between these two parties.  The second type of organizational interdependency is related to potentially conflicting policies or procedures. The UBC is autonomous in many ways, it is a true model of a small city and, as such, it is under the umbrella of many authorities: the hospital responds to the Coastal Health Authority and follows its emergency procedures, the fire hall and the ambulance services would follow PEP or even PSC procedures in the case of an emergency. At the local level, all UBC emergency responders are coordinated under the Department of Health, Safety and Environment. If there is a major disaster, it would be the Provincial Public Safety Ministry (through the Provincial Emergency Program) or even Public Safety Canada who would manage the response efforts. At a very localized level it would be UBC's Department of Health, Safety and Environment that would respond. It is at the borderline between these organizations jurisdiction that potential problems could arise. As the magnitude of an emergency increases, deciding which organization is the lead organization could be problematic (at what point does  102  PEP take over from DHSE). This is an interesting area of future research within the JIIRP-UBC project.  The third type of potential problems in an organizational interdependency is related to day-to-day conflicting cultural practices. An example of these problems is the necessary coexistence between fire fighters and ambulance paramedics. In an interview made by one of the JIIRP team members at the fire hall, it became evident that there is a rivalry between these two organizations. Conflicting views on some of the procedures during emergencies seemed to be the issue.  The fourth type of organizational interdependency is related to a strong physical dependency. An organization relies on one particular physical asset and bases important parts of its functioning on the assumption that the asset will always be provided. An example of this is the heavy dependence upon steam that the UBC hospital has in order to function during winter. One of UBC hospital's main functions is to provide care for approximately 200 long term patients. It depends heavily on steam to provide heating for these patients during winter. If a steam shortage were to occur during winter, the hospital could not last a day before starting to evacuate these patients. Finding transportation and a bed in an alternative hospital would be a major problem.  One other example of a dependency of this type is the hospital's medicine supply system. The hospital refills its medicine reserve based on an online system that automatically sends a notification to the Vancouver General Hospital. If this automatic link was not functional, as it would probably be after an earthquake, the medicine supply would stop.  103  5.3.7 Centers of High Importance on Campus After analyzing the individual infrastructure networks and the functions developed in each important building on campus, three buildings on campus stand out for its concentration of critical infrastructure: the Power House, the UBC Hospital, and the Angus building.  Figure 5.11 - 3D View (NW) of the UBC Campus — Important Buildings 24  On Figure 5.11, a 3D image of the campus is presented with the three important buildings highlighted. 1. The UBC Power House: The power house building on campus is the central facility that produces steam and the pumps of water (pressure stabilizing) for the whole campus. The steam is used on mainly for heating/cooling and for sterilization. As mentioned in the previous section, steam is an essential asset for the functioning of the hospital.  24  3D figure constructed assuming 3.5 meters per story. Data provided by UBC-Geography Dept.  104  2. The UBC Hospital: Even though the UBC hospital is not an emergency care provider, in the case of an emergency it would certainly be a center for aid to injured people. The UBC hospital provides service to people in the neighborhoods surrounding UBC. The procedures performed at the hospital are diagnostic services, short stay surgeries, and non life threatening emergencies. The hospital also is home to approximately 200 long term patients.  3. The Angus Building: The Henri Angus building holds the main telecommunications hub on campus. It holds the old copper network's main switch and it is also the main contact to the fiber optics network coming from outside the campus.  5.4 Conclusions, Limitations, and Recommendations for Future Research In this section I conclude by analyzing some of the important challenges, both practical and conceptual, faced by myself and the JIIRP-UBC team when developing the project as a whole and the I-G1S in particular. Finally, I stress the importance of continuing the effort towards integrating a robust and reliable infrastructure GIS of the UBC campus.  5.4.1 Information Sharing Challenges When the JIIRP project started, we had aimed at developing a case study focusing on an area larger than the UBC campus. We had envisioned the possibility of modeling the city of Vancouver or maybe even go at a larger scale. We soon realized that this task would be too ambitious, not only because of the complexity of the data and the interconnection of infrastructure networks at the city level, but because the data would just not be available to us. We approached the project's partners (BCTC, Telus, the GVRD, and the YVR) and obtained a different range of responses to our data requests, most of them negative. It was then that the team decided to focus on the UBC as the study area. Getting access to the UBC infrastructure databases was less difficult, although not free of challenges.  105  Data sharing in the JIIRP-UBC project  JIIRP-developer —Confidentiality agreement (?) —Specification of the use that will be given to the data —Negotiate support from data operator's supervisors —Approach at three different organizational levels  Data Owner —Incomplete data —Data not compatible —Multiple versions —Fear of competition, loss of competitive advantage if data is shared —Important data still in owner's head —Security concerns (misuse)  Figure 5.12 - Data Sharing in the JIIRP-UBC Project  Any project that deals with sensitive information will face data sharing issues. This project was no exception. In Figure 5.12 I represent the relationship between the two main of actors involved in the project, the data owners and the developers, as well as the main challenges and concerns associated to each.  On the data owner's side, all of the data issues described in the third chapter of this thesis were faced, I here provide some examples:  -  Policy issues: Different information sharing policies among the campus planning office, the utilities office, the IT office. The owners of the data had different levels of concern towards sharing it. Some immediately shared the data, others waited for an approval from higher authorities, a third group feared misuse and were reluctant to share.  -  Technical issues: Although most of the data on infrastructure networks on campus is maintained in digital format (AutoCAD drawings), we found that it is redundant in many cases. We also found different versions of the same data  106  across departments. Every time a modification is made to the conduits, the AutoCAD maps are updated in the department responsible for the modification. The new version of the file is then shared to other departments. This obviously constitutes a problem when two departments make changes simultaneously. One other issue regarding the infrastructure data is that it is "flat". The CAD drawings do not have a database associated with it. All dimensions, materials, directionality, etc., are stored as annotations on the map, this makes it impossible to use the data for analysis. — Cultural barriers: We also faced some difficulties when obtaining data due to cultural barriers. Communication was difficult some of the data owners—they would see the project as a merely academic exercise with no particular application to their work. They could not see a direct benefit from sharing the data. Concerns towards the security of the UBC community were also raised by some of the data owners if the data was misused. One operator even told some of the members of the team "How do I know that you are not terrorists?" — Non systematized information: Although most of UBC's infrastructure data is systematized in some way, many of the day-to-day operations 'know how' is not documented: the weak points in the networks, the way some of the most common issues are solved every day, the communication issues between departments, the reliance of the quotidian operation on a particular external asset or procedure. All this information is very valuable and is generally not documented. It is in the data owner's (the operator's) head. On the developer's side, we also learnt some important lessons when it comes to establishing a trust relationship with the data owners. We identified four crucial factors to obtain the data owner's cooperation:  107  — A confidentiality agreement, or some sort of written arrangement, in which the sensitivity of the data is recognized and in which the limitations of use and publication are specified. — A clear understanding on the developer's side of the use that will be given to the data. After several interviews with data owners on campus we realized that we could engage them in an agreement to share the data if we had a very clear idea of what we would be doing with their data, and we could communicate that effectively to them. This sounds evident, but as in many projects of the same nature, the data gathering process was done in parallel to the conceptual modeling, and in some cases even prior to the modeling. We knew we would need the data at some point, we just did not know to what extent and when. Not being able to give this reassurance to the data owners probably slowed down the process of accessing the data. — Support from higher level authorities. Having written or verbal approval from high authorities is something that was needed in a couple of cases in order to be able to even sit and talk about data sharing, this however was no guarantee that the data sharing would occur. — Approaching a department at three different levels. We identified broadly three levels of occupation profiles that had to be engaged with the project: the higher authority —a department director (which in many cases does not know about the data) is the person signing the official agreement; the department manager who needs to be convinced that the agreement will be beneficial for her work and thus should cooperate; and the data operator, who is the person always in contact with the data and the one that knows the flaws and has most of the day to day know-how when it comes to data maintenance. This person needs to be convinced that the flaws will not be publicized and that his job is not on the line.  108  5.4.2 Perception of Risk — Structural Changes vs. Operational Changes One important issue faced by the team when discussing the project with the involved parties at UBC is that the perception of risk can be sometimes more important to decision makers than the actual risk. Risk-management decisions may be influenced by public perceptions of risk in ways that may distort priorities away from actual risk reductions. Policy-makers may feel the need to be seen to be doing something about particular risks, even where the risks are relatively small and the actions undertaken are more visible than they are effective (Eiser, 2004).  Some of the critical interdependencies on campus can be solved with a minimum amount of investment and no spectacular developments. It is not as costly to maintain an updated building and infrastructure database and to give access to it to all people involved in an emergency as it is to retrofit a building or invest on increasing telecommunications resilience. It is, however, less noticeable.  5.4.3 Changing and Emergent Behaviours, Can these be Modeled? Modeling things such as the gas flow in a pipe network would fall into modeling "what you know". The modeling of the consequences of an earthquake on certain buildings would fall into "what you know you do not know". Trying to model the interdependencies between infrastructure systems in the time of an earthquake falls into a third category, "what you do not know you do not know".  There were four main objects that the team had to model. On their own, all of them have a certain degree of complexity:  — The modeling of the natural phenomena: the earthquake scenario  109  — The physical networks interconnectivity: the interdependencies during normal operation — The human component and its day to day relationship with the physical networks: the organizational interdependencies — The human response to an emergency  To study the combination of all of these four objects and the emergent properties that would arise from these interactions is what constitutes the main objective of the project. The unknown behaviours that will arise in a situation like an earthquake, and the consequences on the array of interconnected infrastructures, are things that will never be determined with exactitude in advance. Developing an understanding of how infrastructures are related to each other is, however, our best approach to estimate the effect of an event and to be better prepared.  5.4.4 Impossibility to Model Everything and the Importance of Defining the Infrastructure Unit (the Granularity Issue) This was certainly one of the most challenging aspects in the JIIRP-UBC project. The question of "to what detail should we model?" inspired many debates at all levels in the team. In a project of this nature it is very difficult to build the bridge between the actual data available and the conceptual model. Many times we fell in the temptation of trying to model at a higher detail than what the data or time constraints would allow. It is crucial in a project of this nature, in which many systems need to be interconnected, that the minimal infrastructure unit is defined and that there is a clear rapport between the actual raw infrastructure data unit and the conceptual infrastructure unit.  If the purpose of the overall system is to model interdependencies at a local level (e.g., an electric substation, a hospital, a water reservoir, and some local decision makers), the information required might be very detailed (e.g., the specific connectivity between the  110  substation, the hospital, and the water pumps, the functionality of backup generators). If the scale of the model is wider, for example at a city level, the level of detail should be aggregated (e.g., neighborhoods, substations) in order to make the model treatable. Creating an array of systems that can function at multiple scales could certainly be one of the research areas in the future of this project. The definition of the granularity is an important component in the definition of the project's ontology.  5.4.5 The Ontology Definition in an Interdisciplinary Project The definition of an ontology that would encompass all efforts in the project was also a difficult challenge that confronted different views and approaches in our interdisciplinary team. The definition of the project's ontology should follow the following guidelines (Marti et al., 2007):  — The abstraction or representation should allow multiple dissimilar systems to be resolved simultaneously — Representation should capture the information needed for decision making across multiple infrastructures, but only at the detail needed at a given decision making level — Representation should be applicable to any particular infrastructure despite the detail differences among them — Representation should not break down when only limited knowledge is available  Creating a link between the ontology developed for the physical infrastructure interdependencies simulator developed by the electrical engineering team (as explained in 4.1), the damage assessment module, and the I-GIS representation of the world, is an ongoing effort at the time of the writing of this thesis. The relationship is not evident between the simulator's "cell", the I-GIS "building", and the assessments (e.g., one cell could encompass several GIS buildings, one single GIS building, or sections of a GIS  111  building; similarly, one GIS building can have one or several assessments). A similar situation occurs with the simulator's "channels", the I-GIS "conduits", and the assessments. There is not a simple one-to-one or one-to-many relationship between the objects in the different systems. These two tasks continue to be under development.  5.4.6 The Role of GIS as an Integrator — Common Ground between Disciplines Geographical Information Systems are natural data integrator systems (e.g. aerial photography, satellite imagery, GPS data, Census information, etc.). As I mentioned in chapter 4 of this thesis, UBC's I-GIS was an important component in the functioning of the project as it became an information repository used by most of the other modules. The project followed a multi/interdisciplinary approach and the GIS worked as a common communication and data sharing platform amongst the members of the team. I believe there are three characteristics of Geographic Information Systems that make them ideal for interdisciplinary work:  -  Simplicity of GIS terminology and representation of the world  -  Common and natural understanding of space across disciplines and humans  -  Visually appealing representation  These three characteristics made the I-GIS a valuable tool in the project.  5.4.7 Continuing Efforts towards a Complete Infrastructure GIS I believe the efforts towards updating and maintaining the I-GIS should continue. It is important to have a centralized repository of spatial information on campus to avoid data redundancy. There are many pending tasks in that direction. Future work should include constructing a complete and accurate geometric utility network topology for each infrastructure pipe system. The construction of such a data set would allow for  112  more complex analysis for individual utility networks. The construction of a spatial data set that includes pipe materials, diameters and pipe capacities should also be a priority.  One other area of future work is the combination of the final building and lifeline assessments with the road network analysis for the planning of evacuation routes on campus. The same assessment results integrated with the upgraded geometric utility network would produce also interesting results. A final area of future work is the visualization of intermediate states of the interdependencies simulator developed by the JIIRP electrical engineering team.  5.4.8 Recommendations to other Interdisciplinary Groups After having worked for more than two years in an interdisciplinary team, and have faced the challenges described above and many others, I believe the team and I have learnt many lessons when it comes to working in interdisciplinary groups. I would not want to finish this thesis without pointing out some aspects that I believe are important when doing academic work in a large and diverse group such as UBC's JIIRP team:  A Definition of each team member's individual objective as part of overall project objectives: it is important to identify in early stages of the project the way in which individual interests and objectives fit within the general goals of the project. It is not trivial to assemble all individual efforts into a common output when many diverse individual interests are present. I believe that, in a large interdisciplinary project such as the UBC-JIIRP, it is not uncommon for a team member to loose the scope of the entire project. It is important for the success of the project that everyone know how his/her piece of the puzzle matches with everything else. A clear understanding of the interconnections between the team members' work: it is important that members of the team understand how their individual work  113  relies on other people's individual achievements as well as how their own work is used by other project participants. -  A methodology for integration of conceptualizations in an interdisciplinary environment: this point derives from the two above. There are many tools for collaborative work. In the JIIRP at UBC some of the team members introduced two specific software products: IHMC CmapTools 25 and Concept Vista 26 . The first one was more successful than the latter. At the time of its introduction to the JIIRP project, Concept Vista was still an unstable version. A wiki was one other tool used by the team as a data sharing platform. The effective implementation of this type of tools by all members of the project could help to establish a collective terminology and objectives.  -  A predefined data sharing internal policy: it is very difficult and sometimes frustrating to gain access to data for the project. Once the data is in the team's hands, it should be shared among all members. For this to happen there should also be a formal internal data sharing agreement.  -  A predefined internal authorship policy: in an interdisciplinary group in which everyone's work is connected in some way to others' and in which many share their work, it is important to specify since the beginning of the project the types of collaborative work that occur and the way in which these will be acknowledged.  25 26  Developed at the Institute for Human and Machine Cognition, available at: http://cmap.ihmc.us/ Developed at PennState university, available at: http://www.geovista.psu.edu/ConceptVISTA/index.jsp  114  References Abdalla, R.M. (2004). Utilizing 3D Web-based GIS for Infrastructure Protection and Emergency Preparedness. Proceedings of the XXth International Society for Photogrammetry and Remote Sensing Congress: "Geo-Imagery Bridging Continents". Abdalla, R.M. (2006). An Infrastructure Interdependency-Based Framework for Utilizing Network-Centric GIS as a Core Technology in Disaster Management. Dissertation Submitted to the Faculty of Graduate Studies in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy Graduate Program in Earth and Space Science. York University. Banger, S.K. (No date). Remote Sensing and Geographical Information System for Natural Disaster Management. Available at http://www.gisdevelopment.net/ application/natural_hazards/overview/nho0011.htm Castle, C. (2005). A GIS-Based Spatial Decision Support System (SDSS) for Emergency Services: London's King's Cross Redevelopment. GISRUK 2005 Conference Proceedings. Chang, S.E., McDaniels, T.L., Mikawoz, J., and Peterson, K. (2007). Infrastructure Failure Interdependencies in Extreme Events: Power Outage Consequences in the 1998 Ice Storm. Natural Hazards, 41(2), 337-358. http://dx.doi.org/ 10.1007/s11069-006-9039-4 De Silva, N.F. (2000). Challenges in Designing Spatial Decision Support Systems for Evacuation Planning. Available at: http://www.colorado.edu/hazards /wp/ 105/ wp105.html Dudenhoeffer D., Permann M.R., and Manic, M. (2006). CIMS: A Framework for Infrastructure Interdependency Modeling and Analysis. Proceedings of the 2006 Winter Simulation Conference (L.F. Perrone, F.P. Wieland, J. Liu, B.G. Lawson, D.M. Nicol, and R.M. Fujimoto, Eds.). Dudenhoeffer, D., Permann M. R., and Boring R. L. (2006). Decision consequence in complex environments: Visualizing decision impact. In Proceeding of Sharing Solutions for Emergencies and Hazardous Environments. American Nuclear SocietyJoint Topical Meeting: 9th Emergency Preparedness and Response/11th Robotics and Remote Systems for Hazardous Environments.  115  Duefias-Osorio, L., Craig, J.I., Goodno, B.J., and Bostrom, A. (2007). Interdependent Response of Networked Systems. Journal of Infrastructure Systems, 13(3), 185194. http://dx.doi.org/10.1061/(ASCE)1076-0342(2007)13:3(185) Eiser, J.R. (2004). Public Perception of Risk. Centre for Research in Social Attitudes Department of Psychology University of Sheffield Sheffield S10 2TP. Available at: http://www. foresight. gov.uk/Previous_Proj ects/Intelli gent_ Infrastructure_Systems/Reports_and Publicationsantelligentinfrastructure Fut ures/PublicPerceptionofRisk/long_paper.pdf Entwistle, R. (2003). Kelowna Fires. Presentation at URISA BC Symposium, 2003. Available at: www.urisabc.org/assets/events/2003/kelownafires/ kelownafires_presentation.pdf Fletcher, D.R. (2002). The Role of Geospatial Technology in Critical Transportation Infrastructure Protection: A Research Agenda. Available at: http://www.ncgia.ucsb.edu/ ncrst/research/cip/CIPAgenda.pdf Greene, R.W. (2002). Confronting Catastrophe: A GIS Handbook. ESRI Press. Haimes, Y.Y. (2005). Infrastructure Interdependencies and Homeland Security. Journal of Infrastructure Systems, 11(2), 65-66. http://dx.doi.org/10.1061/ (ASCE)10760342(2005)11:2(65) Herold, S., Sawada M. and Wellar, B. (2005). Integrating Geographic Information Systems, Spatial Databases and the Internet: A Framework for Disaster Management. Proceedings of the 98 th Annual Canadian Institute of Geomatics Conference. Hollman, J. A., Marti, J. R., Jatskevich J., Srivastava K.D. (2007). Dynamic islanding of critical infrastructures: a suitable strategy to survive and mitigate extreme events. International Journal of Emergency Management (IJEM), Vol. 4, Issue 1. Liu, L. (2007). Prototyping and Cells Modeling of the Infrastructure Interdependencies Simulator I2Sim. MSc Thesis, UBC, Department of Electrical and Computer Engineering. Mansourian, A., Rajabifard, A., Valadan, Z., and Williamson I. (2006). Using SDI and Web-Based System to Facilitate Disaster Management. Computers & Geosciences, 32, 303-315.  116  Marti, J. (2007). Simulation of Infrastructure Interdependencies Dynamics for Disaster Response Coordination. Presentation given at the JIIRP workshop, February 2007. Marti, J., Hollman, J., Ventura, C., and Jatskevich, J. (2006). Design for Survival. RealTime Infrastructures Coordination. Proceedings of the International Workshop on Complex Network and Infrastructure Protection. National Consortium for Remote Sensing in Transportation. Available at: (http://www.ncrst.org/ncrst.html) Pederson, P., Dudenhoeffer, D., Hartley, S., and Permann, M. (2006). Critical  Infrastructure Interdependency Modeling: A Survey of U.S. and International Research. Idaho National Laboratory, Critical Infrastructure Protection Division. Idaho Falls. Prepared for the Technical Support Working Group. https ://www.pcsforum. org/library/files/1159904563T S WG_INL_CIP_Tool_ Survey_final .pdf  Peerenboom, J. (No date). Infrastructure Interdependencies: Overview of Concepts and Terminology. Infrastructure Assurance Center Argonne National Laboratory. Available at: http://www.pnwer.org/pris/peerenboom_pdf.pdf Public Safety and Emergency Preparedness Canada. Available at: http://www.ocipep.gc.ca/critical/nciap/nci_sectorl_e.asp#summary Rajabifard, A. and Williamson, P.I., (1999). Spatial Data Infrastructures: Concept, SDI Hierarchy and Future Directions. Proceedings of Geomatics '80 Conference, Teheran, Iran. Available at: http://www.geoinfo.aitac.th/ download/SCOSA2007/ l_DrAbbas/2-SDIConceptandNature.pdf Rajabifard, A., Chan, T.O., and Williamson, I.P. (1999). The Nature of Regional Spatial Data Infrastructures. The 27th Annual Conference of AURISA. Blue Mountains, Australia. Rakde, J., Cova, T., Sheridan, M.F., Troy, A., Mu, L., and Johnson, R. (2000). Challenges for GIS in Emergency Preparedness and Response. ESRI White Paper. Available at: http://www.esri.com/library/whitepapers/ pdfs/challenges.pdf Rao Singupuram, S.P. (2007). PC-Cluster Simulator for Joint Infrastructure Interdependencies Studies. MSc Thesis, UBC, Department of Electrical and Computer Engineering.  117  Rinaldi S.M., (2004). Modeling and Simulating Critical Infrastructures and Their Interdependencies. Proceedings of the 37th Hawaii International Conference on System Sciences. Rinaldi, S.M., Peerenboom, J.P., Kelly, T.K. (2001). Identifying, Understanding, and Analyzing Critical Infrastructure Interdependencies. IEEE Control Systems Magazine. Robinson, C.P., Woodard, J. B., Vernado, S. (1998). Critical Infrastructure: Interlinked and Vulnerable, Issues in Science and Technology, Fall 1998. http://issues.org/15.1/robins.htm Sotoodeh, M. (2007). Ontology-Based Semantic Interoperability in Emergency Management. Department of Electrical and Computer Engineering, UBC, July 2007. JIIRP-UBC internal documentation. Swiatek, J.A. (1999). Crisis Prediction Disaster Management. CATS Technical Paper. Available at: http://www.saic.com/products/simulation/cats/cats.html Thibert, K., (2008). A Methodology For Assessing The Seismic Risk Of Buildings. MSc Thesis, UBC, Department of Civil Engineering. Thiebert, K., Ventura, C., and Juarez, H. (2007). Seismic Risk of UBC Buildings. JIIRP — UBC internal presentation. Available at: https://bugs.cs.ubc.ca/twiki/ pub/JIIRP/StudentThesis/Thibert-SeismicRiskofBuildings.pdf Thomas W.H., North M.J., Macal C.M., and Peerenboom, J.P. (2003). From Physics to Finances: Complex Adaptive Systems Representation of Infrastructure Interdependencies. Naval Surface Warfare Center. Dahlgren Division Technical Digest, 58-67. Wimbish, W. and Sterling, J. (2003). Center for Strategic Leadership, U.S. Army War College, Vol. 06-03.  118  Appendix A: Water Network and Water Circuits Geodatabase Table Structure Water Network: Id 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38  Name Water1.3.1 Waterl.3 Water1.4.1.1 Water2 Water2 Water2 Water2 Water2 Water2 Water2 Water2 Water2 Water2 Water1.4.1 Water1.4.1 Water1.4.1 Water1.4.1 Water1.4.1 Water1.4.1 Water1.4.1 Water1.4.1 Water1.4.1 Water1.4.2 Water1.4.2 Water1.4.2 Waterl.4 Waterl.4 Waterl.4 Water1.4 Waterl.4 Waterl.4 Waterl.4 Waterl.4 Waterl.4 Waterl.4 Waterl.4 Waterl.4  Parent Waterl.3 Waterl, PH Water1.4.1  Waterl.4 Waterl.4 Waterl.4 Waterl.4 Waterl.4 Waterl.4 Waterl.4 Waterl.4 Waterl.4 Waterl.4 Water1.4 Waterl.4 Waterl, PH Waterl, PH Waterl, PH Waterl, PH Waterl, PH Waterl, PH Waterl, PH Waterl, PH Waterl, PH Waterl, PH Waterl, PH Waterl, PH  Level  PipeID  Length 0 3 2 4 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 3 2 2 2 2 2 2 2 2 2 2 2 2  0.00 82.86 243.81 198.00 160.08 136.58 1054.42 108.50 17.40 320.50 132.00 75.40 59.70 251.00 6.40 116.20 42.90 125.50 196.00 139.00 67.60 137.55 2.44 7.00 122.60 88.00 9.30 108.60 152.00 23.40 148.80 16.40 103.70 150.00 154.40 2.70 4.20 95.00  0 0 0 6910 9999 41 42 8030 8040 8050 8060 8080 8120 8130 4710 4730 4830 5010 31 32 6920 8000 8002 6630 620 621 6360 1019 18 6090 6080 6050 6040 6041 4580 4490 4590 4770  119  Water Circuits: OBJECTID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45  GISID 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44  WTRCIRCUIT Water1.4.3 Waterl.4.B Water1.4.3 Waterl.4.B Waterl.4.B Waterl.4.B Water1.4.3 Waterl.4.B Waterl.4.B Waterl.4.0 Waterl.4.0 Waterl.4.0 Waterl.4.B Waterl.4.0 Waterl.4.0 Waterl.4.B Waterl.4.B Water1.4.4 Waterl.4.A Water1.4.4 Water1.4.4 Water1.4.4 Water1.4.4 Waterl.4.A Water1.4.3 Waterl.4.A Waterl.4.A Waterl.4.A Waterl.4.A Waterl.4.A Waterl.4.A Waterl.4.A Waterl.4.A Waterl.4.A Waterl.4.A Waterl.4.A Waterl.4.A Waterl.4.A Waterl.4.A Waterl.4.A Waterl.4.A Waterl.4.A Waterl.4.A Waterl.4.A Waterl.4.A  120  Appendix B: Gas Network and Gas Circuits Geodatabase Table Structure Gas network: ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38  Name Terasen2.GA2 Terasen2 .GA2 Terasen2.GA2 Terasenl.GA1 Terasenl .GA1 Terasenl.GA1.GA1 Terasenl .GA1 Terasenl.GAI Terasenl.GA1 Terasenl.GA1.GA1 Terasenl.GA1 Terasenl.GA1 Terasenl.GA1.GA1 Terasenl.GA1 Terasenl.GA1 Terasenl.GA1 Terasenl.GA1 Terasenl.GA1 Terasen 1 .GA1 .GA1 Terasenl.GAI.GA1 Terasen 1 .GAl.GA1 Terasenl.GA1 .GA1 Terasen 1 .GA1 .GA1 Terasenl.GA1.GA1 Terasen 1 .GAI Terasenl .GA1 .GA1 Terasenl.GA1.GA1 Terasenl.GAl.GAI Terasenl.GA1.GA1 Terasenl .GA1 .GA I Terasenl.GAI.GA1 Terasenl.GA1.GA1 Terasenl.GA1.GA1 Terasenl.GA1 Terasenl.GA1 Terasen 1 .GAI Terasenl.GA1 Terasenl.GA1.GA1  Parent Terasen2 Terasen2 Terasen2 Terasenl Terasenl Terasenl.GA1 Terasenl Terasenl Terasenl Terasenl.GA1 Terasenl Terasenl Terasenl.GA1 Terasenl Terasenl Terasenl Terasen I Terasen I Terasenl.GA1 Terasenl.GA1 Terasenl .GA I Terasenl.GA1 Terasenl.GA1 Terasenl .GA1 Terasen I Terasenl .GA1 Terasenl.GAI Terasenl .GA1 Terasen I .GA1 Terasenl .GA1 Terasenl.GA1 Terasenl .GA1 Terasenl.GA1 Terasen 1 Terasenl Terasenl Terasenl Terasenl.GA1  Level 2 2 2 2 2 3 2 2 2 3 2 2 3 2 2 2 2 2 3 3 3 3 3 3 2 3 3 3 3 3 3 3 3 2 2 2 2 3  PipeID 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0  Lenght 1.82085126039 80.59253856070 5.98163144205 1.63975264581 1.11698046808 1.41176825937 2.61444768793 1.20369711185 1.28781734068 1.61018052230 1.93982811990 2.01618271780 1.07860105334 2.75374074638 8.69712857713 71.47056987720 3.07020384655 1.72918745261 3.93030446544 14.72506898030 1.73659911414 1.64554323581 3.43518607504 2.25061258127 1.24218861301 1.87664307352 1.82453600310 6.35069603148 3.00320989806 1.52396103893 20.25156914290 89.32563966020 119.09276405700 60.72361192860 6.95711722756 0.01750106289 2.93536193945 10.70579823400  121  Gas Circuits: OBJECTID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 46  GISID 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 45  GASCIRCUIT  Terasenl.2 Terasen2.GA2. 15 Terasen2.GA2.15 Terasenl.GA1.7 Terasenl.GA1.5 Terasenl.GA1.5  Terasen2.GA2.15  Terasen2.GA2.6 Terasen2.GA2.6 Terasen2.GA2.13 Terasen2.GA2.11 Terasen2.GA2.11 Terasen2.GA2.11 Terasen2.GA2.11 Terasen2.GA2.13 Terasen2.GA2.13 Terasenl.GA1.6 Terasenl.GA1.6 Terasenl.GA1.7 Terasenl.GA1.7 Terasenl.GA1.GA1.7 Terasenl.GA1.GA1.7 Terasenl.GA1.GA1.7  Terasenl.GA1.7 Terasenl.GAI.GA1.7  Terasenl.GA1.4  122  Appendix C: GeoDatabase Model UBC - IGIS GEODATABASE  RDB_bdg to bus PK  GISID  RDB_Cell_Classification  RDB_Building_Circuits_Water  PK GISID  PK  GISID  A RDB_Building  RDB_Building_Circuits_Gas  PK,FK2,FK3,FK4 GISID PK,FK1 ObjectiD  PK  GISID  RDB_Gas_Pipes PK PK  Obiect1D GISID  RDB_Roads_UBC PK Obiect1D  4 RDB_Water pipes PK ObiectlD PK GISID  4  RDB Assessment PK PK,FK2,FK3,FK4,FK5 PK,FK1,FK2,FK4,FK5 PK  PioeID ObjectID GISID RoadID  RDB_Steam_pipes PK PK  Object1D GISID  Version  Version  123  

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.24.1-0066623/manifest

Comment

Related Items