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 major 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 components 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  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  1  1.1  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  1  1.2  Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3  1.2.1  Infrastructure Interdependencies  . . . . . . . . . . . . . . . . . .  3  1.2.2  Previous Researches . . . . . . . . . . . . . . . . . . . . . . . . . .  4  2  Introduction  1.3  Research Objectives  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6  1.4  Organization of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . .  6  Infrastructure Interdependencies Simulation (I2Sim) . . . . . . . . . . . . .  8  2.1  I2Sim Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8  2.1.1  . . . . . . . . . . . . . . . . . . .  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  Cell and Channel Classification  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  15  Human Readable Table 3.1.1  4  5  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  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  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  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  I2Sim Toolbox  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  Simulations and Results 5.1  5.2  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  38  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  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 colleagues 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 Laboratory 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 student, 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 Infrastructure 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 interconnection 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 suffering 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 mobilize 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 disaster 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 disasters long before the disaster while preparedness is the policies and plans on emergency 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 Interdependencies 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 infrastructure 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 interdependencies 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 capabilities 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 infrastructures, through which one infrastructure influences the other while the interdependency 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 material 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 macroscopic view of emergency preparedness organizations or the microscopic view of the first responders. The emergency preparedness organizations may see the whole picture of how the infrastructures interact; they, however, may miss the details and complexity 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 infrastructures. 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 simulation tools have taken two approaches on modeling the infrastructure system: integrated and coupled models [2]. The integrated model is designed to model multiple infrastructures and their interdependencies within one framework. The coupled approach takes multiple simulations of infrastructures and connect them together. The major modeling techniques using these two approaches are Petri Nets, System Dynamics, 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 discrete 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 infrastructures 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 information. • System Dynamics - System Dynamics is a continuous time based approach to model complex feedback systems. Forrester developed the methodology focusing on stocks, flows, and the feedback of the system over time [26]. Min et al. simulated an infrastructure interdependency model using this technique combined 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 Interdependent Agents (CISIA) presented by Panzieri et al. [2] [23] [24], and Nextgeneration agent-based economic laboratory (N-ABLE) by Sandia National Lab5  1.3. Research Objectives oratories [2] [11]. In the agent-based model, the detailed models of infrastructures, 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 additional 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 increase 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 Interdependency 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 developed specialized in each of these infrastructures to accurately calculate and estimate the results, predicting the outcome when these infrastructures are interconnected together 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 making 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 addition, it can help discover the hidden interdependencies between infrastructures.  2.1  I2Sim Ontology  In Infrastructure Interdependencies Simulation (I2Sim), physical entities such as buildings 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. However, 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 characteristics 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 I2DB  I2Sim GIS  - Virtual cell and channel models - Human Readable Tables  Mapping  - Study area - Critical buildings (infrastructure, hospitals, etc) - lifelines  Assessment  - Disaster scenario - Physical damage assessment to buildings and lifelines  Implementation I2Sim Toolbox  Scenario Development - Simulation  I2Sim Damage  Decisions  Assessment  Results  - Result analysis - Decision making I2Sim Operating Centre  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 buildings 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 classifications 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 adjustments 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 repairs, 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 negatively. 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 because 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 population 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  • Water Station  • Fire Hall  • Telecom Generator  • Ambulance Service • RCMP  • Transportation • Food Services  • Classroom and Library • Commercial • Research Lab and Museum • Residential • Parking Lots  • Administrator • Services and Utility  • Recreation and Society  • Power House  • Substation  • 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 implemented 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 economy has been adopted to build the new I2Sim HRTs. For a factory to produce a certain 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 using 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 possible 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 High-pressured Water (m3 /hr) 103 77 51 26 0  Electricity (MW) 0.011 0.008 0.005 0.003 0  Input Low-pressured Water (m3 /hr) 103 77 51 26 0  Table 3.1: Production Human Readable Table  Another major improvement made in the new Human Readable Table is the physical 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 physical 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 understanding 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  ,ŽƐƉŝƚĂů Ğůů WŚLJƐŝĐĂů DŽĚĞƐ KƉĞƌĂďŝůŝƚLJ WDϬϭ ϭϬϬй WDϬϮ ϲϲй WDϬϯ ϯϯй WDϬϰ Ϭй  ZDϬϭ ZDϬϮ ZDϬϯ  KƵƚƉƵƚ WĂƚŝĞŶƚƐ ϭϬϬй ϱϬй Ϭй  ZDϬϭ ZDϬϮ ZDϬϯ  KƵƚƉƵƚ WĂƚŝĞŶƚƐ ϲϲй ϯϯй Ϭй  ZDϬϭ ZDϬϮ  KƵƚƉƵƚ WĂƚŝĞŶƚƐ ϯϯй Ϭй  ZDϬϭ  KƵƚƉƵƚ WĂƚŝĞŶƚƐ Ϭй  WDϬϭ с ϭϬϬй ůĞĐƚƌŝĐŝƚLJ ϭϬϬй ϱϬй Ϭй  /ŶƉƵƚƐ tĂƚĞƌ 'ĂƐ ϭϬϬй ϭϬϬй ϱϬй ϱϬй Ϭй Ϭй  ^ƚĂĨĨƐ ϭϬϬй ϱϬй Ϭй  WDϬϮ с ϲϲй ůĞĐƚƌŝĐŝƚLJ ϲϲй ϯϯй Ϭй  /ŶƉƵƚƐ tĂƚĞƌ ϲϲй ϯϯй Ϭй  'ĂƐ ϲϲй ϯϯй Ϭй  ^ƚĂĨĨƐ ϲϲй ϯϯй Ϭй  /ŶƉƵƚƐ tĂƚĞƌ 'ĂƐ ϯϯй ϯϯй Ϭй Ϭй  ^ƚĂĨĨƐ ϯϯй Ϭй  /ŶƉƵƚƐ tĂƚĞƌ 'ĂƐ Ϭй Ϭй  ^ƚĂĨĨƐ Ϭй  WDϬϯ с ϯϯй ůĞĐƚƌŝĐŝƚLJ ϯϯй Ϭй WDϬϰ с Ϭй ůĞĐƚƌŝĐŝƚLJ Ϭй  Figure 3.1: Physical Mode and Resource Mode  3.3  Color Scheme  The physical mode (PM) and the resource mode (RM) mentioned above are represented inside the I2Sim Cell and Channel blocks through a color scheme for the visualization 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 functionality 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 interviewing 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 distributed. The ratio could be either given by the infrastructure stakeholders or calculated by the number of the channels that carry the output and the capacity of the channels. 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 components which are created based on the I2Sim concept introduced earlier in this thesis. 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 MATLAB/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 difficult 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 visualization 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 summation 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 production 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 interface 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 4569% 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  60MW  Hospital 60MW needed 100L/hour needed  0L/hour  Substation 60MW Available  0MW  0% of patients healed  Electricity Channel Water Channel  Water Station 40MW needed  (a) Bad Distribution of Resource  40MW  Hospital 60MW needed 100L/hour needed  50L/hour  Substation 60MW Available  20MW  70% of patients treated  Electricity Channel Water Channel  Water Station 40MW needed  (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 yˆ % 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 channel 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 ⇒ ∆L = v(t) × ∆t ∆t  (4.2)  When the integral of equation 4.2 is taken from time t to td (t), it becomes: L  t  dl = 0  t  v(t)dt ⇒ L = t−td (t)  t−td (t)  L dt τ (t)  (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. t  1= t−td (t)  1 dt τ (t)  (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 outside 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 sfunction 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 command 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 = level0 +         lmax t 0 (xin  level ≥ lmax − xcmd )dt  lmin < level < lmax  lmin  (4.5)  level ≤ lmin  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 resources 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  UBC Substation  Electricity Source BC Hydro Substation  Electricity Channel  UBC Hospital  Electricity Water Gas Steam  Substation Cell  Back-up Generator Electricity Channel Purdy Hospital Cell (Long-term Patients)  Electricity Channel  Back-up Water Tank  Electricity Channel  UBC Power House  Back-up Water Tank  Power House Cell Water Station Cell Water Source GVRD  Gas Source Terasen Gas Returned Steam Source  Water Channel  Water Channel  Back-up Oil Tank  Gas Channel Steam Channel  Medicine & Personnel Source  Back-up Generator  Back-up Generator  Steam Station Cell  Koerner Hospital Cell (Short-term Patients) Steam Channel  UBC Steam Station Gas Channel  Figure 5.1: Design of Reduced UBC Campus Test Case  Treated Long-term Patients Sink  5.1. UBC Campus Case  UBC Water Station  Treated Short-term Patients Sink  39  5.1. UBC Campus Case  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 information 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 functionality 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] PM01 output input electricity electricity MW MW 22800 22800 18240 18240 13680 13680 9120 9120 4560 4560 0 0  (c) New Substation Model  PM02 output input electricity electricity MW MW 11400 11400 9120 9120 6840 6840 4560 4560 2280 2280 0 0  PM03 output input electricity electricity MW MW 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 electrical 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 water 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 distribution 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 outputs 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:  T otal patients = total paitents0 + entering patients − treated patients  (5.1)    treatable patients total patients ≥ treatable patients T reated patients =     (5.2) total patients  total patients < treatable patients  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 hospital 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 functionality 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 electrical 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. UBC Campus Case  51  Figure 5.11: Vancouver 2010 Winter Olympics Study Area  5.1. UBC Campus Case  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 features 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 supplying 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 virtual 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 information 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 earthquake 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 Downtown Vancouver and bridges connected to it will be high. Also, there will be a sunset 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 Vancouver 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 increase 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 validated 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 predicting 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 allocation 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 components 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 characteristics 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 Interdependency 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, compared 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 resource 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 increases 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 programming 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 MATLAB/Simulink. As expected, the development of the I2Sim toolbox has progressed in the JIIRPUBC 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 simulate 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, fu63  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 compared 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 International 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 impact 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 Tierney, William A. Wallace, and Detlof von Winterfeldt. A framework to quantitatively assess and enhance the seismic resilience of communities. Earthquake Spectra, 19(4):733–752, 2003. [9] A. Cervantes-Larios. A Geographical Information Systems Approach to Analyzing 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: Proceedings 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 Paralympics Winter Games. 2010 vancouver olympics games medals results schedule sports : Vancouver 2010 winter olympics.  [Online]. Available: www.  vancouver2010.com/, 2009. [13] O. Gursesli and A.A. Desrochers. Modeling infrastructure interdependencies using 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 realtime 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 interdependent 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 interdependent infrastructures. In 16th IFAC World Congress, 2005. [25] May Robin Permann. Genetic algorithms for agent-based infrastructure interdependency 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 analyzing critical infrastructureinterdependencies. Control Systems Magazine, IEEE, 21:11–25, December 2001. [28] Steven M. Rinaldi. Modeling and simulating critical infrastructures and their interdependencies. Hawaii International Conference on System Sciences, 2:20054a, 2004. [29] A. Shendarkar, K. Vasudevan, Seungho Lee, and Young-Jun Son. Crowd simulation 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. University of British Columbia, 2009.  68  Appendix A  Aggregator MATLAB System Function Code 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29  function aggregator_sfun(block) setup(block); function setup(block) %% Register number of input and output ports numInPorts = block.DialogPrm(1).Data; if isa(numInPorts,'double') block.NumInputPorts = numInPorts; for k = 1:numInPorts block.InputPort(k).Complexity = 'Real'; block.InputPort(k).DataTypeId = 0; block.InputPort(k).SamplingMode = 'Sample'; block.InputPort(k).Dimensions = 1; end end %% Setup functional port properties to dynamically %% inherited. block.SetPreCompInpPortInfoToDynamic; block.SetPreCompOutPortInfoToDynamic; %% Dynamically adjusting the dimension of the output according to %% available distribution factors block.NumOutputPorts = 1; block.OutputPort(1).Complexity = 'Real'; block.OutputPort(1).DataTypeId = 0; block.OutputPort(1).SamplingMode = 'Sample'; block.OutputPort(1).Dimensions = 1; %% Register parameters block.NumDialogPrms = 1; block.DialogPrmsTunable = {'NonTunable'}; %% Set block sample time to inherited  68  Appendix A. Aggregator MATLAB System Function Code 30 31 32 33 34  block.SampleTimes = [-1 0]; %% Run accelerator on TLC block.SetAccelRunOnTLC(false); %% Register methods block.RegBlockMethod('Outputs', @Output);  35 36 37 38 39 40 41 42 43  function Output(block) % Read parameters numInPorts = block.NumInputPorts; temp = 0; for k=1:numInPorts temp = temp + block.InputPort(k).Data; end block.OutputPort(1).Data = temp;  69  Appendix B  HRT MATLAB System Function Code 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29  function hrt_sfun(block) setup(block); function setup(block) is_PM_Internal = block.DialogPrm(2).Data-1; HRT_name = block.DialogPrm(1).Data; if evalin('base',['exist(''' HRT_name ''',''var'')']) HRT_struct = evalin('base',HRT_name); [dummy, num_PM]=size(HRT_struct); temp=HRT_struct.HRT; [nr,nc] = size(temp); InputDimension = nc - 1; numInPorts = InputDimension; if (is_PM_Internal == 0) % In this case, add an input port for the PM numInPorts = numInPorts + 1; end numOutPorts = 2; else numInPorts = 0; numOutPorts = 0; end %% Register number of input and output ports block.NumInputPorts = numInPorts; block.NumOutputPorts = numOutPorts; %% Setup functional port properties to dynamically %% inherited. block.SetPreCompInpPortInfoToDynamic; block.SetPreCompOutPortInfoToDynamic; if numOutPorts  70  Appendix B. HRT MATLAB System Function Code 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71  block.OutputPort(1).Dimensions = 1; block.OutputPort(2).Dimensions = 1; for k = 1:InputDimension block.InputPort(k).Dimensions = 1; end end if ( (is_PM_Internal == 0) && (numInPorts = 0) ) % In this case, add an input port for the PM block.InputPort(k+1).Dimensions = 1; end %% Dynamically adjusting the dimension of the input according to HRT %% Register parameters % 1 - Human Readable Table; % 2 - Flag for internal or external PM; % 3 - PM; block.NumDialogPrms = 4; block.DialogPrmsTunable = {'Tunable','Tunable','Tunable','Tunable'}; %% Set block sample time to inherited block.SampleTimes = [-1 0]; %% Run accelerator on TLC block.SetAccelRunOnTLC(false); %% Register methods block.RegBlockMethod('PostPropagationSetup', @PostPropagationSetup); block.RegBlockMethod('Start', @Start); block.RegBlockMethod('Outputs', @Output); block.RegBlockMethod('SetInputPortSamplingMode',@SetInputPortSamplingMode); function SetInputPortSamplingMode(block, idx, fd) block.InputPort(idx).SamplingMode = fd; block.InputPort(idx).SamplingMode = fd; block.OutputPort(1).SamplingMode = fd; block.OutputPort(2).SamplingMode = fd; function Output(block) % Read parameters isPMInternal = block.DialogPrm(2).Data-1; if isPMInternal PM = block.DialogPrm(3).Data; else PM = block.InputPort(block.Dwork(2).Data+1).Data; end HRT_struct = evalin('base',block.DialogPrm(1).Data); [dummy, num_PM]=size(HRT_struct); temp=HRT_struct.HRT;  71  Appendix B. HRT MATLAB System Function Code 72 73 74 75  [nr,nc] = size(temp); HRT=HRT_struct(PM).HRT; base=HRT_struct.Output_Base; rated=[num2str(int16(base)) HRT_struct(1).Output_Unit];  76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113  for k = 1:block.Dwork(2).Data block.Dwork(1).Data(k) = block.InputPort(k).Data; end [y, limit]= HRT_Search(HRT,block.Dwork(1).Data,PM,num_PM); if limit>0 limiting_input=HRT_struct(PM).Input_Name(limit,:); limiting_input; else limiting_input='none'; end %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% Change the Block Background Color - assiciated with RM (resource mode) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %set big rectangle colour according to output rm_old=get_param(gcb, 'BackgroundColor'); if y≥0.85*base rm='[0, 1, 0]'; elseif y≥0.7*base rm='[0, 1, 1]'; elseif y≥0.45*base rm='[1, 1, 0]'; elseif y≥0.26*base rm='[1, 0.5, 0]'; else rm='[1, 0, 0]'; end % Compare old color with new one if ( strcmp('white',rm_old) ) set_param(gcb, 'BackgroundColor', rm); if block.DialogPrm(4).Data==1 set_param(gcs,'SimulationCommand','pause'); end else if (strcmp('orange',rm_old)) vec_rm_old=[1 0.5 0]; else vec_rm_old = eval(rm_old);  72  Appendix B. HRT MATLAB System Function Code 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152  end vec_rm = eval(rm); if( sum(vec_rm = vec_rm_old) ) set_param(gcb, 'BackgroundColor', rm); if block.DialogPrm(4).Data==1 set_param(gcs,'SimulationCommand','pause'); end end end %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% Change the PM Background Color - assiciated with PM (physical mode) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Check if PM changed is_PM_changed = ( block.Dwork(3).Data = PM ); is_y_changed = (block.Dwork(4).Data = y); is_limit_changed =(block.Dwork(5).Data = limit); if (is_PM_changed||is_y_changed||is_limit_changed) %set small rectangle colour according to PM txt=['text(0.1,0.95,''PM=0' num2str(PM) ''')']; txt2='text(0.7,0.95,''{\bf\fontsize{12}Rated:}'',''texmode'',''on'')'; txt3=['text(0.75,0.85,''{\bf\fontsize{12}' rated '}'',''texmode'', ''on'')']; txt=[txt txt2 txt3]; if HRT(1,1)≥0.85*base code_om=['patch([0 0 0.5 0.5],[0.6 1 1 0.6], [0 1 0]), plot([-0.02 0.49 0.49],[0.61 0.61 1.02])',txt]; elseif HRT(1,1)≥0.7*base code_om=['patch([0 0 0.5 0.5],[0.6 1 1 0.6], [0 1 1]), plot([-0.02 0.49 0.49],[0.61 0.61 1.02])',txt]; elseif HRT(1,1)≥0.45*base code_om=['patch([0 0 0.5 0.5],[0.6 1 1 0.6], [1 1 0]), plot([-0.02 0.49 0.49],[0.61 0.61 1.02])',txt]; elseif HRT(1,1)≥0.26*base code_om=['patch([0 0 0.5 0.5],[0.6 1 1 0.6], [1, 0.5, 0]), plot([-0.02 0.49 0.49],[0.61 0.61 1.02])',txt]; else code_om=['patch([0 0 0.5 0.5],[0.6 1 1 0.6], [1 0 0]), plot([-0.02 0.49 0.49],[0.61 0.61 1.02])',txt]; end  153 154 155  port_labels = []; for k = 1: block.Dwork(2).Data  73  Appendix B. HRT MATLAB System Function Code 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197  port_labels = [port_labels ',port_label(''input'',' num2str(k) ', ''in' num2str(k) ''')'] ; end port_labels = [port_labels ',port_label(''input'',' num2str(k+1) ', ''PM'')']; port_labels = [port_labels ',port_label(''output'',1,''out''), port_label(''output'',2,''{\bf\fontsize{13}NEED:' limiting_input'} '',''texmode'',''on'')']; set_param(gcb, 'MaskDisplay',[ code_om port_labels ]); if block.DialogPrm(4).Data==1 set_param(gcs,'SimulationCommand','pause'); end if isPMInternal block.Dwork(3).Data = block.DialogPrm(3).Data; else block.Dwork(3).Data = block.InputPort(block.Dwork(2).Data+1).Data; end block.Dwork(4).Data=y; block.Dwork(5).Data=limit; end %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% Code for the Pause feature, for everytime the HRT output or PM changes %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% block.OutputPort(1).Data = y; block.OutputPort(2).Data = limit; function [y, limit] = HRT_Search(HRT,x,PM,num_PM) if num_PM ≥ PM && PM > 0 table=HRT; %find the size of HRT [r, c]=size(table); k=1; trig=-1; %tag that changes to 1 when limiting factor is found %in the column temp_row=1;%limiting factor position limit_input=1; %starts from the first column of input and goes down the row until %it finds the entry that is lower than the input(limiting factor) for n=2:c while k≤r && trig==-1 if table(k,n)≤x(n-1) trig=1; if temp_row=k  74  Appendix B. HRT MATLAB System Function Code limit_input=n-1;%limiting input end temp_row=k;%the row limiting factor was found  198 199 200  end k=k+1;  201 202  end trig=-1;%tag resetted to -1 for next column k=k-1;  203 204 205  end y=table(temp_row,1);%output at the row limiting factor was found %when all inputs are equal to or above the maximum capacity of %the cell, limiting factor is zero. if temp_row=1 limit=limit_input;%limiting input else limit=0; end %When there is a negative entry in the HRT, output and limit will %set to unreasonable number to indicate it.  206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234  else feval('error','Unavailable Operating Mode'); y=0; limit=0; end function PostPropagationSetup(block) %% Work vector (persistent data) block.NumDworks = 5; HRT_struct = evalin('base',block.DialogPrm(1).Data); [dummy, num_PM]=size(HRT_struct); temp=HRT_struct.HRT; [nr,nc] = size(temp); InputDimension = nc - 1; block.Dwork(1).Name = 'x'; block.Dwork(1).Dimensions = InputDimension; block.Dwork(1).DatatypeID = 0; block.Dwork(1).Complexity = 'Real'; block.Dwork(1).UsedAsDiscState = true;  235 236 237 238 239  block.Dwork(2).Name = 'InputDimension'; block.Dwork(2).Dimensions = 1; block.Dwork(2).DatatypeID = 0; block.Dwork(2).Complexity = 'Real';  75  Appendix B. HRT MATLAB System Function Code 240  block.Dwork(2).UsedAsDiscState = true;  241 242 243 244 245 246  block.Dwork(4).Name = 'OldY'; block.Dwork(4).Dimensions block.Dwork(4).DatatypeID block.Dwork(4).Complexity block.Dwork(4).UsedAsDiscState  = = = =  1; 0; 'Real'; true;  block.Dwork(3).Name = 'OldPM'; block.Dwork(3).Dimensions block.Dwork(3).DatatypeID block.Dwork(3).Complexity block.Dwork(3).UsedAsDiscState  = = = =  1; 0; 'Real'; true;  247 248 249 250 251 252 253 254 255 256 257 258  block.Dwork(5).Name = 'Oldlimit'; block.Dwork(5).Dimensions = 1; block.Dwork(5).DatatypeID = 0; block.Dwork(5).Complexity = 'Real'; block.Dwork(5).UsedAsDiscState = true;  259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274  function Start(block) HRT_struct = evalin('base',block.DialogPrm(1).Data); [dummy, num_PM]=size(HRT_struct); temp=HRT_struct.HRT; [nr,nc] = size(temp); InputDimension = nc - 1; block.Dwork(1).Data = zeros(InputDimension,1); block.Dwork(2).Data = InputDimension; block.Dwork(4).Data=-1; isPMInternal = block.DialogPrm(2).Data-1; if isPMInternal block.Dwork(3).Data = -1; else block.Dwork(3).Data = block.InputPort(block.Dwork(2).Data+1).Data; end  76  Appendix C  Distributor MATLAB System Function Code 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29  function distributor_sfun(block) setup(block); function setup(block) try is_OM_Internal = block.DialogPrm(2).Data; if (is_OM_Internal == 0) % In this case, add an input port for the OM numInPorts = 2; else % otherwise numInPorts = 1; end catch numInPorts = 1; end %% Register number of input and output ports block.NumInputPorts = numInPorts; for k = 1:numInPorts block.InputPort(k).Complexity = 'Real'; block.InputPort(k).DataTypeId = 0; block.InputPort(k).SamplingMode = 'Sample'; block.InputPort(k).Dimensions = 1; end %% Setup functional port properties to dynamically %% inherited. block.SetPreCompInpPortInfoToDynamic; block.SetPreCompOutPortInfoToDynamic; %% Dynamically adjusting the dimension of the output according to %% available distribution factors  77  Appendix C. Distributor MATLAB System Function Code 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71  isDistManual = block.DialogPrm(1).Data; if isDistManual OutputDimension = length(block.DialogPrm(5).Data); else HRT_name = block.DialogPrm(3).Data; HRT_struct = evalin('base',HRT_name); temp=HRT_struct.HRT; [nr,nc] = size(temp); OutputDimension = nc - 1; end block.NumOutputPorts = OutputDimension; for k = 1:OutputDimension block.OutputPort(k).Complexity = 'Real'; block.OutputPort(k).DataTypeId = 0; block.OutputPort(k).SamplingMode = 'Sample'; block.OutputPort(k).Dimensions = 1; end %% Register parameters % 1 - Flag for manual or automatic operation; % 2 - Flag for internal or external OM; % 3 - Human Readable Table; % 4 - OM; % 5 - distribution factors; block.NumDialogPrms = 5; block.DialogPrmsTunable = {'Tunable','Tunable','Tunable','Tunable', 'Tunable'}; %% Set block sample time to inherited block.SampleTimes = [-1 0]; %% Run accelerator on TLC block.SetAccelRunOnTLC(false); %% Register methods block.RegBlockMethod('CheckParameters', @CheckPrms); block.RegBlockMethod('SetInputPortSamplingMode',@SetInputPortSamplingMode); block.RegBlockMethod('Outputs', @Output); function CheckPrms(block) flagManual = block.DialogPrm(1).Data; function Output(block) % Read parameters isOMInternal = block.DialogPrm(2).Data; if isOMInternal OM = block.DialogPrm(4).Data; else  78  Appendix C. Distributor MATLAB System Function Code 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107  OM = block.InputPort(2).Data; end isDistManual = block.DialogPrm(1).Data; x = block.InputPort(1).Data; if isDistManual factors = block.DialogPrm(5).Data; y = x*factors; else HRT_name = block.DialogPrm(3).Data; HRT_struct = evalin('base',HRT_name); HRT=HRT_struct(OM).HRT; y = HRT_Search(HRT,x); end for k=1:length(y) block.OutputPort(k).Data = y(k); end function y = HRT_Search(HRT,x) if ¬isempty(HRT) [r,c] = size(HRT); % Check x dimension if (length(x) = 1) feval('error','DISTRIBUTOR ERROR: There must be only one input into a distributor'); end % Checking if operating mode inputted is actually available in HRT %struct table = HRT; % Find the row that best approximate the input [xmin,idx] = min(abs(x-table(:,1))); y = x.*table(idx,2:c); else y = 0; end function SetInputPortSamplingMode(block,port,mode) block.InputPort(port).SamplingMode = mode; block.OutputPort(port).SamplingMode = mode;  79  Appendix D  Channel MATLAB System Function Code 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29  function hrt_sfun(block) setup(block); function setup(block) block.NumInputPorts = numInPorts; block.NumOutputPorts = 3; %% Setup functional port properties to dynamically %% inherited. block.SetPreCompInpPortInfoToDynamic; block.SetPreCompOutPortInfoToDynamic; block.OutputPort(1).Dimensions = 1; block.OutputPort(2).Dimensions = 1; block.OutputPort(3).Dimensions = 1; block.InputPort(1).DImensions = 1; %% Register parameters % 1 - HRT block.NumDialogPrms = 2; block.DialogPrmsTunable = {'Tunable','Tunable'}; %% Set block sample time to inherited block.SampleTimes = [-1 0]; %% Run accelerator on TLC block.SetAccelRunOnTLC(false); %% Register methods block.RegBlockMethod('Start', @Start); block.RegBlockMethod('PostPropagationSetup', @PostPropagationSetup); block.RegBlockMethod('Outputs', @Output); block.RegBlockMethod('SetInputPortSamplingMode',@SetInputPortSamplingMode); function SetInputPortSamplingMode(block, idx, fd) block.InputPort(idx).SamplingMode = fd; block.OutputPort(1).SamplingMode = fd;  80  Appendix D. Channel MATLAB System Function Code 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71  block.OutputPort(2).SamplingMode = fd; block.OutputPort(3).SamplingMode = fd; function Output(block) % Read parameters OM = block.InputPort(1).Data; HRT_struct = block.DialogPrm(1).Data; HRT=HRT_struct.HRT; is_OM_changed = ( block.Dwork(1).Data = OM ); if (is_OM_changed) capacity=max(HRT(OM,1)); if capacity≥0.85 code='[0, 1, 0]'; elseif capacity≥0.7 code='[0, 1, 1]'; elseif capacity≥0.45 code='[1, 1, 0]'; elseif capacity≥0.26 code='[1, 0.5, 0]'; else code='[1, 0, 0]'; end set_param(gcs, 'BackgroundColor', code) token=HRT_struct.Token; txt=['text(0.5,0.9,''PM=0' num2str(OM) ''',''texmode'',''on'')']; txt2=[txt 'text(0.5,0.5,''{\bf\fontsize{13}' token '}'', ''texmode'',''on'')']; txt3=[txt2 ',port_label(''input'',2, ''PM'')']; set_param(gcs,'MaskDisplay',txt3); block.Dwork(1).Data = block.InputPort(1).Data; if block.DialogPrm(2).Data==1; set_param(bdroot(gcb),'SimulationCommand','pause'); end end [a, tal, y_max]= HRT_Search(HRT,OM); block.OutputPort(1).Data = a; block.OutputPort(2).Data = tal; block.OutputPort(3).Data = y_max; function [a, tal, y_max] = HRT_Search(HRT,OM) a=HRT(OM,1); tal=HRT(OM,2); y_max=HRT(OM,3); function PostPropagationSetup(block)  81  Appendix D. Channel MATLAB System Function Code 72 73 74 75 76 77 78 79  block.NumDworks = 1; block.Dwork(1).Name = 'OldOM'; block.Dwork(1).Dimensions block.Dwork(1).DatatypeID block.Dwork(1).Complexity block.Dwork(1).UsedAsDiscState function Start(block) block.Dwork(1).Data = -1;  = = = =  1; 0; 'Real'; true;  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:
http://iiif.library.ubc.ca/presentation/dsp.24.1-0064885/manifest

Comment

Related Items