UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Infrastructure interdependencies simulation (I2Sim) system model and toolbox Lee, HyunJung 2010

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

Item Metadata

Download

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

Full Text

Infrastructure Interdependencies Simulation (I2Sim) System Model and Toolbox by HyunJung Lee B.A.Sc., The University of British Columbia, 2007 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in The Faculty of Graduate Studies (Electrical and Computer Engineering) THE UNIVERSITY OF BRITISH COLUMBIA (Vancouver) April 2010 © HyunJung Lee 2010 Abstract The interdependencies between infrastructures have become more complex with the growth of the civilization. As a result, the cascading effects on the system caused by a failure of one infrastructure became larger and unpredictable. As seen from the ma- jor disasters such as the Sichuan earthquake in China, understanding infrastructure interdependencies and allocating resources efficiently in the system can facilitate the recovery process significantly. As a part of Canadian Government’s effort to develop innovative ways to mitigate large disaster situations and grow resiliences of systems, Joint Infrastructure Interdependencies Research Program (JIIRP) has been formed. The UBC’s Infrastructure Interdependencies Simulation (I2Sim) group led by Dr. Jose Marti participated to study decision making for critical linkages in infrastructure networks. At the end of the program period, its achievement was recognized, and the I2Sim group was selected to develop a simulator for the Vancouver 2010 Winter Olympics. As a part of this research, the concept of cells, channels, and tokens along with com- ponents consisting the cells were developed. The core of the cells and the channels are formed by the Human Readable Tables (HRT) which describe the relationship between the inputs and the outputs of the unit. The HRT allows a reasonable prediction of the real life system even with limited data. As a result, the infrastructure owners do not have to disclose the confidential operational information of the system. The test case models were built based on the UBC Campus first and extended to the Olympics sites in Vancouver. To simulate the test cases, a customized Matlab/Simulink toolbox called I2Sim was developed. The I2Sim toolbox follows a graphical drag-and-drop box format. Since the user of the toolbox only has to deal with the graphical interface, even the non-experts can build a case easily. The main improved features included in the new version is that the effect of time delay in the channels and the human flow. The test case results helps producing an optimal resource allocation and the restoration priorities during disasters. ii Table of Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.1 Infrastructure Interdependencies . . . . . . . . . . . . . . . . . . 3 1.2.2 Previous Researches . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Research Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4 Organization of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2 Infrastructure Interdependencies Simulation (I2Sim) . . . . . . . . . . . . . 8 2.1 I2Sim Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.1 Cell and Channel Classification . . . . . . . . . . . . . . . . . . . 9 2.2 I2Sim Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3 Discrete Event Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.1 Uncontrollable Event . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.2 Time-dependent Event . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.3 Decision-making Event . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4 UBC Campus and Vancouver 2010 Winter Olympics . . . . . . . . . . . 12 2.4.1 UBC Campus Test Case . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4.2 Vancouver 2010 Winter Olympics . . . . . . . . . . . . . . . . . . 13 iii Table of Contents 3 Human Readable Table (HRT) . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1 Human Readable Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.1 Types of Human Readable Tables . . . . . . . . . . . . . . . . . . 16 3.2 Physical Mode (PM) and Resource Mode (RM) . . . . . . . . . . . . . . . 18 3.3 Color Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.4 Construction of a Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4.1 Information Gathering . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4.2 Building Human Readable Table . . . . . . . . . . . . . . . . . . . 22 3.4.3 Designing Cells using I2Sim Toolbox . . . . . . . . . . . . . . . . 23 4 I2Sim Toolbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1 Development of Customized Blocks . . . . . . . . . . . . . . . . . . . . . 25 4.2 I2Sim Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2.1 Aggregator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2.2 Human Readable Table (HRT) . . . . . . . . . . . . . . . . . . . . 26 4.2.3 Distributor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2.4 Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.2.5 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2.6 Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.2.7 Sink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5 Simulations and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.1 UBC Campus Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.1.1 Scenario 2 of Liu’s Thesis . . . . . . . . . . . . . . . . . . . . . . . 41 5.1.2 Modified Version of the Scenario 2 of Liu’s Thesis . . . . . . . . . 46 5.1.2.1 Model and Scenario Change . . . . . . . . . . . . . . . . 46 5.1.2.2 Scenario and Results . . . . . . . . . . . . . . . . . . . . 47 5.2 Vancouver 2010 Winter Olympics Case . . . . . . . . . . . . . . . . . . . 53 5.2.1 Crowd Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.2.2 Initial Conditions and Scenario . . . . . . . . . . . . . . . . . . . . 54 5.2.3 Results and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.3 Simulation Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.4 Limitation of the MATLAB . . . . . . . . . . . . . . . . . . . . . . . . . . 60 iv Table of Contents 6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.1 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Appendices A Aggregator MATLAB System Function Code . . . . . . . . . . . . . . . . . . 68 B HRT MATLAB System Function Code . . . . . . . . . . . . . . . . . . . . . . 70 C Distributor MATLAB System Function Code . . . . . . . . . . . . . . . . . . 77 D Channel MATLAB System Function Code . . . . . . . . . . . . . . . . . . . . 80 E Statement of Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 v List of Tables 3.1 Production Human Readable Table . . . . . . . . . . . . . . . . . . . . . . 16 3.2 Channel Human Readable Table . . . . . . . . . . . . . . . . . . . . . . . 17 3.3 Distributor Human Readable Table . . . . . . . . . . . . . . . . . . . . . . 17 vi List of Figures 2.1 Cell Classification Example . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 I2Sim Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1 Physical Mode and Resource Mode . . . . . . . . . . . . . . . . . . . . . . 19 3.2 Color Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.3 PM RM Color Representation in a Block . . . . . . . . . . . . . . . . . . . 20 3.4 Generic Cell Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.1 I2Sim Toolbox in Simulink . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2 Aggregator Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3 Human Readable Table Block . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.4 Distribution Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.5 Distributor Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.6 Channel Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.7 Storage Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.8 Source Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.9 Sink Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.1 Design of Reduced UBC Campus Test Case . . . . . . . . . . . . . . . . . 39 5.2 Simulation of Reduced UBC Campus Test Case . . . . . . . . . . . . . . . 40 5.3 Substation Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.4 Substation Cell Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.5 Power House, Steam Station, Water Station Cell Results . . . . . . . . . . 44 5.6 Hospital Cell Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.7 Water Station Back-up Oil Tank Level . . . . . . . . . . . . . . . . . . . . 45 5.8 Human Flow Model for Purdy Hospital . . . . . . . . . . . . . . . . . . . 47 5.9 Water Station and Steam Station Cell Outputs . . . . . . . . . . . . . . . . 49 5.10 Hospital Cell Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 vii List of Figures 5.11 Vancouver 2010 Winter Olympics Study Area . . . . . . . . . . . . . . . . 51 5.12 Vancouver 2010 Winter Olympics Simulink Model . . . . . . . . . . . . . 52 5.13 GM Place with Crowd Model . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.14 Electricity to BC Place, GM Place, and St Paul’s Hospital . . . . . . . . . 56 5.15 Water to Hospitals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.16 Waiting Area for Olympics Venues . . . . . . . . . . . . . . . . . . . . . . 58 5.17 Olympics Case Hospital Model Results . . . . . . . . . . . . . . . . . . . 59 viii List of Algorithms 4.1 Human Readable Table Search Algorithm . . . . . . . . . . . . . . . . . . . 28 4.2 Distributor Search Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 31 ix Acknowledgements I am very grateful to my supervisor, Professor Jose R. Marti, for his guidance during the last three years. Dr. Marti introduced me to the rich field of power engineering and infrastructure simulation and demonstrated first-hand the level of dedication and hard work required to be successful in this field. This thesis would not have been possible without his help and support. I would also like to thank Professor K.D. Srivastava and Professor Juri Jatskevich for being the members of my thesis committee and providing insightful feedback throughout my Master’s program. I would like to thank my col- leagues and friends Marcelo Tomim, Hugon Juarez, Brian Burtchett, Jian Xu, Shahrzad Rostamirad, Tom De Rybel, and Lucy Liu as well as the students in the Power Lab- oratory for the interesting discussions we had and for the valuable comments they provided for the work in this thesis. They made my experience at UBC unforgettable and I am very lucky to have been able to meet them. I am grateful to my family for their unconditional love and support throughout my life. I would not be where I am today without the sacrifices that they have made. I would never forget the cheer-up shopping with my sister SookSook and the summer trips with my brother ChangChang. I also want to thank my best friends, Nara Shin and Eugenia Chen, for their emotional supports. Above all, I wish to sincerely thank my husband George Yuan, who was there since the first day as a UBC graduate stu- dent, for his unyielding support and love, bearing with me through the tough times. Finally I would like to express my thanks to Natural Sciences and Engineering Research Council (NSERC) of Canada and Vancouver Olympics Committee (VANOC) that provided the support for this work. x To George, my husband xi Chapter 1 Introduction The topic of this thesis is the development of a simulator and models in order to study the interdependencies between infrastructures and critical buildings during disasters as well as the effective decision making processes. The work in this thesis is a part of the research done by Infrastructure Interdependencies Simulation (I2SiM) group led by Dr. Jose Marti at the University of British Columbia (UBC) for the Joint Infrastruc- ture Interdependencies Research Program (JIIRP) [19] and the Vancouver Organizing Committee for the 2010 Olympics and Paralympics Winter Games (VANOC) [12]. 1.1 Motivation The effective allocation of resources and services among the different infrastructures, such as power and water utilities, telecommunications, transportation networks and hospitals, has become significant in the modern society. At the same time, the intercon- nection and interdependencies between these infrastructures have become intensely complex which makes the system more vulnerable to failures from cascading effects. Since the dependencies between infrastructures are not easily identified, it is difficult to determine how to operate the system by intuition alone. Especially during large disasters, prompt and effective responses and resilience are very closely related to the probability of human survivals. Through major events, such as the New York City attacks on September 11, 2001, the Eastern North America power blackout on August 14, 2003 [4], and the South Asia tsunami on December 26, 2004 [6], we have learned the importance of operating infrastructures effectively to achieve fast restorations and strong resilience of the system. To ensure the resilience of the system, it is important to define what it is first. The resilience of a system can be conceptualized into four categories as follows [8] [21]: • Robustness - the ability of elements and system to withstand stress without suf- fering degradation 1 1.1. Motivation • Redundancy - the extent to which elements and system to be substitutable by other elements in the event of disruption • Resourcefulness - the capacity to identify problems, establish priorities, and mo- bilize resources during the event of disruption or scarceness of resources • Rapidity - the capacity to meet priorities and goals within the required time in order to avoid future disruption Ensuring resilience of the system during the disaster requires more than a fast and proper response during the disaster. It also involves the preparations before the dis- aster and the restorations after the disaster. Hollman et al define the four stages of management of infrastructures for disasters as follows [16]: • Mitigation - long before the disaster • Preparedness - long and shortly before the disaster • Response - during and shortly after the disaster • Recovery - shortly and long after the disaster Mitigation refers to the sustained actions to reduce the long-term impacts from dis- asters long before the disaster while preparedness is the policies and plans on emer- gency management. Response is the actions taken during or immediately after the disaster; and Recovery is the restoration actions after the disaster. Any actions that are taken during these stages are dynamically interconnected. As part of Canadian Governments effort to develop innovative ways to mitigate large disaster situation and grow resilience of systems, Joint Infrastructure Interdepen- dencies Research Program (JIIRP) has been formed through the Natural Sciences and Engineering Research Council (NSERC) and Public Safety Canada (PS) [19] [20]. UBC I2Sim group led by Dr. Jose Marti was the largest group out of six university groups participating in this project to study decision making for critical linkages in infrastruc- ture networks. At the end of the project period, its achievement was recognized, and I2Sim group was selected to develop a simulator for Vancouver 2010 Winter Olympics in 2009. 2 1.2. Background 1.2 Background This section gives an overview of the fundamental concepts of the infrastructure inter- dependencies and related researches that have been conducted. 1.2.1 Infrastructure Interdependencies The study of infrastructure interdependency has not been emphasized until recently. As a result, the definition of infrastructures and the classification of interdependencies between them may not be clear to many people. The Critical Infrastructure Assurance Office (CIAO) defined infrastructure as [1] [27]: ”the framework of interdependent networks and systems comprising identifiable industries, institutions (including people and procedures), and distribution capa- bilities that provide a reliable flow of products and services essential to the defense and economic security of the United States, the smooth functioning of governments at all levels, and society as a whole [1].” This describes that the infrastructures are not limited only to the physical buildings and lifelines. By this definition, infrastructures are ”interdependent” networks, which leads to the questions of what is the ”interdependency” and how it is different from the ”dependency”. Rinaldi et al. describes the dependency as a linkage between two infras- tructures, through which one infrastructure influences the other while the interdepen- dency is a bidirectional relationship between two infrastructures, through which both infrastructures affect each other [27]. Interdependencies can be classified into different types depending on their characteristics. Rinaldi et al. classifies the interdependencies into four categories according to the nature of linkage between infrastructures as follows [10] [27] [28]: • Physical Interdependency - the state of an infrastructure depends upon the mate- rial outputs of another infrastructure and vice versa. Physical interdependencies arise from physical linkages between infrastructures such as transmission lines. • Cyber Interdependency - the state of an infrastructure depends on information transferred through the information infrastructure such as supervisory control and data acquisition (SCADA) systems in power networks. 3 1.2. Background • Geographic Interdependency - a local environmental event can create state changes in all infrastructure due to close spatial proximity such as collocated elements in different infrastructures in a common right-of-way. • Logical Interdependency - the state of an infrastructure depends upon the state of another infrastructure and vice versa through the means that is not all of above. The logical linkage can be policy, legal or regulatory regimes. Rinaldi et al’s interdependency classification is a simple but yet comprehensive way of describing different types of infrastructure linkages. 1.2.2 Previous Researches As mentioned above, the research of infrastructure interdependency simulation alone is relatively new; however, the techniques and studies regarding disasters have been actively developed and evolved since Oklahoma City bombing in 1995 and the report from the Defense Science Board Task Force on Information Warfare in 1996. According to Marti et al. [17], present simulation tools involve either the macro- scopic view of emergency preparedness organizations or the microscopic view of the first responders. The emergency preparedness organizations may see the whole pic- ture of how the infrastructures interact; they, however, may miss the details and com- plexity of each infrastructure and hidden interdependencies between infrastructures, which could result in a sequential catastrophic responses. The first responders may be an expert in their field, but they would not be able to see the operation of other infras- tructures. In this thesis, the simulation itself is proceeded as an integrated simulation while each infrastructure can be modeled separately by its own expert. In this way, the simulator can capture the advantages of both approaches taking macroscopic and microscopic view of the situation. According to the survey performed by Pederson et al., most infrastructure simu- lation tools have taken two approaches on modeling the infrastructure system: inte- grated and coupled models [2]. The integrated model is designed to model multiple infrastructures and their interdependencies within one framework. The coupled ap- proach takes multiple simulations of infrastructures and connect them together. The major modeling techniques using these two approaches are Petri Nets, System Dy- namics, Agent-based, Physics based and Input-output Model [2]. In addition to these techniques, Cell-channel model has been developed by UBC I2Sim group, which this 4 1.2. Background thesis has been developed upon. The following is a summary of techniques mentioned above. • Petri Net - A Petri net is a graphical and mathematical tool for modeling dis- crete distritbuted systems. It is composed of places, transitions, and directed arc connecting places and transitions. Petri Net uses the flow of tokens to show the state of the infrastructures and the interdependencies between them. Tokens are stored in the places and transferred to another places through transitions. In [13], Gurseli et al use the Petri net’s place invariants to model the major infras- tructures such as electricity, oil, water, natural gas, and telecommunication and identify the interdependencies and vulnerabilities by assigning 1 for ”ON” and 0 for ”OFF”. Petri net has an advantage of presenting a simple visualization of interdependencies. However, it lacks the ability to model quantitative informa- tion. • System Dynamics - System Dynamics is a continuous time based approach to model complex feedback systems. Forrester developed the methodology focus- ing on stocks, flows, and the feedback of the system over time [26]. Min et al. simulated an infrastructure interdependency model using this technique com- bined with IDEFO for decision makings [15]. System Dynamics are more suitable for high-level view of the system rather than a detailed model of infrastructures. That is, it gives a macroscopic view of the effect from policies or plans on multiple infrastructures for the emergency preparedness organizations. • Agent-Based Model - The agent-based modeling paradigm is one of the most popular approaches used for the infrastructure interdependency simulations [2]. An agent-based model consists of autonomous decision makers called agents who each assesses the situation and makes decision according to their own rules [7]. Each agent is assigned with different responsibilities such as water production, electricity distribution, or back-up system start. When a simple behavior of each agent is combined, it creates complex random patterns of a system. A number of infrastructure models have been developed using agent-based model including Critical Infrastructure Modeling Software (CIMS) developed by the Idaho National Laboratory [10] [25], Critical Infrastructure Simulation by Inter- dependent Agents (CISIA) presented by Panzieri et al. [2] [23] [24], and Next- generation agent-based economic laboratory (N-ABLE) by Sandia National Lab- 5 1.3. Research Objectives oratories [2] [11]. In the agent-based model, the detailed models of infrastruc- tures, in general, are done separately and fed into agents as inputs [22]. • Cell-Channel Model - The cell-channel model is a unique modeling technique used for UBC I2Sim project by Marti et al. [17]. This thesis is the extension of the first version of cell-channel model which was implemented by Liu [18]. The model consists of the identities called cells, channels, and tokens. Infrastructures are defined as cells where transformation of tokens occur. The tokens are the resources or services that flow between cells using channels. The channels are the representation of lifelines such as transmission lines and water pipe lines. Cells and channels are composed of Human Readable Tables and other addi- tional components. The operating state of cells and channels are expressed as physical modes and resource modes of the system. The details about cell-channel model will be discussed throughout chapter 2 and chapter 3 of this thesis. All of above methods have their strengths and weaknesses. For the new I2Sim model, I studied previous work done on the infrastructure interdependency simulation to take advantage of strengths and improve on weaknesses. The main advantages of the new I2Sim model are that: (1) it can simulate and produce a reasonable prediction with both limited and extensive information; and (2) the goal of the simulations (e.g. the human survival, economics, etc) can be easily modified by the users; and (3) the simulations can be put together by a non-expert of the infrastructures. 1.3 Research Objectives The objective of my research is to develop a simulation tool, I2Sim Simulator, that can help study decision making process and interdependencies in infrastructure network before, during, and after disasters in real time. I2Sim Simulator is designed to help even the non-experts of the infrastructures before, during, and after the disaster to in- crease the resilience of the system. The goal of test cases performed during my research is to demonstrate the effective application and the usage of the I2Sim Simulator. 1.4 Organization of the Thesis The rest of the thesis is organized as follows: 6 1.4. Organization of the Thesis • Chapter 2 describes the ontology and the architecture of Infrastructure Interde- pendency Simulation as well as the scale of test cases performed. • Chapter 3 presents the modeling of different types of Human Readable Table as well as the concept of physical modes and resource modes. It then introduces how to construct physical area of interest into a virtual model using I2Sim. • Chapter 4 proposes the techniques to build I2Sim Toolbox using Matlab/Simulink and the different components of the toolbox. • Chapter 5 presents and analyzes simulation test cases and results. • Chapter 6 concludes this thesis and suggests some of the future works that can be done. 7 Chapter 2 Infrastructure Interdependencies Simulation (I2Sim) The behavior of the infrastructure systems such as power, water, and gas networks is highly non-linear and complex in nature. Even though many tools have been devel- oped specialized in each of these infrastructures to accurately calculate and estimate the results, predicting the outcome when these infrastructures are interconnected to- gether in a single system is still difficult. In addition, it is even more difficult to find an expert who is experienced enough to handle and make a decision upon such system. The purpose of Infrastructure Interdependency Simulator is to aid in decision mak- ing processes without the user being an expert in the area of all infrastructures. I2Sim is a tool that can help a non-expert to build a system of interdependent infrastructures and accurately predict the direct and indirect outcomes of the decisions made. In ad- dition, it can help discover the hidden interdependencies between infrastructures. 2.1 I2Sim Ontology In Infrastructure Interdependencies Simulation (I2Sim), physical entities such as build- ings and lifelines in a geographical area are represented by three major virtual entities: a token, a cell, and a channel. • A token is an entity that flows and is transformed in the system. It includes the resources, services and humans. • A cell is an entity where one or more types of tokens are consumed to produce a specific type of tokens. That is, it is a functional unit where a transformation of tokens occur. • A channel is an entity where a specific type of tokens flow. Unlike a cell, the nature of tokens does not change in the channel, but there may be losses and a 8 2.1. I2Sim Ontology time delay between the input and the output. 2.1.1 Cell and Channel Classification In general, cells are used to represent physical buildings such as hospitals, substations, and water stations. For instance, a water station cell takes electricity and low-pressured water as input tokens and produces high-pressured water as an output token. How- ever, a cell does not necessarily means one building. A group of buildings with the same functionality and geographical location can be represented as one cell whereas one building with multiple functionalities can be represented by a number of cells. For example, a power house building with two functionalities, a water station and a steam station, will be represented by two cells as shown in Figure 2.1(a). Also, a group of houses in an area can be one cell as shown in Figure 2.1(b). Power House Building Water Station Cell Steam Station Cell (a) One building with Two Cells Residence Cell House1 House2 House3 (b) One cell with Multiple Buildings Figure 2.1: Cell Classification Example Channels are virtual representations of uni-directional connection from one cell to another. The type of channels can vary from the roads for cars and humans to the lifelines for water, gas, and electricity. A channel model simplifies the complex charac- teristics of a physical connection by capturing only total loss and time delay occurred during the transportation in the channel. For examples, water from a water station may go through different types of water pipes with the breakages at different parts to arrive at a residence, but only factors needed to build a channel are the total leakage added up throughout the pipes and the total time it takes to arrive at the residence. 9 2.2. I2Sim Architecture - Study area - Critical buildings (infrastructure, hospitals, etc) - lifelines I2Sim GIS - Virtual cell and channel models - Human Readable Tables I2DB - Disaster scenario - Physical damage assessment to buildings and lifelines I2Sim Damage Assessment - Simulation I2Sim Toolbox - Result analysis - Decision making I2Sim Operating Centre Mapping Implementation Assessment Scenario Development Results Decisions Figure 2.2: I2Sim Architecture 2.2 I2Sim Architecture Building a system with I2Sim involves the multidisciplinary fields such as geography, computer science, civil engineering, and electrical engineering. The architecture of I2Sim is as shown in Figure 2.2. The geographical study area for a disaster is identified along with the critical build- ings and lifelines. Using a GIS program, physical buildings and lifelines are mapped into the virtual cell and channel models in I2Sim Database (I2DB). I2DB also contains the Human Readable Tables (HRT) which is used to define cells and channels. The details about HRT will be discussed in the next chapter. The geographical information in GIS is also used by I2Sim Damage Assessment to help the cell and channel classi- fications and the scenario development for I2Sim simulation [30] [9]. For a practical application of I2Sim, the result from simulation would usually be communicated to an operations or control centre, through a communications layer. In this thesis,however, 10 2.3. Discrete Event Simulation the role of an operations centre is played by the user of the I2Sim toolbox. The ad- justments and decisions by the operations centre or user may be incorporated in other possible scenarios for additional simulations. This thesis focusses on the I2Sim toolbox development and the simulation of study areas with different scenarios. 2.3 Discrete Event Simulation The cells and channels in a I2Sim system creats a discrete event-driven system. That is, the system condition can be dynamically changed through discrete time or events. As a result, it shows non-deterministic behaviors. In a discrete event-driven system, an event can cause one or more state changes in the components while a combination of events can also cause one or more state changes in the system. There are three types of discrete events that affect the I2Sim system in this thesis: the uncontrollable event, the time-dependent event, and the decision-making event. 2.3.1 Uncontrollable Event The uncontrollable event is an unexpected event that can change the internal variables of the system such as a cell and channel functionality. In I2Sim, the physical modes for cells and channels can change with an uncontrollable event. The concept of physical modes will be discussed in details in the next chapter. The effect of events to the system will vary depending on the diaster type itself and the time of the disaster. For example, the power system failure during a winter nighttime would have different effects on the system from the one during a summer daytime. The examples of uncontrollable events could be an operation failure of the system or a natural disaster such as a tsunami. In the thesis, an earthquake and a snow storm have been used as uncontrollable events. 2.3.2 Time-dependent Event The time-dependent event is a scheduled event that will happen to a cell or a channel after a period of time when it is in a specific state. Other entities that are connected to the cell or the channel of the event may be affected but the whole system will not be affected. However, the effect can be spread out to the later layer of the connected entity. An example of a time-dependent event trigger can be the run-time of internal 11 2.4. UBC Campus and Vancouver 2010 Winter Olympics back-up resources such as an oil and water tank. One of the examples from the test case in the thesis is diesel water pump in the water station. When the diesel runs out after the run-time of the tank, the water station can no longer supply water to the hospitals which may interrupt the treatment of the patients in the hospitals. 2.3.3 Decision-making Event The decision-making event is triggered by the human decisions after the analysis of the current system condition. During disasters, the effective prioritization of the re- pairs, restorations, and the resource allocations can increase the probability of human survival significantly, which are examples of decision-making events. In I2Sim, it is described as an operating and physical mode changes in the distributors, the cells, and the channels, which are the actions taken by the I2Sim operating centre. A decision making action on one cell may affect other cells in the system either positively or neg- atively. For example, both hospitals and roads are damaged due to an earthquake. If the repair crews are sent to the hospitals first, it will increase the number of treatable patients at the hospital. However, it may delay the transportation of the patients from the diaster sites to the hospitals since the bridge is not fixed. As a result, it is very critical to analyze the situation accurately since decision-making events can affect a wide variety of cells and channels in different ways. As mentioned above, I2Sim helps saving time for decision-making processes to save more human lives. 2.4 UBC Campus and Vancouver 2010 Winter Olympics I2Sim model is implemented and tested in two area settings: the UBC Campus and the Downtown Vancouver. The brief descriptions of the test cases are written below. The detailed test results will be discussed in Chapter 5. 2.4.1 UBC Campus Test Case The UBC Campus is a well-qualified study space for the first demonstration site be- cause of its unique characteristic as a municipality independent of City of Vancouver. In relatively small area of 2000 acres, it contains all the critical sectors defined by Public Safety Canada. Also, the UBC Campus displays infrastructure complexity and popula- tion diversity that are difficult to find in other communities. The UBC Campus case has 12 2.4. UBC Campus and Vancouver 2010 Winter Olympics nineteen cell types that classifies the critical infrastructures and buildings on campus as below: • Hospital • Fire Hall • Ambulance Service • RCMP • Classroom and Library • Research Lab and Museum • Residential • Parking Lots • Recreation and Society • Substation • Water Station • Telecom Generator • Transportation • Food Services • Commercial • Administrator • Services and Utility • Power House • Steam Station. Out of these nineteen cell types, I have implemented a system using the five critical types of cells with the I2Sim toolbox, which will be introduced in Chapter5. 2.4.2 Vancouver 2010 Winter Olympics After successfully implementing the reduced UBC Campus test case, I2Sim group signed a contract with V2010 Olympics committee to build a case for olympic venues, hospitals and critical infrastructures in Downtown Vancouver. The buildings designed for the olympic case in this thesis are as below: • BC Place • GM Place • Cathedral Square Substation • Dal Grauer Substation • Sperling Substation 13 2.4. UBC Campus and Vancouver 2010 Winter Olympics • Murrin Substation • Water Station • Vancouver General Hospital • St. Paul’s Hospital Out of the buildings above, I designed BC Place, GM Place, the water station, and two hospitals. The buildings above has the same types of cells that has been imple- mented in the UBC Campus case except for BC Place and GM Place. They are classified as a Recreation and Society among the 19 cell types of I2Sim, but in Olympics scenario, I defined them to behave as evacuation centres. For this type of cells, the human flow is very critical. The detailed design of BC Place and GM Place cells will be discussed in Chapter 5. 14 Chapter 3 Human Readable Table (HRT) 3.1 Human Readable Table Human Readable Table (HRT) is a table containing the relationship between inputs and outputs of a system. Unlike the previous HRT by Liu [18], a new concept of econ- omy has been adopted to build the new I2Sim HRTs. For a factory to produce a cer- tain amount of outputs, it requires a combination of different inputs such as materials, labors, and capitals. That is, increasing one of the inputs alone with other inputs fixed would not increase the output after it reaches a certain limit. In fact, having to many workers in the area may even lowers the production rate. In economy, this concept is called the law of diminishing marginal returns. I applied this concept in the new HRTs built in this thesis. This is a significant improvement from the previous HRTs developed by Liu [18]. Liu’s tables try to identify all potential combinations of the inputs and the outputs us- ing an interpolation technique. As a result, a size of the table increases exponentially as the number of inputs increases, which makes it difficult to build and understand the tables. However, the new HRT introduced here simplifies the construction process of HRT by identifying only the actual output levels at which a cell can produce. For example, a water pumping station with two water pumps would have only three pos- sible output levels depending on the number of functional pumps: 100%, 50%, and 0% of the full capacity. The interpolation between these output levels would not be necessary since the station will not be able to operate at those levels. Each row of the new HRT contains the threshold values of the inputs required to produce those output levels. The principal behind the use of threshold values in HRTs is adopted from the law of diminishing marginal returns as mentioned above. No matter how much water a water pumping station has, it would not be able to produce above 50% output if even one of other inputs such as electricity is limited to 50%. As a result, the HRT for water pumping station above would be simplified into only three rows. 15 3.1. Human Readable Table Water Station Output Input High-pressured Water Electricity Low-pressured Water (m3/hr) (MW) (m3/hr) 103 0.011 103 77 0.008 77 51 0.005 51 26 0.003 26 0 0 0 Table 3.1: Production Human Readable Table Another major improvement made in the new Human Readable Table is the phys- ical mode and the resource mode which will be discussed in detail in section 3.2. 3.1.1 Types of Human Readable Tables Even though the core concept of the Human Readable Tables is the same, the formats of the HRTs used for the different components of the I2Sim are quite different. To make it clear to understand, I categorized them into three major types: production HRTs, channel HRTs, and distribution HRTs. The production HRT is used for the cell units. It represents the relationship between multiple inputs and a single output of a cell as shown in table: 3.1, which is an example of water station production unit. The physical damages to the cell are portrayed by the number of physical modes corresponding to different HRTs, which will be explained in detail in the next section. The channel HRT represents the lifelines and roads with a traveling time delay, a capacity, and a gain factor (which is less than or equal to one) of the channel as shown in table: 3.2, which is an example of a people channel. The channels in I2Sim have the same type of an input and a output. Also, unlike cell’s production unit, the output of a channel does not have discrete threshold levels. Instead, it is calculated using the variable transport delay function with the amount of the input and the gain specified, which will be discussed in detail in chapter 4. As a result, the input and the output are not in part of the channel HRT. In the channel HRT, each row of the table is treated as an operating mode since each row is a unique condition caused by different events. The third type of HRT is the distribution HRT. A distributor in I2Sim takes this HRT 16 3.1. Human Readable Table People channel Gain Delay Capacity (ratio) (hours) (people) 1 0.5 100 1 1 100 1 2 100 0.9 1.5 80 0.9 2 80 0.75 1.5 50 0.5 1.5 50 0.25 2 25 0 0 0 Table 3.2: Channel Human Readable Table Water Station Distributor Total Water Hospital Residence (m3/hr) (ratio) (ratio) 103 0.5 0.5 77 0.34 0.66 51 0.01 0.99 0 0 0 Table 3.3: Distributor Human Readable Table to find the ratio of how the output from a cell or a channel is distributed to different places. Opposite to the production HRT, the distribution HRT has a single input with multiple outputs. While the production HRT contains actual physical units of inputs and outputs, only the input column of the distribution HRT has a physical unit. The output columns of the distribution HRT is in ratios rather than a physical units, and the sum of output ratios for each row must be equal to one. In this way, there will not be any calculation loss from distributors. In addition, the distribution HRT has the operating modes instead of the physical modes since the switches to different HRTs is made by the distribution policy changes instead of a physical damage. An example of the distribution HRT is shown in table: 3.3, which is an example of a water distribution from a water station. 17 3.2. Physical Mode (PM) and Resource Mode (RM) 3.2 Physical Mode (PM) and Resource Mode (RM) In the new I2Sim, the operating state of a cell and a channel is defined by two means: a physical mode (PM) and a resource mode (RM). The physical mode reflects the physi- cal state of a cell while the resource mode represents the actual operating output level determined by the available inputs to the cell. These two modes combined together produce a final operating state of a cell. In a regular operating condition, a cell most likely has 100% physical functionality. That is, the buildings is not suffering any structural damages or equipment failures, so they can work in their full capacity as long as the input resources are available. However, when an event like an earthquake occurs, the physical mode of the cell may change. For example, if the half of the transformers in a substation is broken due to shaking from an earthquake, the physical functionality of the substation will be only 50% of its full functionality. In this case, the cell that represents the substation goes into the physical mode with a different HRT. The maximum RM level is limited by the current PM of the cell. That is, when the physical functionality of a cell is only 50%, the highest output level the cell can produce, the maximum RM level, will be only 50% no matter how much resources are available from the outside. For example, even though a hospital has enough staffs and resources to perform four surgeries, if only two surgical rooms are available, the maximum surgeries that can be done is only two. Each PM is assigned to a Human Readable Table (HRT), so a cell has multiple HRTs eqault to the number of the PMs it has. In the HRT, each row becomes one of the RMs for that specific PM. The detail of how this is done is shown in figure 3.1. In figure 3.1, it shows an example of a hospital cell in percentiles for easier un- derstanding of the PM and RM concept. There are four PMs according to physical operability of the hospital, and each PM is pointed to a table consists of RMs. For instance, PM02 in the figure has the HRT with three RMs, and the maximum patient level is 66% since PM02 represents the physical operability of 66%. Prior to the simulation, a specific PM is predicted by the damage assessment data. The damage assessment gives a data such that after an earthquake with intensity VIII, the hospital will be 66% functional. 18 3.3. Color Scheme  	  

                         	  

       
     !! !! !! !! !!          !!         "   	  

                   	  

            #	  $ % & &!! & "& #	  #	  #	  Figure 3.1: Physical Mode and Resource Mode 3.3 Color Scheme The physical mode (PM) and the resource mode (RM) mentioned above are repre- sented inside the I2Sim Cell and Channel blocks through a color scheme for the visual- ization purpose. The color scheme used contains five color levels shown in figure 3.2, which is used by Color-coded Threat Level System of U.S. Department of Homeland Security (DHS). Each color is assigned to a range of the nominal output levels or the unit function- ality as listed below. • Green: 85-100% • Blue: 70-84% • Yellow: 45-69% • Orange: 26-44% • Red: 0-25% 19 3.3. Color Scheme Figure 3.2: Color Scheme Figure 3.3: PM RM Color Representation in a Block A unit in a normal condition would be in green and precede down to red as the unit is damaged and becomes no longer functional. In a I2Sim block, I programmed the mask of the block with a small rectangle on the top left corner showing the PM with its color level, and the rest of the block with the color representing the output color level of RM as shown in figure 3.3. To maximize the speed of the Simulink/MATLAB simulation, I designed the colors of the blocks to be checked for an update only where there is a change in the output level of the block instead of every loop. The figure 3.3 is an example of cells in a green physical mode with different colored resource modes. The color representations of PM and RM help the users to capture the system condition and respond faster during the simulations or the disasters. 20 3.4. Construction of a Model 3.4 Construction of a Model This section describes the construction process that I took to build the I2Sim virtual models from the physical area of interest. The process consists of researching and in- terviewing for information gathering, filling the Human Readable Tables, and building a virtual model using the I2Sim toolbox. 3.4.1 Information Gathering Prior to building a HRT, it is very important to identify the information that is needed to build the HRT. This may be one of the most difficult steps in the construction of the model since it involves the interviews with the infrastructure stakeholders about the confidential information on the operation of the system. As a result, I found that it is very essential to determine the minimum data required by every unit of the virtual model to build the HRTs. Through the experience I had from the interviews with UBC Power House personnel, VANOC, and Vancouver health care, I observed at least the following data has to be acquired before building any virtual systems: • The type and the amount of the output produced by the unit • The types and the amount of the inputs used to produce the output • The number of the different lifelines and the roads that carry the inputs and the outputs of the building • The capacity and the traveling time of the channels • The basic internal configurations that can help define the different physical modes at which a unit can operate • The internal reserves or the back-up sources and their capacity • The resources required to run the internal back-up sources Depending on the nature of the unit, each unit requires additional information to create an accurate model. Information gathering was the most time-consuming and difficult part of the model construction. Another technique that I learned to receive the better cooperations from the infrastructure stakeholders is presenting how I2Sim can benefit them in return of their help before the actual interview. Once all the required 21 3.4. Construction of a Model information is collected, HRTs has to be built for the various components of the cell which will be discussed in the next section. 3.4.2 Building Human Readable Table The list of information gathered was used to create the production, distribution and channel HRTs. First, the different physical modes of the cell production HRTs were determined using the internal configurations of the cell. For example, when a substation has two transformers, three physical modes can be used: both transformers functional, one transformer functional, and no transformers functional. For each PM, the HRT is built using the types and the amount of the inputs and the output. With the full capacity being the first row, the discrete threshold levels which become the rest of the rows of HRT can be determined according to the internal configurations as well. The output produced from the cells may be distributed to the other cells through the different channels. The distribution HRT lists the ratio at which the output is dis- tributed. The ratio could be either given by the infrastructure stakeholders or calcu- lated by the number of the channels that carry the output and the capacity of the chan- nels. The distribution ratio of the resources in case of emergency must be different from when in the normal condition. For example, in a normal condition, a substation is able to distribute the electricity as needed by all customers such as hospitals and residences. However, in emergency, when the electricity is scarce, the substation may go into an operating mode where the hospitals become the first priority, which would change the ratio of distribution. The third step would be building the HRTs for channels that are connected to the cell. The channel HRT is consisted of the different combinations of the traveling time delay, the capacity, and the gain of the channel, which is less than or equal to one. The time delay and the gain in the normal condition become the first row of the HRT. The time delay and the gain may vary depending on what flows in the channel. For example, a traffic channel with cars may have a large time delay such as one hour with no loss while a electricity channel has no time delay with small loss in the transmission lines. The capacity of the channel may change due to the damages to the physical channel. One of the factors that helped me building more realistic channel HRTs were the damage assessment from Juarez [14]. Juarez calculated possible immediate and progressive states at which channels can fall into during the earthquakes with different 22 3.4. Construction of a Model intensities. 3.4.3 Designing Cells using I2Sim Toolbox Figure 3.4: Generic Cell Design After the Human Readable Tables for each component of all the cells in a desired system are built, the connectivity of components has to be designed. Each cell has the following generic components: aggregators, internal reserves, a production unit, and distributors. The same type of inputs entering a cell through different channels or internal reserves should be added up using an aggregator before the production unit. When the output of the production unit is distributed to more than one places, a distributor should be added to divide the output. One cell should be connected to other cells using the channels. An example of a generic one-cell design is shown in figure 3.4. After the design is done, the system can be built using the components in the I2Sim Toolbox. The functionalities and the interfaces of the I2Sim Toolbox components in Simulink will be discussed in detail in the next chapter. 23 Chapter 4 I2Sim Toolbox Figure 4.1: I2Sim Toolbox in Simulink 24 4.1. Development of Customized Blocks I2Sim Toolbox in Simulink is a library containing the customized blocks of the com- ponents which are created based on the I2Sim concept introduced earlier in this the- sis. Once the library is installed on a computer, the toolbox will show up from the Simulink library browser along with other toolboxes that originally come with MAT- LAB/Simulink software as shown in figure 4.1. To simplify the installation process of the toolbox, I wrote a MATALB script that can be run and automatically installs or updates the toolbox. 4.1 Development of Customized Blocks The component blocks used in I2Sim are created through a subsystem containing a combination of pre-existing Simulink blocks and customized system-function(s-function) blocks. The most challenging part of the development process was programming the s-function blocks in the m-file. To create a s-function block, all characteristics such as quantities, types, and dimensions of inputs, outputs, and parameters, the initial state of the block, and the outlook of the block have to be all programmed in a single m-file along with its functional algorithm as shown in Appendix A. As a result, the s-function blocks allow the higher flexibility compared to the other customized blocks such as an embedded MATLAB function block. Another reason s-function blocks were chosen is due to its compatibility with the toolbox libraries. Other customized blocks cannot have more than one instances in one system once it is added to the toolbox library. Since Matlab/Simulink is not commonly used for the customized blocks, I had a diffi- cult time realizing these limitations of different customized blocks. The details about how each customized components are built will be discussed in the next section. 4.2 I2Sim Components There are seven functional components in I2Sim Toolbox as followings: an aggregator, a HRT, a storage, a distributor, a channel, a source, and a sink. Their functionality and implementation using MATLAB/Simulink will be discussed in detail in this section. In addition to these components, the toolbox has a I2Sim control panel, a I2Sim visu- alization panel, and a probe for visualization purposes which were developed by my colleague, Tomim. As a result, they will not be discussed in this thesis. 25 4.2. I2Sim Components 4.2.1 Aggregator Figure 4.2: Aggregator Block The functionality of the aggregator block is producing an output which is the sum- mation of all inputs into the block. It is used when a same type of resources reaches a cell through multiple routes. For example, when the electricity to a hospital can come from an external substation, an internal back-up generator or both, the aggregator adds the electricity from both sources and inputs it into the HRT block as one input. To be able to change the number of input ports as a parameter of the aggregator, I built the aggregator using a s-function block instead of a pre-existing summation block from the Simulink. The MATLAB code used for the aggregator can be found in Appendix A. The figure 4.2 is the aggregator block on the left and the user interface on the right. The aggregator block needs the number of inputs specified on the user interface beforehand to change the number of input ports accordingly for the block. 4.2.2 Human Readable Table (HRT) The Human Readable Table block represents the core production unit for the cell. It takes the values from the input ports and searches for the matching entries in the pro- duction HRT; and it produces the corresponding threshold output value found. As a result, it requires a pre-defined production HRT to operate. I designed the HRT block with three parameters to be specified in the user inter- face as shown in figure 4.3: the name of a HRT, a physical mode (PM) setting, and a physical mode. The HRT name is the name of the production HRT variable, which has 26 4.2. I2Sim Components Figure 4.3: Human Readable Table Block to be created in MATLAB. I chose the struct as the standard variable format for the HRTs in I2Sim, since it has the flexibility of storing different types of variables under one struct. For example, the HRT structs used for the test cases in this thesis contain the input/output names, units, and maximums along with description for the HRT. This makes the Human Readable Tables more readable. The physical mode setting is used to set whether the PM is determined internally through the interface parameter or externally as an extra input to the block. Only when PM is set internal, the third parameter, the physical mode, is used to set which physical mode the cell is under. In addition, the HRT being used by the block can be viewed by clicking on the checkbox beside View-HRT, which was implemented by my colleague, Tomim. By Dr. Marti’s request, I added the feature of a checkbox for Pause-when-there-is-a-change. It enables the simulation to pause whenever there is a change in the state of the production HRT such as the output levels and the PMs, so the users can monitor the situation in depth. The HRT block automatically creates the number of the input ports according to the production HRT entered in the user interface. In addition to these ports, the port for the physical mode is created below the input ports when the PM setting is external. As 27 4.2. I2Sim Components mentioned in chapter 3, there are two colors shown in the block: a physical mode color for the small square and an actual output level color for rest of the block. Also, inside the small square, the current physical mode number is shown as in figure 4.3. In this particular example in figure 4.3, HRT block is in the physical mode yellow, which is 45- 69% functional, but the actual output level is red, which is 0-25% of its rated capacity, due to lack of resources. The rated output capacity of the cell at its normal condition is also shown on the right top corner of the block. One of the features of the HRT block that helps users to assess the situation faster is the NEED display on the right bottom corner. It shows the input resource that is needed to increase the output level. In figure 4.3, the input resource needed is electricity. All these display and color features along with the input and PM ports are controlled by a single s-function file that also contains the functional codes of the HRT block. The reason I chose this method is to keep the synchronization of all the changes on the block. The detailed codes of the HRT block can be found in Appendix B. The search algorithm implemented in the s-function code in HRT block is as above. It searches for the maximum possible output level that can be produced with the given input amounts. This algorithm works for only the tables with a descending order of entries in the rows. Data: input vector x̂ Result: output y r = 1 % start at the first row; for ix = 1,...,nx do % iterate over each input variable; for i = r,...,nrow do % iterate over each row; if HRT(r, ix+1) ≤ x(ix) then break for-loop; % go to next input variable; else r = r + 1; % go to next row; end end ix = ix + 1; end y = HRT(r, 1); Algorithm 4.1: Human Readable Table Search Algorithm 28 4.2. I2Sim Components 4.2.3 Distributor Substation 60MW Available Hospital 60MW needed 100L/hour needed Water Station 40MW needed 60MW 0MW Electricity Channel Water Channel 0L/hour 0% of patients healed (a) Bad Distribution of Resource Substation 60MW Available Hospital 60MW needed 100L/hour needed Water Station 40MW needed 40MW 20MW Electricity Channel Water Channel 50L/hour 70% of patients treated (b) Good Distribution of Resource Figure 4.4: Distribution Example The distributor is used when a single type of resources is distributed to multiple units. The distributor is an important decision making control point in I2Sim. When the resources are scarce, it is very critical for the emergency responders to make a decision on how to distribute the resources among the infrastructures to save most human lives. The figure 4.4 below shows an example of good and bad distributions. In a normal condition, the substation in the example is assumed to supply the full electrical need of both hospital and water station, which is 100MW. However, as shown in figure 4.4, only 60MW of the electricity is currently available from the substation due to an emergency. As a result, the appropriate distribution of the electricity becomes critical. In figure 4.4(a), when all available electricity is sent to the hospital to save human lives, the hospital still cannot treat the patients since they cannot receive any water from the water station. The smarter choice in this case would be sending some of the electricity to the water station as in figure 4.4(b). However, it is still difficult to manually predict the ideal distribution ratio of electricity that would maximize the number of treated patients. Using the I2Sim distributor, the emergency responders can more accurately predict the consequences of choosing different distribution ratio at different decision points. For a more flexible application, I designed the I2Sim distributor block to be able to choose the ratio either by a distribution HRT (automatic) or by the values from the user interface (manual). The user interface for the distributor block was built by my colleague, Tomim. If the manual checkbox is checked as in figure 4.5, the distributor 29 4.2. I2Sim Components Figure 4.5: Distributor Block divides the input according to the number of outputs and the ratio entered manually by the user. The ratio can be entered using the scroll bar or the numbers. The sum of the ratio entered has to add up to 100%. The compute button calculates the ratio for the selected output by subtracting the rest of the entered ratio from 100%. When the manual checkbox is unchecked, the distributor block uses a pre-defined Human Readable Table to find the ratio. In this case, the number of output ports of the block will automatically change according to the outputs from the HRT. 30 4.2. I2Sim Components The distributor HRT may have multiple operating modes (OM) as discussed in chapter 3. The OM for the distributor can be determined either internally or externally as in the PM for the HRT block in the previous section. When the OM is externally set, the distributor block has an extra OM port in addition to an input port and a number of output ports. I built the distributor block with a customized s-function code block. The search algorithm implemented in the s-function code is as below. It searches for the closest input level to the given input amount and read the corresponding ratio to be used. The given input amount is multiplied by the ratio found and outputted into each output port. The detailed codes for the distributor can be found in Appendix C. Data: input x Result: output vector ŷ % initialization; deltax = | HRT(1,1) - x |; tempr = 1; for r = 2,...,nrow do % iterate over each row; if | HRT(r,1) - x | < deltax then % save the location of the closest input; tempr = r; deltax=|HRT(r,1)-x|; else % do nothing; end r = r + 1; end for c = 2,...,ncol do % iterate over each output ratio; y(c-1) = HRT(tempr,c) * x; i = i + 1; end Algorithm 4.2: Distributor Search Algorithm 4.2.4 Channel The I2Sim channel is an entity where a token flows from one unit to another. Unlike a cell, the channel does not change the nature of the input token; however, there may be 31 4.2. I2Sim Components (a) External View (b) Inside the Mask (c) Interface Figure 4.6: Channel Block 32 4.2. I2Sim Components losses or a time delay between the input token and the output token as mentioned in chapter 2. In the I2Sim channel, the time delay and the losses are found from a pre-built chan- nel HRT, where each row is a pre-defined physical mode. The channel block contains a combination of a s-function block and the pre-existing Simulink blocks. The time delay in the channel is apply to the input token through the variable transport delay Simulink block, and the output from the block is multiplied by the loss factor before exiting the channel as shown in figure 4.6(b). I designed the physical mode to choose the loss factor and the time delay produced from the s-function block. The detailed s-function codes can be found in Appendix D. The channel block is masked as a block colored according to the current loss factor. It also shows the physical mode and the token type as in figure 4.6(a). In the figure, it shows a steam pipe that is severely damaged. Similar to the other blocks discussed earlier in the chapter, the channel block takes the name of the channel HRT as a parameter in the user interface, and the physical mode can be either an external input or an internal parameter as shown in figure 4.6(c). The variable transportation delay uses the following concept to accurately calculate the total time delay throughout the channel when the time delay on the channel varies with time [31]. With fixed length of channel, L, the propagation speed of the token at time t would be as below: v(t) = L τ(t) (4.1) When equation 4.1 is applied to a infinitesimal fragment of a length, the equation becomes as below: v(t) = ∆L ∆t ⇒ ∆L = v(t)×∆t (4.2) When the integral of equation 4.2 is taken from time t to td(t), it becomes:∫ L 0 dl = ∫ t t−td(t) v(t)dt⇒ L = ∫ t t−td(t) L τ(t) dt (4.3) When equation 4.3 is simplified, it becomes as below, which is used in the Simulink block to solve for the total time delay throughout the channel by calculating td(t) at 33 4.2. I2Sim Components every time step. 1 = ∫ t t−td(t) 1 τ(t) dt (4.4) 4.2.5 Storage In I2Sim, the storage is used to represent a point at which a token is accumulated and flows out at a desired rate. The most straightforward use of storage is as an internal back-up source storage such as an oil and water tank. However, that is not the only way to use the storage block. I used the storage block as a waiting area for people out- side of each cell during the disaster in the test cases in chapter 6. When it is combined with a channel, it can also be a part of a cell with people as an input and an output such as hospitals and stadiums. People are contained in the storages waiting for the treatments or watching a show and released after a certain time delay which can be depicted by a channel with possibly zero loss factor. Also, the rate at which people are released can be determined by a HRT block with the physical modes determined by the number of professional personnel and resources to facilitate the function of the cells. This concept is implemented in the Vancouver 2010 Winter Olympics cases which would be discussed in more details in chapter 6. The I2Sim storage block is consist of pre-existing Simulink blocks without any s- function block. The storage has a single input and a single output. In addition, the command for the output is added as an extra input to be able to vary the flow rates over time as shown in figure 4.7(a). Also, the current level of the storage is produced as an additional output. The maximum and minimum command signals are specified as the parameters of the block along with the maximum, minimum and initial levels of the storage on the user interface as shown in figure 4.7(c). A storage unit can store the input resource up to the maximum capacity and gives out the output resource at a desired flow rate until the minimum level of the tank is reached. The flow rate may either be given by the infrastructure stakeholders or be calculated from the time that the storage can supply the cell and the capacity of the storage. The concept behind the storage was designed by my colleague, Tomim, and it will be discussed below. As shown in figure 4.7(b), the storage outputs the resource according to the com- mand signal as long as the level of the storage is above the minimum level limit. Also, the command signal is checked for its boundary limit set by the parameters in the in- 34 4.2. I2Sim Components (a) External View (b) Inside the Mask (c) Interface Figure 4.7: Storage Block 35 4.2. I2Sim Components terface. When the minimum level limit of storage is reached, the storage outputs zero amount of resources regardless of the command signal. The current level of storage is determined by the integration between the current input and output along with the initial level as described in the equation 4.5 [31]. level =  lmax level ≥ lmax level0 + ∫ t 0 (xin − xcmd)dt lmin < level < lmax lmin level ≤ lmin (4.5) 4.2.6 Source A source represents the resources coming from the outside into the defined system. I designed the source block to have an unlimited capacity of resources, but it can only output resources at a certain rate defined by the owner of the physical source. The size of source can vary from a small local water station to a large water reservoir for a district. Every resource that is used by the cells in a system has to either come from a source or be produced within the system. In I2Sim, the source block is a simple block with no input and one output system as shown in figure 4.8. The output of the source is determined by the parameter, source value, entered in the user interface. Figure 4.8: Source Block 36 4.2. I2Sim Components 4.2.7 Sink Figure 4.9: Sink Block A sink represents a point at which the resources exit the defined system. The re- sources entering the sink are no longer used by any of the components in the system. They may be passed onto another defined system as a source. In addition, the value of the resources may be plotted or stored before entering the sink since some of them may be the total output goal of the system. For example, for the purpose of I2Sim project, the goal of the project is maximizing the human survival, which is the number of people treated from the hospital. However, people exiting from the hospital is not used by the system anymore, so it is sent to the sink. Since monitoring and improving the number of people survived is the goal of the system operation, the signal may be plotted before it enters the sink. Once resources enter the sink, they are terminated since it has no preservation value to the system. In I2Sim, I designed the source block to be a block with only an input port and no output or parameters as in figure 4.9. 37 Chapter 5 Simulations and Results As an implementation of the I2Sim toolbox discussed in chapter 4, I re-created one of the scenario cases which were developed on the University of British Columbia (UBC) campus by Liu [18] and compared the results with the previous I2Sim model. Also, a test case has been developed for the Vancouver 2010 Winter Olympics as a part of the V2010 project led by Dr. Marti at UBC. 5.1 UBC Campus Case In Liu’s thesis, she simulated a reduced test case for the UBC campus with the five infrastructures: the substation, the powerhouse, the water station, the steam station, and the hospitals. To compare the performance of the new I2Sim model and toolbox with Liu’s model and simulator, I re-built the same test case scenario with one of Liu’s scenarios. In addition to the original case, I also developed another case with the same scenario but with the people’s flows and the distribution decision making points. This features allowed the model to produce more realistic results. The simulated scenario depicts the power outage happened during the snowstorm at the UBC on November 27, 2006. During the snowstorm, the heavy snow caused the tree branches to fall down on two of the major transmission lines coming into the UBC campus [3]. As a result, the power was out for all parts of the UBC campus including the student residences for about twelve hours. Liu also added an additional event of the water pipe brokage to the real situation to demonstrate a multiple disaster situation [18]. 38 5.1. U BC C am pus C ase UBC Water Station Electricity Source BC Hydro Substation Electricity Channel Substation Cell Power House Cell Electricity Channel Water Station Cell Steam Station Cell Water Source GVRD Water Channel UBC Substation UBC Power House Back-up Oil Tank Back-up Generator Gas Source Terasen Gas Gas Channel UBC Steam Station Purdy Hospital Cell (Long-term Patients) Koerner Hospital Cell (Short-term Patients) Water Channel Steam Channel Electricity Channel Electricity Channel Back-up Water Tank Back-up Water Tank Back-up Generator Back-up Generator Gas Channel Medicine & Personnel Source Treated Short-term Patients Sink Treated Long-term Patients Sink UBC Hospital Electricity Water Gas Steam Returned Steam Source Steam Channel Figure 5.1: Design of Reduced UBC Campus Test Case 39 5.1. U BC C am pus C ase Figure 5.2: Simulation of Reduced UBC Campus Test Case 40 5.1. UBC Campus Case Liu’s model has been modified according to the new concept introduced in this thesis as shown in figure 5.1. I divided the hospital cell into two different cells for the long term and short term patients since the new I2Sim cell is one output only unit. In addition, these two cells are separated into two hospital buildings in real. The model has been simplified significantly since it no longer requires the internal configuration of the cells, but it still produces accurate results using the physical modes and the threshold levels. It makes the process of developing the case and collecting the infor- mation from the infrastructure stakeholders much easier. Previously, the user had to become an expert on the Simulink program since the test case was hard-coded. As a result, it is difficult to modify the case to add new cells without fully understanding the I2Sim model. However, with the new I2Sim toolbox, the user needs only the basic knowledge on the toolbox and can still create an accurate case through the publicly available information on the infrastructures. A comparison between the models and the HRTs of Liu’s substation and the new substation is shown in figure 5.3. The model presented in this thesis has significantly fewer components as compared to the earlier model proposed by Liu. For example, the new HRT for a substation comprises three tables, with less than six rows per table. 5.1.1 Scenario 2 of Liu’s Thesis The scenario contains the sequential events listed below: • Initial State (t < 0): All cells and channels are functional. • t = 20 min: – The electrical channel from the outside to the UBC substation goes to 0% functional due to the fallen tree branches caused by snow. – The back-up generator for the steam station starts to warm up but is not started yet. – The diesel back-up pump in the water station starts right away. • t = 40 min: – The water pipe from the water station to the hospitals breaks, so the func- tionality of the water channel goes to 0%. – The water from the hospitals’ back-up water tank starts being used. 41 5.1. UBC Campus Case (a) Liu’s Substation Model [18] (b) Liu’s Substation HRT [18] (c) New Substation Model PM01 PM02 PM03 output input output input output input electricity electricity electricity electricity electricity electricity MW MW MW MW MW MW 22800 22800 11400 11400 0 0 18240 18240 9120 9120 13680 13680 6840 6840 9120 9120 4560 4560 4560 4560 2280 2280 0 0 0 0 (d) New Substation HRT Figure 5.3: Substation Comparison • t = 50 min: The back-up generator in the steam station starts providing power. • t = 14 hr: The transmission lines are restored, and the functionality of the electri- cal channel from the source to the substation becomes 100%. • t = 24 hr: The water channel is fully restored. Twenty minutes after the initial state, the transmission lines to the UBC substation is down. As a result, the electrical channel in the model goes to functionality of 0%. Even though the substation is in the physical mode 01 with no damage to the building, it cannot deliver any power to the other cells as in figure 5.4, since there is no input to the system. In the previous model, it was difficult to identify whether failure to produce the output was due to a physical damage to the building or lack of input 42 5.1. UBC Campus Case resources. As mentioned in chapter 3 section chapter 3, the new I2Sim toolbox shows the levels of the physical mode and the resource mode in colors within the cell during the simulation. For example, in the left top corner of figure 5.2, the substation has a green PM color and a red RM color to present that the output level for the substation is 0% due to lack of resources. (a) Electricity from Source to Substation (b) Electricity from Substation to PowerHouse (c) Electricity from Substation to Hospitals Figure 5.4: Substation Cell Results The powerhouse behaves similarly to the substation not being able to provide any power to the water station and the steam station. However, both water station and steam station quickly goes back to its normal state as soon as their back-up diesel pump and generator come up. As a result, the water supply to the hospitals is not disrupted since the diesel water pump was hot on standby. However, the steam supply to the hospitals is stopped for 30 minutes due to the back-up generator start-up time as shown in figure 5.5. 43 5.1. UBC Campus Case (a) Electricity from PowerHouse to Water Station and Steam Station (b) Steam from Steam Station to UBC Campus (c) Water from Water Station to UBC Campus Figure 5.5: Power House, Steam Station, Water Station Cell Results Even though the water station is producing water at the full capacity, no water is received by the hospitals starting from t = 40 minute to t = 24 hour. It is because the wa- ter channel from the water station to hospitals is broken. As a result, the amount of the water sent out from the water station to the hospitals does not affect the functionality of the hospitals anymore. In the next scenario, a re-distribution of the water from the water station will be discussed in details. The hospitals start using the internal back-up water tanks, so there is no interruption of services even without the water. In fact, the hospitals can survive for about three days without an external water or power supply. However, when the steam supply is interrupted for 30 minutes from t = 20minute, the treatments for the long-term patients are affected significantly since the Purdy hospital cannot self-supply steam as shown in figure 5.6. At t = 14 hour as the transmission lines are restored, the oil tank level for the diesel pump in the water station stops decreasing as shown in figure 5.7. 44 5.1. UBC Campus Case Figure 5.6: Hospital Cell Results Figure 5.7: Water Station Back-up Oil Tank Level From the simulation, it is found that the redundancy in the resource availability such as the back-up sources ensures the important infrastructures and hospitals on the UBC campus to function at the full capacity for more than twenty four hours without an external source. The results from the simulation closely follow the results from Liu’s scenario 2 [18]. It shows that the new model can produce the same results as the previous one with a significantly easier design and process. In the next scenario, the improvements in functionality of the new I2Sim model and the toolbox will be captured through the effects of the people’s flow and the dis- tribution control points to the simulation. 45 5.1. UBC Campus Case 5.1.2 Modified Version of the Scenario 2 of Liu’s Thesis This section describes a modified version of previous simulation above. 5.1.2.1 Model and Scenario Change In this modified version of the scenario above, the back up diesel pump in the water station can supply only 50% of its total capacity. As a result, the steam station and the hospitals cannot function fully due to lack of water. I moved the water pipe breakage from t = 40 minutes to t = 4 hours to see the effect of the breakage on the system more clearly. When the water pipe to the hospitals breaks, the water sent to the hospitals is lost in the channel. Thirty minutes after the pipe breakage, I decided to send all the water produced to the steam station instead of the hospitals to see the effect of a new distribution ratio. The distributor at the water station is switched to the third operating mode which to sending all the water to the steam station, so steam station produces steam at the full capacity. At this point, the hospitals starts using their back up water tanks. As seen in figure 5.10(a), when the water is directed correctly, it can increase the number of treated patients at the hospitals compared to the result from the original scenario. This increase demonstrates the importance of the decision making points. On top of the scenario modification, I also modified the structure of the hospital model to represent the output as the human flow instead of the total capacity of the hospital. The prediction of the human flow plays an important role in determining the appropriate resource allocation. For example, in power system, a transmission line to an area has a maximum power flow capacity. However, the actual power flow on the line is equivalent to the instantaneous demand not the maximum capacity. It would be waste to send all the generated power to the area at its maximum capacity when it is not actually needed. The rest of generated power can be directed to another area that needs power. In British Columbia, BC Hydro makes a large profit by redirecting and selling their unconsumed power to USA. The hospitals are usually the first priority for the resource allocation. However, when there are less than the full capacity of patients in the hospital, it would not make sense to send the amount of the resources that meets its full capacity. By implementing the patient flow into the hospital model, the instantaneous amount of the resources required by the hospitals can be determined. In the new model I designed, the out- puts of the hospital Human Readable Tables are modified to the number of treatable 46 5.1. UBC Campus Case Figure 5.8: Human Flow Model for Purdy Hospital patients per hour from the total capacity of the hospitals. As shown in figure 5.8, the output from the HRT unit is fed into a I2Sim storage unit as a command input. The number of patients entering the hospital is put into the storage unit as an input. The I2Sim storage unit accumulates these two numbers and calculates the actual number of patients treated per hour according to the following equations: Total patients = total paitents0 + entering patients− treated patients (5.1) Treated patients =  treatable patients total patients ≥ treatable patients total patients total patients < treatable patients (5.2) The channel after the storage output as shown in figure 5.8 is added to represent the average time taken to treat the patients. 5.1.2.2 Scenario and Results The modified version of the original scenario contains the sequential events as below: 47 5.1. UBC Campus Case • Initial State (t < 0): All cells and channels are 100% functional. The hospital beds are half full with patients. Twenty five short-term patients comes into Koerner hospital every hour while fifteen long-term patients are admitted to Purdy hos- pital every hour. • t = 20 min: – The electrical channel to the UBC substation from the outside goes to 0% functional due to the fallen tree branches caused by snow. – The back-up generator for the steam station starts to warm up but is not started yet. – The diesel back-up pump in the water station starts right away supplying only 50% of the full capacity. • t = 50 min: The back-up generator in the steam station starts providing power. • t = 4 hr: – The water pipe from the water station to the hospitals breaks, so the func- tionality of the water channel goes to 0%. – The water from the hospitals’ back-up water tank starts being consumed. • t = 4.5 hr: The operating mode of the distributor in the water station is changed. All water is sent to the steam station, and none is sent to the hospitals. • t = 14 hr: The transmission lines are restored, and the functionality of the electri- cal channel from the source to the substation becomes 100%. • t = 24 hr: The water channel is restored fully. As mentioned above, when the water station switches to its diesel back-up pump from the electrical pump at t = 20 minute, the water station can only supply 50% of the required water on the campus. As a result, the steam from steam station decreases to about 50% as shown in figure 5.9, and the treated patients from the hospitals drops down to less than 50% of its full capacity due to lack of water and steam as shown in figure 5.10(a). At this point, no decision-making action is taken to the system. As soon as the water pipe breaks, hospitals turn on their back-up water tank which would satisfy its full needs of water. However, it still cannot operate at its full capacity 48 5.1. UBC Campus Case (a) Water from Water Station to Hospitals (b) Water from Water Station to Steam Station (c) Steam from Steam Station to Hospitals Figure 5.9: Water Station and Steam Station Cell Outputs due to lack of steam. Thirty minutes after the water pipe to the hospitals breaks, the water station operator decided to send all its output to the steam station instead of distributing to both the steam station and the hospitals as shown in figure 5.9. As a result, the steam station can now produce steam at 100%. The hospitals can start treating patients at their full capacity again since they have 100% water and steam as shown in figure 5.10(a). The figure 5.10(b) shows the total number patients in the hospitals. Until t = 4.5 hour, the total number of the patients increases fast since the hospitals cannot treat the patients at their full capacity. At t = 4.5 hour, the total number of the patients at Koerner starts to decrease while the one at Purdy still increases. It is because twenty five patients enter Purdy every hour while the maximum treatable patients per hour at Purdy is only twenty. As a result, all the beds in Purdy fills up after t = 17 hour. In previous case, this problem was not shown through the simulation because it looked 49 5.1. UBC Campus Case (a) Hospital Patient per Hour (b) Hospital Total Number of Patients Figure 5.10: Hospital Cell Outputs at only the total number of beds that can be filled at the moment instead of the actual filled number of the beds. Knowing the hospitals cannot accept any more patients due to lack of beds even at the full capacity, the simulation can help the emergency responders to prepare for re-direction of the patients in advance. Through this case, the importance of resource distribution and human flow in the hospitals were explained. In the next section, I will present the case of V2010 Winter Olympics with a new type of cell as well as an implementation of the crowd behavior during the evacuation of a enclosed space. In addition, the physical damage to the cells will be implemented whereas in UBC Campus case, no physical damage to the cells was occurred. 50 5.1. U BC C am pus C ase Figure 5.11: Vancouver 2010 Winter Olympics Study Area 51 5.1. U BC C am pus C ase Figure 5.12: Vancouver 2010 Winter Olympics Simulink Model 52 5.2. Vancouver 2010 Winter Olympics Case 5.2 Vancouver 2010 Winter Olympics Case To demonstrate the feasibility of the new I2Sim model outside of the UBC Campus, a case on Vancouver 2010 Winter Olympics Venues and the critical buildings has been set up by the I2Sim group. In addition, the physical mode and the resource mode fea- tures are emphasized in the Olympics case. The case includes BC Place, GM Place, Vancouver General Hospital (VGH), St. Paul’s Hospital (SPH), a Water Station supply- ing hospitals, and four substation, Cathedral Square (CSQ), Dal Grauer (DGR), Murrin (MUR), and Sperling (SPG) supplying power to the buildings. A map of study area with the buildings except SPR substation is shown in figure 5.11. In addition, the vir- tual model developed with the I2Sim toolbox is shown in figure 5.12. The four cells on the left represents the substations which were built by Rostamirad while the two on the right are the hospitals. Two cells in the centre top represent the BC and GM Place, and the bottom one is the Water Station. Except for the substation cells, the informa- tion on all cells were collected by Mirza and Khouj while the cells and the HRTs were built by me. I also built the channels and put all the components together. 5.2.1 Crowd Behavior Figure 5.13: GM Place with Crowd Model As mentioned in the previous section, the new type of cells, the BC Place and the GM Place, are implemented in the V2010 Olympics case. In a normal condition, they would be classified as a recreation cell. However, during disaster such as an earth- quake in this case, I decoded it would act as a place filled with crowds evacuating. As a result, I designed a new cell model for the crowd behavior evacuating from the 53 5.2. Vancouver 2010 Winter Olympics Case enclosed space. Based on Shendarkar et al. [29]’s study, the number of the police on site, the number of the exits of the buildings, and the population are the factors that will affect the crowd evacuation time. Along with those three factors, I added the electricity for the lightings as an input for the BC Place and the GM Place in the Olympics case. The output of the cell would be the number of people evacuating per hour. As in the hospital model from the UBC Campus case, the HRTs for the venues produce the possible number of people evacuating per hour, and this number is fed into the storage unit which represents the total population inside the venues as shown in figure 5.13. Upon exiting the venues, I added a triage to discriminate the crowds into dead, injured, and healthy people. Since only the injured people are of interest to the hospitals for the purpose of this simulation, the dead and healthy people are sent to the sink exiting the system. I used another storage unit to represent the area where the injured people are sent to wait for the transportation of the hospitals. Unlike the UBC Campus case, the patients entering the hospitals changes with time according to the system conditions. The effect of this will be described in the next section. 5.2.2 Initial Conditions and Scenario The scenario for the Vancouver Olympics test case below was developed by the I2Sim group. The scenario starts at 5:11pm on Thursday, February 25, 2010, which is the 14th day of the Vancouver 2010 Winter Olympics. GM Place is hosting the Women’s Ice Hockey Final while BC Place is hosting Women’s Figure Skating Final. Both venues will be fully filled up with people. Since it is a weekday, the rush hour traffic in Down- town Vancouver and bridges connected to it will be high. Also, there will be a sun- set in 20 minutes, which would affect the demand of the electricity for the lightings. Including the spectators, the media, the residents, etc., the estimated population in Downtown Vancouver will be around 420,000 [14] [12]. The selected earthquake for the case will be of magnitude 7.3 occurred on the Van- couver Island. The intensity in Downtown Vancouver would be VI. The damage to the buildings will be light, and there will be casualties with light injuries. The scenario contains the sequential events as below: • Initial State (t < 0): 54 5.2. Vancouver 2010 Winter Olympics Case – MUR substation is down due to shaking, so its physical mode becomes red. – BC Place, GM Place, VGH, and SPH suffer light damages going into the physical mode of 50-75% – The electrical feeders from CSQ to GM Place break. – The roads from the Olympics Venues experience a traffic jam due to the traffic light outages. As a result, the people channel from the venues to the hospitals goes into the operating mode of two hour delay. – The water pipe from the water station to VGH is broken due to shaking on Cambie Bridge. – 120 people from BC Place and 38 people from GM Place are injured which is 0.2% of the total population in each venue. • t < 1 min: The emergency lights in BC and GM Place come on, so the venues become 30% functional. • t = 20 min: – The back-up generator in the water station comes on. – The back-up water pump and generator from VGH come on. – The back-up generator from SPH comes on. • t = 2 hr: – The electrical feeder to GM Place is fixed to 100%. – The delay in the people channel to the hospitals decrease to 1.5 hours by the traffic police. • t = 5 hr: The traffic returns to normal with only 1 hour delay from the venues to the hospitals. • t = 7 hr: The water station is restored fully. • t = 7.5 hr: The water pipe to VGH is restored, and the back-up water tank is turned off. • t = 8 hr: GM Place is fully repaired. 55 5.2. Vancouver 2010 Winter Olympics Case • t = 10 hr: St. Paul’s Hospital is fully restored. • t = 11 hr: Vancouver General Hospital is fully restored. 5.2.3 Results and Analysis (a) Electricity to BC Place (b) Electricity to GM Place (c) Electricity to St. Paul’s Hospital Figure 5.14: Electricity to BC Place, GM Place, and St Paul’s Hospital As shown in the figure 5.12, the DGR substation receives all its input electricity from the MUR substation. When MUR goes to the physical mode of red after the earthquake, DGR goes to 0% resource mode even though its physical mode is 100%. As a result, DGR cannot supply any power to the BC Place and St. Paul’s hospital as shown in figure 5.14(a) and 5.14(c). The MUR substation also supplies the water station and part of the GM place and VGH electricity. As a result, the water station cannot produce any water for the hospitals as shown in figure 5.15, and the hospitals 56 5.2. Vancouver 2010 Winter Olympics Case cannot treat any patients due to lack of water as shown in figure 5.17. VGH still receives some of its electricity from SPG, but its functionality is still 0% due to lack of water. Since the electrical channel from CSQ to the GM Place is broken, the GM Place cannot receive any electricity for two hours until the feeder is fixed as shown in figure 5.14(b). In addition, since the roads are experiencing two hour delay, no patients are arrived at either hospitals as shown in figure 5.17. (a) Water to Vancouver General Hospital (b) Water to St. Paul’s Hospital Figure 5.15: Water to Hospitals As soon as the emergency lights in the venues come on, the evacuation of crowd begins as shown in figure 5.16. However, the injured people cannot arrive at the hospitals until two hours later due to the traffic delay. When the back-up generator comes on at the water station at t = 20 minute, it can start supplying water at 50% of the full capacity, which is the maximum it can produce with its current physical mode. However, VGH still cannot receive water from the outside due to the water channel breakage, so it relies its water supply on the internal water tank. The water station distributor chooses the operating mode that directs all its output to SPH instead of VGH, so SPH receives 100% of water needed as shown in figure 5.15(b). In addition, VGH and SPH can start treating the patients since they receive electricity from their back-up generators. The main goal of the simulation is predicting the human flow from the Olympics 57 5.2. Vancouver 2010 Winter Olympics Case Venues to the hospitals and their survival during the disaster. Right after the earthquake, the injured people waiting outside of the venues to be transported to the hospitals increase rapidly due to traffic delay as shown in figure 5.16. As the traffic clears up at t = 2 hour and t = 5 hour, the number of people waiting in front of the GM Place and the BC Place starts decreasing. As shown in figure 5.16, the I2Sim simulation predicts that the evacuation will be completed at eight hours for the GM Place and twelve hours for the BC Place after the earthquake. These times reflect on the number of the patients in the hospitals’ waiting room. This consequence was not predicted during the scenario designing process. The direct output of a cell with given input resources can be obvious, but the effect of the output to the system can only be predicted through the simulation. It is one of advantages of the I2Sim simulation model. Using I2Sim, the user can observe the hidden interdependencies between the venues and other infrastructures that will help the decision making processes during the actual disaster. (a) Waiting Area of BC Place (b) Waiting Area of GM Place Figure 5.16: Waiting Area for Olympics Venues For the first two hours after the earthquake, there is no output from the hospitals since the patients from the venues are still on the road. At t = 2 hour, even though both 58 5.2. Vancouver 2010 Winter Olympics Case (a) Patients at Vancouver General Hospital (b) Patients at St. Paul’s Hospital Figure 5.17: Olympics Case Hospital Model Results hospitals start treating the patients, they cannot meet the full needs due to the physical damages to the buildings. As a result, the number of the patients in the waiting room continues to increase rapidly. At t = 7 hour, even if the water station is repaired, and SPH can receive 100% of water, SPH still cannot treat the patients at the 100% capacity due to the physical damages to the hospital building itself. As mentioned above, when the evacuation at the GM Place is completed eight hours after the earthquake, the patients arriving at the hospitals decrease, and the in- crease in the number of the patients in the waiting room slows down. Ten hours after the earthquake, SPH is fully restored, and it can treat the patients at the 100% capacity. As a result, it can match the number of the patients coming in and being treated, so 59 5.3. Simulation Conclusion the level of the waiting room patients stops increasing as shown in the figure 5.17(b). When the evacuation is completed at BC Place at t = 12 hour, the number of the patients in the SPH and VGH waiting rooms start decreasing. As shown from the figure 5.17, all patients in VGH and SPH are treated less than twenty hours after the earthquake. It is one possible case out of many scenarios which can be tested. With this result as a base case, the Olympics Committee can try different decisions on the resources allocations and the infrastructure restoration priorities to maximize their needs to reach the goal. 5.3 Simulation Conclusion In this chapter, the I2Sim system model and the toolbox components has been vali- dated and tested by using the known UBC Campus cases and an unknown Vancouver 2010 Winter Olympics case. The advanced I2Sim model and toolbox demonstrated the improvements on the previous I2Sim version [18] and the accuracy for predict- ing behaviors of the interdependent infrastructure systems using the flow of resources instead of the capacity. The redundancy in the system such as the internal back-up generators and the secondary power lines increases the robustness of the system. The performance of the cells may be optimized or degraded depending on the distribution of the resources. In addition, the resource alone cannot increase the output of a cell when the physical damage is occurred to the building or the equipments. The allo- cation of the resources should be changed according to the flow of humans. Various different scenarios can be simulated easily by installing and using the I2Sim toolbox developed in MATLAB/Simulink. 5.4 Limitation of the MATLAB The limitation of the Matlab/Simulink that I discovered from the test case simulations is that as the number of components in the system increases, the simulation speed decreases by a fast rate. While the Vancouver Olympics case contains eighty one com- ponents in total, the simulation time for the case is still slightly faster than the real time. My colleague, Tomim, and I were able to increase the speed by cleaning up the loops and the conditional statements in the MATLAB code. However, for the further increase in speed, the features such as the color and the mask of the blocks may have 60 5.4. Limitation of the MATLAB to be compromised. I believe the main cause of the speed degradation is the nature of MATLAB/Simulink being a fourth generation programming language. This character- istics allows a higher abstraction and statement power, which allowed us to develop the toolbox with efficient graphical interfaces incorporated within less time and effort. However, both Tomim and I agreed that the final version of the simulator using a lower level programming language such as C++ or Java would be needed to build detailed and bigger simulation cases. Therefore, I would conclude that this version of the I2Sim toolbox should be used as a prototype for next version of the I2Sim simulator. Also, the limit of the number of components that will degrade the simulation time to be slower than the real time can be tested for future work. 61 Chapter 6 Conclusion This chapter describes the main contribution of the thesis and the future work that can be done. 6.1 Contribution This thesis is presented as a contribution to the development of the Infrastructure In- terdependency Simulation project led by Dr. Jose Marti at the University of British Columbia for the JIIRP and the Vancouver 2010 Olympics. In particular, one of the main contributions is developing a methodology for an improved I2Sim model with the physical modes and the resource modes. The new HRT contains only five to ten rows per physical mode which makes it significantly simpler and easier to build, com- pared to the original version [18]. The simplification was achieved by understanding of the threshold output level for each input resource instead of finding all possible combinations of the resources using the interpolation methods. In addition, the re- source mode is limited by the physical mode. That is, even though the resources are available, if the buildings or the lifelines are physically damaged, they cannot produce at its full capacity. Previously, only cells had the HRTs associated with them; however, in this research, channels and distributors also adopted the HRTs. The complexity and the importance of the cells, the channels, and the distributors was fully integrated to the system using the HRTs. Using this technique, the substation, the water station, the steam station, the power house, and the hospitals at the UBC Campus were modeled as well as the BC place, the GM Place, four substations, the water station, St. Paul’s Hospital, and Vancouver General Hospital for the Vancouver 2010 Winter Olympics as a part of the research. The second main contribution of this thesis is the development of the I2Sim Toolbox using Matlab/Simulink. Instead of a hard-coded simulator developed by Liu [18], the toolbox uses the standardized graphical component boxes to allow the users to build 62 6.2. Future Work any cases they want even with basic knowledge about the Simulink. The previous version of the I2Sim simulation test case was a very important starting point for the new I2Sim toolbox, but it was difficult to modify or create the cells. The new I2Sim toolbox allows an easy modification to the existing cells and channels as well as the creation of new cells and channels by dragging and connecting components as they are connected in real. The users do not need to have any professional programming background to develop a new case for themselves. The I2Sim toolbox consists of seven components: an aggregator, a HRT, a storage, a distributor, a channel, a source, and a sink. The combinations of these components were used successfully to build the test cases for the UBC Campus and the Vancouver 2010 Winter Olympics in this thesis. In addition, the future works mentioned by Liu [18] in her thesis have been tested and implemented in this thesis. The time delay has been taken into considerations for the patient transportation from the olympic venues to the hospitals. Also, the flow of patients and its effect at the hospital was implemented through the waiting area outside the disaster site and the waiting room in the hospitals. 6.2 Future Work An important part of future research in this area will be to improving the speed and performance of the simulator. As mentioned in chapter 5, the simulation time in- creases significantly as the number of cells increases since it is highly dependent on efficiency of Matlab/Simulink. As a result, the simulator with a lower level program- ming language can be built using the I2Sim toolbox as a prototype. This would require a longer time to be able to incorporate the graphical features that were given by MAT- LAB/Simulink. As expected, the development of the I2Sim toolbox has progressed in the JIIRP- UBC group. By changing the integration routine in the Simulink, from continuous to discrete steps, has significantly increased the simulation speed. In addition, the parallel computation methodology of MATE should further speed up simulation [5]. The speed issue leads to another work that can be done which is simulating a larger case such as a provincial-wise system. The toolbox has been used to successfully sim- ulate city-wise systems so far. However, whether it can handle a bigger case is yet to be proven. To extend the research carried out beyond Vancouver 2010 Winter Olympics, fu- 63 6.2. Future Work ture works can be done to build infrastructure systems with different goals such as an economical aspect instead of the human survival. Also, it can focus on the single type of infrastructure network to test if it can successfully produce the similar results com- pared to the results predicted by a specialized infrastructure program. For instance, it is interesting to note that, in most power system control centres, the ’daily operating orders’ are pre-computed and are essentially similar to HRTs in this thesis. It should be possible to extend I2Sim methodology to future developments in the power system control centres. 64 Bibliography [1] Presidential decision directive 63. [Online]. Available: http://www.ciao. gov/. [2] Critical Infrastructure Interdependency Modeling: A Survey of US and Interna- tional Research. Technical report, Idaho National Laboratory, 2006. [3] Winter storm report october 2006 - january 2007. Technical report, BC Hydro, 2007. [4] Massoud Amin. North america’s electricity infrastructure: Are we ready for more perfect storms? IEEE Security and Privacy, 1(5):19–25, 2003. [5] Tomim Marcelo Aroca. Parallel computation of large power system networks using the multi-area The’venin equivalents. PhD thesis, University of British Columbia, 2009. [6] P. Athukorala and B. P. Resosudarmo. The indian ocean tsunami: Economic im- pact diaster management and lessons. Asian Economic Papers, 2005. [7] Eric Bonabeau. Agent-based modeling: Methods and techniques for simulating human systems. Proceedings of the National Academy of Sciences of the United States of America, 99(Suppl 3):7280–7287, 2002. [8] Michel Bruneau, Stephanie E. Chang, Ronald T. Eguchi, George C. Lee, Thomas D. O’Rourke, Andrei M. Reinhorn, Masanobu Shinozuka, Kathleen Tier- ney, William A. Wallace, and Detlof von Winterfeldt. A framework to quantita- tively assess and enhance the seismic resilience of communities. Earthquake Spec- tra, 19(4):733–752, 2003. [9] A. Cervantes-Larios. A Geographical Information Systems Approach to Analyz- ing Critical Infrastructure Interdependencies: A Case Study at the UBC Campus. Master’s thesis, University of British Columbia, 2008. 66 Chapter 7. Bibliography [10] Donald D. Dudenhoeffer, May R. Permann, and Milos Manic. Cims: a framework for infrastructure interdependency modeling and analysis. In WSC ’06: Proceed- ings of the 38th conference on Winter simulation, pages 478–485. Winter Simulation Conference, 2006. [11] M.A. Ehlen and A.J. Scholand. Modeling interdependencies between power and economic sectors using the n-able agent-based model. In Power Engineering Society General Meeting, 2005. IEEE, pages 2842–2846, June 2005. [12] The Vancouver Organizing Committee for the 2010 Olympics and Para- lympics Winter Games. 2010 vancouver olympics games medals results sched- ule sports : Vancouver 2010 winter olympics. [Online]. Available: www. vancouver2010.com/, 2009. [13] O. Gursesli and A.A. Desrochers. Modeling infrastructure interdependencies us- ing petri nets. In Systems, Man and Cybernetics, 2003. IEEE International Conference on, volume 2, pages 1506–1512 vol.2, Oct. 2003. [14] Juarez Garcia H. Multi-Hazard Risk Assessment: an interdependency approach. PhD thesis, University of British Columbia, 2010. [15] Min H., Beyeler W., Brown T., Son Y., and Jones A.T. Toward modeling and simulation of critical national infrastructure interdependencies. IIE Transactions, 39(1):57–71, 2007. [16] Hollman J.A., Marti J.R., Jatskevich J., and Srivastava K.D. Dynamic islanding of critical infrastructures, a suitable strategy to survive and mitigate critical events. Int. J. Emergency Management. [17] Marti J.R., Hollman J.A., Ventura C., and Jatskevich J. Design for survival real- time infrastructures coordination. CNIP, 2007. [18] L. Liu. Prototyping and Cells Modeling of the Infrastructure Interdependencies Simulator I2Sim. Master’s thesis, University of British Columbia, 2007. [19] J. R. Marti. I2sim. [Online]. Available: http://www.i2sim.ca/, 2007. [20] Government of Canada. The government of canada announces $2.98 million to fund research on critical infrastructure interdependencies. Ottawa, April 2005. 67 Chapter 7. Bibliography [21] T.D. O’Rourke. Critical infrastructure, interdependencies, and resilience. The Bridge, 2007. [22] Nathan Ozog. Power systems modeling for multiple infrastructure damage and repair simulations. Master’s thesis, University of British Columbia. [23] S. Panzieri, R. Setola, and G. Ulivi. An agent based simulator for critical inter- dependent infrastructures. In In Proceedings of the 2nd International Conference on Critical Infrastructures, October 2004. [24] S. Panzieri, R. Setola, and G. Ulivi. An approach to model complex interdepen- dent infrastructures. In 16th IFAC World Congress, 2005. [25] May Robin Permann. Genetic algorithms for agent-based infrastructure interde- pendency modeling and analysis. In SpringSim ’07: Proceedings of the 2007 spring simulation multiconference, pages 169–177, San Diego, CA, USA, 2007. Society for Computer Simulation International. [26] George P. Richardson and Alexander L. Pugh. Introduction to System Dynamics Modeling with Dynamo. MIT Press, Cambridge, MA, USA, 1981. [27] S.M. Rinaldi, J.P. Peerenboom, and T.K. Kelly. Identifying, understanding, and an- alyzing critical infrastructureinterdependencies. Control Systems Magazine, IEEE, 21:11–25, December 2001. [28] Steven M. Rinaldi. Modeling and simulating critical infrastructures and their in- terdependencies. Hawaii International Conference on System Sciences, 2:20054a, 2004. [29] A. Shendarkar, K. Vasudevan, Seungho Lee, and Young-Jun Son. Crowd simu- lation for emergency response using bdi agent based on virtual reality. Winter Simulation Conference, 0:545–553, 2006. [30] K. Thibert. A methodology of assessing the seismic risk of buildings. Master’s thesis, University of British Columbia, 2008. [31] M. A. Tomim, H. Lee, and J. R. Marti. I2Sim Simulink Toolbox Specification. Univer- sity of British Columbia, 2009. 68 Appendix A Aggregator MATLAB System Function Code 1 function aggregator_sfun(block) 2 setup(block); 3 function setup(block) 4 %% Register number of input and output ports 5 numInPorts = block.DialogPrm(1).Data; 6 if isa(numInPorts,'double') 7 block.NumInputPorts = numInPorts; 8 for k = 1:numInPorts 9 block.InputPort(k).Complexity = 'Real'; 10 block.InputPort(k).DataTypeId = 0; 11 block.InputPort(k).SamplingMode = 'Sample'; 12 block.InputPort(k).Dimensions = 1; 13 end 14 end 15 %% Setup functional port properties to dynamically 16 %% inherited. 17 block.SetPreCompInpPortInfoToDynamic; 18 block.SetPreCompOutPortInfoToDynamic; 19 %% Dynamically adjusting the dimension of the output according to 20 %% available distribution factors 21 block.NumOutputPorts = 1; 22 block.OutputPort(1).Complexity = 'Real'; 23 block.OutputPort(1).DataTypeId = 0; 24 block.OutputPort(1).SamplingMode = 'Sample'; 25 block.OutputPort(1).Dimensions = 1; 26 %% Register parameters 27 block.NumDialogPrms = 1; 28 block.DialogPrmsTunable = {'NonTunable'}; 29 %% Set block sample time to inherited 68 Appendix A. Aggregator MATLAB System Function Code 30 block.SampleTimes = [-1 0]; 31 %% Run accelerator on TLC 32 block.SetAccelRunOnTLC(false); 33 %% Register methods 34 block.RegBlockMethod('Outputs', @Output); 35 36 function Output(block) 37 % Read parameters 38 numInPorts = block.NumInputPorts; 39 temp = 0; 40 for k=1:numInPorts 41 temp = temp + block.InputPort(k).Data; 42 end 43 block.OutputPort(1).Data = temp; 69 Appendix B HRT MATLAB System Function Code 1 function hrt_sfun(block) 2 setup(block); 3 function setup(block) 4 is_PM_Internal = block.DialogPrm(2).Data-1; 5 HRT_name = block.DialogPrm(1).Data; 6 if evalin('base',['exist(''' HRT_name ''',''var'')']) 7 HRT_struct = evalin('base',HRT_name); 8 [dummy, num_PM]=size(HRT_struct); 9 temp=HRT_struct.HRT; 10 [nr,nc] = size(temp); 11 InputDimension = nc - 1; 12 numInPorts = InputDimension; 13 if (is_PM_Internal == 0) 14 % In this case, add an input port for the PM 15 numInPorts = numInPorts + 1; 16 end 17 numOutPorts = 2; 18 else 19 numInPorts = 0; 20 numOutPorts = 0; 21 end 22 %% Register number of input and output ports 23 block.NumInputPorts = numInPorts; 24 block.NumOutputPorts = numOutPorts; 25 %% Setup functional port properties to dynamically 26 %% inherited. 27 block.SetPreCompInpPortInfoToDynamic; 28 block.SetPreCompOutPortInfoToDynamic; 29 if numOutPorts 70 Appendix B. HRT MATLAB System Function Code 30 block.OutputPort(1).Dimensions = 1; 31 block.OutputPort(2).Dimensions = 1; 32 for k = 1:InputDimension 33 block.InputPort(k).Dimensions = 1; 34 end 35 end 36 if ( (is_PM_Internal == 0) && (numInPorts 6= 0) ) 37 % In this case, add an input port for the PM 38 block.InputPort(k+1).Dimensions = 1; 39 end 40 %% Dynamically adjusting the dimension of the input according to HRT 41 %% Register parameters 42 % 1 - Human Readable Table; 43 % 2 - Flag for internal or external PM; 44 % 3 - PM; 45 block.NumDialogPrms = 4; 46 block.DialogPrmsTunable = {'Tunable','Tunable','Tunable','Tunable'}; 47 %% Set block sample time to inherited 48 block.SampleTimes = [-1 0]; 49 %% Run accelerator on TLC 50 block.SetAccelRunOnTLC(false); 51 %% Register methods 52 block.RegBlockMethod('PostPropagationSetup', @PostPropagationSetup); 53 block.RegBlockMethod('Start', @Start); 54 block.RegBlockMethod('Outputs', @Output); 55 block.RegBlockMethod('SetInputPortSamplingMode',@SetInputPortSamplingMode); 56 function SetInputPortSamplingMode(block, idx, fd) 57 block.InputPort(idx).SamplingMode = fd; 58 block.InputPort(idx).SamplingMode = fd; 59 block.OutputPort(1).SamplingMode = fd; 60 block.OutputPort(2).SamplingMode = fd; 61 function Output(block) 62 % Read parameters 63 isPMInternal = block.DialogPrm(2).Data-1; 64 if isPMInternal 65 PM = block.DialogPrm(3).Data; 66 else 67 PM = block.InputPort(block.Dwork(2).Data+1).Data; 68 end 69 HRT_struct = evalin('base',block.DialogPrm(1).Data); 70 [dummy, num_PM]=size(HRT_struct); 71 temp=HRT_struct.HRT; 71 Appendix B. HRT MATLAB System Function Code 72 [nr,nc] = size(temp); 73 HRT=HRT_struct(PM).HRT; 74 base=HRT_struct.Output_Base; 75 rated=[num2str(int16(base)) HRT_struct(1).Output_Unit]; 76 77 for k = 1:block.Dwork(2).Data 78 block.Dwork(1).Data(k) = block.InputPort(k).Data; 79 end 80 [y, limit]= HRT_Search(HRT,block.Dwork(1).Data,PM,num_PM); 81 if limit>0 82 limiting_input=HRT_struct(PM).Input_Name(limit,:); 83 limiting_input; 84 else 85 limiting_input='none'; 86 end 87 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 88 %% Change the Block Background Color - assiciated with RM (resource mode) 89 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 90 %set big rectangle colour according to output 91 rm_old=get_param(gcb, 'BackgroundColor'); 92 if y≥0.85*base 93 rm='[0, 1, 0]'; 94 elseif y≥0.7*base 95 rm='[0, 1, 1]'; 96 elseif y≥0.45*base 97 rm='[1, 1, 0]'; 98 elseif y≥0.26*base 99 rm='[1, 0.5, 0]'; 100 else 101 rm='[1, 0, 0]'; 102 end 103 % Compare old color with new one 104 if ( strcmp('white',rm_old) ) 105 set_param(gcb, 'BackgroundColor', rm); 106 if block.DialogPrm(4).Data==1 107 set_param(gcs,'SimulationCommand','pause'); 108 end 109 else 110 if (strcmp('orange',rm_old)) 111 vec_rm_old=[1 0.5 0]; 112 else 113 vec_rm_old = eval(rm_old); 72 Appendix B. HRT MATLAB System Function Code 114 end 115 vec_rm = eval(rm); 116 if( sum(vec_rm 6= vec_rm_old) ) 117 set_param(gcb, 'BackgroundColor', rm); 118 if block.DialogPrm(4).Data==1 119 set_param(gcs,'SimulationCommand','pause'); 120 end 121 end 122 end 123 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 124 %% Change the PM Background Color - assiciated with PM (physical mode) 125 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 126 % Check if PM changed 127 is_PM_changed = ( block.Dwork(3).Data 6= PM ); 128 is_y_changed = (block.Dwork(4).Data 6= y); 129 is_limit_changed =(block.Dwork(5).Data 6= limit); 130 if (is_PM_changed||is_y_changed||is_limit_changed) 131 %set small rectangle colour according to PM 132 txt=['text(0.1,0.95,''PM=0' num2str(PM) ''')']; 133 txt2='text(0.7,0.95,''{\bf\fontsize{12}Rated:}'',''texmode'',''on'')'; 134 txt3=['text(0.75,0.85,''{\bf\fontsize{12}' rated '}'',''texmode'', 135 ''on'')']; 136 txt=[txt txt2 txt3]; 137 if HRT(1,1)≥0.85*base 138 code_om=['patch([0 0 0.5 0.5],[0.6 1 1 0.6], [0 1 0]), 139 plot([-0.02 0.49 0.49],[0.61 0.61 1.02])',txt]; 140 elseif HRT(1,1)≥0.7*base 141 code_om=['patch([0 0 0.5 0.5],[0.6 1 1 0.6], [0 1 1]), 142 plot([-0.02 0.49 0.49],[0.61 0.61 1.02])',txt]; 143 elseif HRT(1,1)≥0.45*base 144 code_om=['patch([0 0 0.5 0.5],[0.6 1 1 0.6], [1 1 0]), 145 plot([-0.02 0.49 0.49],[0.61 0.61 1.02])',txt]; 146 elseif HRT(1,1)≥0.26*base 147 code_om=['patch([0 0 0.5 0.5],[0.6 1 1 0.6], [1, 0.5, 0]), 148 plot([-0.02 0.49 0.49],[0.61 0.61 1.02])',txt]; 149 else 150 code_om=['patch([0 0 0.5 0.5],[0.6 1 1 0.6], [1 0 0]), 151 plot([-0.02 0.49 0.49],[0.61 0.61 1.02])',txt]; 152 end 153 154 port_labels = []; 155 for k = 1: block.Dwork(2).Data 73 Appendix B. HRT MATLAB System Function Code 156 port_labels = [port_labels ',port_label(''input'',' num2str(k) ', 157 ''in' num2str(k) ''')'] ; 158 end 159 port_labels = [port_labels ',port_label(''input'',' num2str(k+1) ', 160 ''PM'')']; 161 port_labels = [port_labels ',port_label(''output'',1,''out''), 162 port_label(''output'',2,''{\bf\fontsize{13}NEED:' limiting_input'} 163 '',''texmode'',''on'')']; 164 set_param(gcb, 'MaskDisplay',[ code_om port_labels ]); 165 if block.DialogPrm(4).Data==1 166 set_param(gcs,'SimulationCommand','pause'); 167 end 168 if isPMInternal 169 block.Dwork(3).Data = block.DialogPrm(3).Data; 170 else 171 block.Dwork(3).Data = block.InputPort(block.Dwork(2).Data+1).Data; 172 end 173 block.Dwork(4).Data=y; 174 block.Dwork(5).Data=limit; 175 end 176 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 177 %% Code for the Pause feature, for everytime the HRT output or PM changes 178 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 179 block.OutputPort(1).Data = y; 180 block.OutputPort(2).Data = limit; 181 function [y, limit] = HRT_Search(HRT,x,PM,num_PM) 182 if num_PM ≥ PM && PM > 0 183 table=HRT; 184 %find the size of HRT 185 [r, c]=size(table); 186 k=1; 187 trig=-1; %tag that changes to 1 when limiting factor is found 188 %in the column 189 temp_row=1;%limiting factor position 190 limit_input=1; 191 %starts from the first column of input and goes down the row until 192 %it finds the entry that is lower than the input(limiting factor) 193 for n=2:c 194 while k≤r && trig==-1 195 if table(k,n)≤x(n-1) 196 trig=1; 197 if temp_row6=k 74 Appendix B. HRT MATLAB System Function Code 198 limit_input=n-1;%limiting input 199 end 200 temp_row=k;%the row limiting factor was found 201 end 202 k=k+1; 203 end 204 trig=-1;%tag resetted to -1 for next column 205 k=k-1; 206 end 207 y=table(temp_row,1);%output at the row limiting factor was found 208 %when all inputs are equal to or above the maximum capacity of 209 %the cell, limiting factor is zero. 210 if temp_row6=1 211 limit=limit_input;%limiting input 212 else 213 limit=0; 214 end 215 %When there is a negative entry in the HRT, output and limit will 216 %set to unreasonable number to indicate it. 217 else 218 feval('error','Unavailable Operating Mode'); 219 y=0; 220 limit=0; 221 end 222 function PostPropagationSetup(block) 223 %% Work vector (persistent data) 224 block.NumDworks = 5; 225 HRT_struct = evalin('base',block.DialogPrm(1).Data); 226 [dummy, num_PM]=size(HRT_struct); 227 temp=HRT_struct.HRT; 228 [nr,nc] = size(temp); 229 InputDimension = nc - 1; 230 block.Dwork(1).Name = 'x'; 231 block.Dwork(1).Dimensions = InputDimension; 232 block.Dwork(1).DatatypeID = 0; 233 block.Dwork(1).Complexity = 'Real'; 234 block.Dwork(1).UsedAsDiscState = true; 235 236 block.Dwork(2).Name = 'InputDimension'; 237 block.Dwork(2).Dimensions = 1; 238 block.Dwork(2).DatatypeID = 0; 239 block.Dwork(2).Complexity = 'Real'; 75 Appendix B. HRT MATLAB System Function Code 240 block.Dwork(2).UsedAsDiscState = true; 241 242 block.Dwork(4).Name = 'OldY'; 243 block.Dwork(4).Dimensions = 1; 244 block.Dwork(4).DatatypeID = 0; 245 block.Dwork(4).Complexity = 'Real'; 246 block.Dwork(4).UsedAsDiscState = true; 247 248 block.Dwork(3).Name = 'OldPM'; 249 block.Dwork(3).Dimensions = 1; 250 block.Dwork(3).DatatypeID = 0; 251 block.Dwork(3).Complexity = 'Real'; 252 block.Dwork(3).UsedAsDiscState = true; 253 254 block.Dwork(5).Name = 'Oldlimit'; 255 block.Dwork(5).Dimensions = 1; 256 block.Dwork(5).DatatypeID = 0; 257 block.Dwork(5).Complexity = 'Real'; 258 block.Dwork(5).UsedAsDiscState = true; 259 260 function Start(block) 261 HRT_struct = evalin('base',block.DialogPrm(1).Data); 262 [dummy, num_PM]=size(HRT_struct); 263 temp=HRT_struct.HRT; 264 [nr,nc] = size(temp); 265 InputDimension = nc - 1; 266 block.Dwork(1).Data = zeros(InputDimension,1); 267 block.Dwork(2).Data = InputDimension; 268 block.Dwork(4).Data=-1; 269 isPMInternal = block.DialogPrm(2).Data-1; 270 if isPMInternal 271 block.Dwork(3).Data = -1; 272 else 273 block.Dwork(3).Data = block.InputPort(block.Dwork(2).Data+1).Data; 274 end 76 Appendix C Distributor MATLAB System Function Code 1 function distributor_sfun(block) 2 setup(block); 3 function setup(block) 4 try 5 is_OM_Internal = block.DialogPrm(2).Data; 6 if (is_OM_Internal == 0) 7 % In this case, add an input port for the OM 8 numInPorts = 2; 9 else 10 % otherwise 11 numInPorts = 1; 12 end 13 catch 14 numInPorts = 1; 15 end 16 %% Register number of input and output ports 17 block.NumInputPorts = numInPorts; 18 for k = 1:numInPorts 19 block.InputPort(k).Complexity = 'Real'; 20 block.InputPort(k).DataTypeId = 0; 21 block.InputPort(k).SamplingMode = 'Sample'; 22 block.InputPort(k).Dimensions = 1; 23 end 24 %% Setup functional port properties to dynamically 25 %% inherited. 26 block.SetPreCompInpPortInfoToDynamic; 27 block.SetPreCompOutPortInfoToDynamic; 28 %% Dynamically adjusting the dimension of the output according to 29 %% available distribution factors 77 Appendix C. Distributor MATLAB System Function Code 30 isDistManual = block.DialogPrm(1).Data; 31 if isDistManual 32 OutputDimension = length(block.DialogPrm(5).Data); 33 else 34 HRT_name = block.DialogPrm(3).Data; 35 HRT_struct = evalin('base',HRT_name); 36 temp=HRT_struct.HRT; 37 [nr,nc] = size(temp); 38 OutputDimension = nc - 1; 39 end 40 block.NumOutputPorts = OutputDimension; 41 for k = 1:OutputDimension 42 block.OutputPort(k).Complexity = 'Real'; 43 block.OutputPort(k).DataTypeId = 0; 44 block.OutputPort(k).SamplingMode = 'Sample'; 45 block.OutputPort(k).Dimensions = 1; 46 end 47 %% Register parameters 48 % 1 - Flag for manual or automatic operation; 49 % 2 - Flag for internal or external OM; 50 % 3 - Human Readable Table; 51 % 4 - OM; 52 % 5 - distribution factors; 53 block.NumDialogPrms = 5; 54 block.DialogPrmsTunable = {'Tunable','Tunable','Tunable','Tunable', 55 'Tunable'}; 56 %% Set block sample time to inherited 57 block.SampleTimes = [-1 0]; 58 %% Run accelerator on TLC 59 block.SetAccelRunOnTLC(false); 60 %% Register methods 61 block.RegBlockMethod('CheckParameters', @CheckPrms); 62 block.RegBlockMethod('SetInputPortSamplingMode',@SetInputPortSamplingMode); 63 block.RegBlockMethod('Outputs', @Output); 64 function CheckPrms(block) 65 flagManual = block.DialogPrm(1).Data; 66 function Output(block) 67 % Read parameters 68 isOMInternal = block.DialogPrm(2).Data; 69 if isOMInternal 70 OM = block.DialogPrm(4).Data; 71 else 78 Appendix C. Distributor MATLAB System Function Code 72 OM = block.InputPort(2).Data; 73 end 74 isDistManual = block.DialogPrm(1).Data; 75 x = block.InputPort(1).Data; 76 if isDistManual 77 factors = block.DialogPrm(5).Data; 78 y = x*factors; 79 else 80 HRT_name = block.DialogPrm(3).Data; 81 HRT_struct = evalin('base',HRT_name); 82 HRT=HRT_struct(OM).HRT; 83 y = HRT_Search(HRT,x); 84 end 85 for k=1:length(y) 86 block.OutputPort(k).Data = y(k); 87 end 88 function y = HRT_Search(HRT,x) 89 if ¬isempty(HRT) 90 [r,c] = size(HRT); 91 % Check x dimension 92 if (length(x) 6= 1) 93 feval('error','DISTRIBUTOR ERROR: There must be only one input 94 into a distributor'); 95 end 96 % Checking if operating mode inputted is actually available in HRT 97 %struct 98 table = HRT; 99 % Find the row that best approximate the input 100 [xmin,idx] = min(abs(x-table(:,1))); 101 y = x.*table(idx,2:c); 102 else 103 y = 0; 104 end 105 function SetInputPortSamplingMode(block,port,mode) 106 block.InputPort(port).SamplingMode = mode; 107 block.OutputPort(port).SamplingMode = mode; 79 Appendix D Channel MATLAB System Function Code 1 function hrt_sfun(block) 2 setup(block); 3 function setup(block) 4 block.NumInputPorts = numInPorts; 5 block.NumOutputPorts = 3; 6 %% Setup functional port properties to dynamically 7 %% inherited. 8 block.SetPreCompInpPortInfoToDynamic; 9 block.SetPreCompOutPortInfoToDynamic; 10 block.OutputPort(1).Dimensions = 1; 11 block.OutputPort(2).Dimensions = 1; 12 block.OutputPort(3).Dimensions = 1; 13 block.InputPort(1).DImensions = 1; 14 %% Register parameters 15 % 1 - HRT 16 block.NumDialogPrms = 2; 17 block.DialogPrmsTunable = {'Tunable','Tunable'}; 18 %% Set block sample time to inherited 19 block.SampleTimes = [-1 0]; 20 %% Run accelerator on TLC 21 block.SetAccelRunOnTLC(false); 22 %% Register methods 23 block.RegBlockMethod('Start', @Start); 24 block.RegBlockMethod('PostPropagationSetup', @PostPropagationSetup); 25 block.RegBlockMethod('Outputs', @Output); 26 block.RegBlockMethod('SetInputPortSamplingMode',@SetInputPortSamplingMode); 27 function SetInputPortSamplingMode(block, idx, fd) 28 block.InputPort(idx).SamplingMode = fd; 29 block.OutputPort(1).SamplingMode = fd; 80 Appendix D. Channel MATLAB System Function Code 30 block.OutputPort(2).SamplingMode = fd; 31 block.OutputPort(3).SamplingMode = fd; 32 function Output(block) 33 % Read parameters 34 OM = block.InputPort(1).Data; 35 HRT_struct = block.DialogPrm(1).Data; 36 HRT=HRT_struct.HRT; 37 is_OM_changed = ( block.Dwork(1).Data 6= OM ); 38 if (is_OM_changed) 39 capacity=max(HRT(OM,1)); 40 if capacity≥0.85 41 code='[0, 1, 0]'; 42 elseif capacity≥0.7 43 code='[0, 1, 1]'; 44 elseif capacity≥0.45 45 code='[1, 1, 0]'; 46 elseif capacity≥0.26 47 code='[1, 0.5, 0]'; 48 else 49 code='[1, 0, 0]'; 50 end 51 set_param(gcs, 'BackgroundColor', code) 52 token=HRT_struct.Token; 53 txt=['text(0.5,0.9,''PM=0' num2str(OM) ''',''texmode'',''on'')']; 54 txt2=[txt 'text(0.5,0.5,''{\bf\fontsize{13}' token '}'', 55 ''texmode'',''on'')']; 56 txt3=[txt2 ',port_label(''input'',2, ''PM'')']; 57 set_param(gcs,'MaskDisplay',txt3); 58 block.Dwork(1).Data = block.InputPort(1).Data; 59 if block.DialogPrm(2).Data==1; 60 set_param(bdroot(gcb),'SimulationCommand','pause'); 61 end 62 end 63 [a, tal, y_max]= HRT_Search(HRT,OM); 64 block.OutputPort(1).Data = a; 65 block.OutputPort(2).Data = tal; 66 block.OutputPort(3).Data = y_max; 67 function [a, tal, y_max] = HRT_Search(HRT,OM) 68 a=HRT(OM,1); 69 tal=HRT(OM,2); 70 y_max=HRT(OM,3); 71 function PostPropagationSetup(block) 81 Appendix D. Channel MATLAB System Function Code 72 block.NumDworks = 1; 73 block.Dwork(1).Name = 'OldOM'; 74 block.Dwork(1).Dimensions = 1; 75 block.Dwork(1).DatatypeID = 0; 76 block.Dwork(1).Complexity = 'Real'; 77 block.Dwork(1).UsedAsDiscState = true; 78 function Start(block) 79 block.Dwork(1).Data = -1; 82 Appendix E Statement of Collaboration The work of building the Vancouver 2010 Winter Olympics test case presented in this thesis is a part of work done by I2Sim group. The scenario for the case was built during the I2Sim group meetings based on the damage assessment from H. Juarez. I designed and implemented the BC Place, the GM Place, the hospitals, and the Water Station. The modeling and data collection for four substations were done by S. Rostamirad, and the data collection for the hospitals and the olympic venues were done by K. Mirza in I2Sim group. Finally, I put together the case using the I2Sim toolbox. In I2Sim toolbox, I developed Source, Sink, HRT, Distributor, Channel, and Aggregator, while Dr. Tomim developed Storage, Distributor interface, and I2Sim Control and Visualization Panels which was not introduced in this thesis. 83

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:
https://iiif.library.ubc.ca/presentation/dsp.24.1-0064885/manifest

Comment

Related Items