UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

A web service based disaster response interface for the DR NEP platform Wang, Tiange 2012

You don't seem to have a PDF reader installed, try download the pdf

Item Metadata

Download

Media
[if-you-see-this-DO-NOT-CLICK]
ubc_2012_fall_wang_tiange.pdf [ 4.27MB ]
Metadata
JSON: 1.0072996.json
JSON-LD: 1.0072996+ld.json
RDF/XML (Pretty): 1.0072996.xml
RDF/JSON: 1.0072996+rdf.json
Turtle: 1.0072996+rdf-turtle.txt
N-Triples: 1.0072996+rdf-ntriples.txt
Original Record: 1.0072996 +original-record.json
Full Text
1.0072996.txt
Citation
1.0072996.ris

Full Text

A WEB SERVICE BASED DISASTER RESPONSE INTERFACE FOR THE DR NEP PLATFORM by Tiange Wang B.Eng., University of Victoria, 2008 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENT FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in  The Faculty of Graduate Studies  (Electrical & Computer Engineering) THE UNIVERSITY OF BRITISH COLUMBIA (Vancouver)  August 2012 © Tiange Wang, 2012  Abstract The Infrastructure Interdependencies Simulation (I2Sim) team led by Dr. José R. Martí at the University of British Columbia has been researching the hidden interdependencies between complex infrastructures for several years [1]. The I2Sim platform was developed on the foundation of Matlab Simulink and has been significantly improved by researchers and engineers since the first version of the toolbox created in 2007 [2]. The current version of the I2Sim toolbox has versatile capabilities on many applications such as disaster response, resource optimization, financial management, etc. For disaster response application, in particular, the I2Sim team has formed a group of engineers in cooperation with the University of Western Ontario and the University of New Brunswick to develop the Disaster Response Network Enabled Platform (DR NEP). DR NEP is a distributed platform that communicates through an Enterprise Service Bus (ESB) utilizing the state-of-the-art Lightpath services provided by CANARIE [3]. With advanced computing power and high speed network connections, DR NEP is able to integrate I2Sim with other simulators and services, which are physically located all over Canada, to perform real time simulations and provide decision support for emergency responders. To further enhance user experience and improve the user interface for emergency responders, Web services were used in the project to create a web-based platform to display the simulation results on web pages and GIS systems, such as Google Earth. This platform enables responders to update and exchange information from standard web browsers and Google Earth. Simulation experts can use the website to control simulation and view simulation results and feedback from the website. A test case which involves the 2011 Tohoku earthquake incident in Japan is included in this report to demonstrate the simplicity of the user interface and the contribution of the web service to DR NEP. In addition, “what-if” scenarios were conducted on the model to explore better emergency responding strategies. The results from the simulation were studied and analyzed in detail. DR NEP is a fully functioning platform with complete components. With sufficient information provided by emergency responders or local resource management facilities, a complete model can be constructed for simulation and study. The next phase of the development would be model automatic creation, ergonomic user interface design, improvement on role-based access and model validation methodology development. Recommendations to those problems are included accordingly. As a member of the DR NEP team, I have been involved in most of the phases of the platform development. My main contribution to the team includes designing part of the table structures in database schema, implementing the web services for data visualization (Google Earth and the associated web services) and constructing the Japan Sendai City model.  ii  Table of Contents Abstract ......................................................................................................................................................... ii Table of Contents ......................................................................................................................................... iii List of Tables ................................................................................................................................................. v List of Figures ............................................................................................................................................... vi Acknowledgement ..................................................................................................................................... viii Dedication .................................................................................................................................................... ix 1 Introduction ............................................................................................................................................... 1 1.1  Initiative ........................................................................................................................................ 1  1.2  I2Sim Ontology .............................................................................................................................. 3  1.2.1 Concept of Interdependency ....................................................................................................... 3 1.2.2 Summary of I2Sim Ontology ........................................................................................................ 4 1.2.3 I2Sim Toolbox Description ........................................................................................................... 6 1.3  DR NEP Concept .......................................................................................................................... 16  1.3.1 Motivation.................................................................................................................................. 16 1.3.2 General Structure of DR NEP ..................................................................................................... 17 2 DR NEP and Web Services ........................................................................................................................ 19 2.1 Pre-development Decisions .............................................................................................................. 19 2.1.1 Software Stack ........................................................................................................................... 19 2.2.2 Standards, Technologies and Development Environment ........................................................ 20 2.2 Software Architecture ....................................................................................................................... 21 2.2.1 Database .................................................................................................................................... 21 2.2.2 Web Service Architecture .......................................................................................................... 25 2.3 Web Interface and Google Earth ...................................................................................................... 32 2.3.1 Web Interface Design................................................................................................................. 32 2.3.2 Google Earth .............................................................................................................................. 39 3 Case Study ................................................................................................................................................ 47 3.1 Case Background ............................................................................................................................... 47 3.2 Modeling Methodology .................................................................................................................... 48 3.2.1 Information Collection ............................................................................................................... 48 iii  3.2.2 Historical Time Line Formulation ............................................................................................... 49 3.2.3 Model Scenario Development ................................................................................................... 50 3.2.4 Implement Model Concept ........................................................................................................ 50 3.2.5 I2Sim Model Implementation .................................................................................................... 53 3.2.6 DR NEP Integration .................................................................................................................... 59 3.2.7 Historical Validation/Verification ............................................................................................... 60 3.2.8 “What-If” Scenarios ................................................................................................................... 61 4 Conclusion ................................................................................................................................................ 63 4.1 Contribution to Disaster Response System....................................................................................... 63 4.2 Future Work ...................................................................................................................................... 63 Bibliography ................................................................................................................................................ 65 Appendices.................................................................................................................................................. 67 Appendix A: Sample Code for Web Service of Setting Distribution Value.............................................. 67 Appendix B: Sample Code for the KML Generation ................................................................................ 84  iv  List of Tables Table 1 Large Disaster Events over the Period 2000–2010 Impacting on Cities [4] [6] ................................ 2 Table 2 Power Resource Allocation Comparison .......................................................................................... 3 Table 3 Critical Infrastructures Which Involved in I2Sim Models [7]............................................................ 5 Table 4 Sample HRT in Hospital (data is modified from the original version and is only for demonstration purposes) [9] ................................................................................................................................................. 9 Table 5 Functionality of Infrastructure Associated with Different Colours ................................................ 10 Table 6 Development Technologies Decisions [14] .................................................................................... 21 Table 7 KML and JAK Specification ............................................................................................................. 40 Table 8 List of Icons Used in DR NEP KML Model ....................................................................................... 43 Table 9 Historical Timeline in Sendai City during Disaster [25] .................................................................. 50 Table 10 Hospital Aggregation in Sendai Region ........................................................................................ 53 Table 11 Strategies for Electricity Distribution in What-If Scenario [27] .................................................... 61  v  List of Figures Figure 1 Illustration of Interdependencies [8] .............................................................................................. 4 Figure 2 I2Sim Toolbox Library...................................................................................................................... 6 Figure 3 Production Cell and its Property Panel ........................................................................................... 7 Figure 4 Colour Scheme for PM and RM [7] ............................................................................................... 10 Figure 5 Colour Display on Production Cell................................................................................................. 10 Figure 6 Aggregator and its Property Panel ................................................................................................ 11 Figure 7 Delay Channel and its Property Panel ........................................................................................... 12 Figure 8 Distributor and its Property Panel ................................................................................................ 13 Figure 9 Source and its Property Panel ....................................................................................................... 14 Figure 10 Storage and its Property Panel ................................................................................................... 15 Figure 11 Visualization and Control Panel .................................................................................................. 16 Figure 12 DR NEP Structure ........................................................................................................................ 18 Figure 13 Current Database Schema for DR NEP ........................................................................................ 24 Figure 14 DR NEP Web Service Architecture .............................................................................................. 26 Figure 15 Struts Work Flow (Eg. Set Physical Mode for Electrical Substation) ........................................... 27 Figure 16 SDO Generation Process [21] ...................................................................................................... 29 Figure 17 DR NEP Login Page ...................................................................................................................... 33 Figure 18 Simulation Selection Page ........................................................................................................... 34 Figure 19 Simulation Result Page................................................................................................................ 34 Figure 20 Simulation Specification Page ..................................................................................................... 35 Figure 21 Simulation Control Panel ............................................................................................................ 36 Figure 22 Simulation Result 1 ..................................................................................................................... 37 Figure 23 Simulation Result 2 ..................................................................................................................... 37 Figure 24 Model Components .................................................................................................................... 38 Figure 25 Detail Report of Hospital Component......................................................................................... 39 Figure 26 KML Generation Process ............................................................................................................. 41 Figure 27 KML Demo Model ....................................................................................................................... 41 Figure 28 Update Physical Mode of the Venue (part 1) ............................................................................. 44 Figure 29 Update Physical Mode of the Venue (part 2) ............................................................................. 44 Figure 30 Set Distribution Ratio 1 ............................................................................................................... 45 Figure 31 Set Distribution Ratio 2 ............................................................................................................... 46 Figure 32 Channel Delay Update 1.............................................................................................................. 46 Figure 33 Channel Delay Update 2.............................................................................................................. 47 Figure 34 DR NEP Modeling Methodology [25] .......................................................................................... 48 Figure 35 Disaster Zones ............................................................................................................................. 51 Figure 36 Impact Zones ............................................................................................................................... 51 Figure 37 Concept Model for Sendai City ................................................................................................... 52 Figure 38 I2Sim Model Overview ................................................................................................................ 56 Figure 39 Resource Section of Sendai Model ............................................................................................. 57 vi  Figure 40 Impact Zone Section of Sendai Model ........................................................................................ 57 Figure 41 Emergency Responders Section of Sendai Model ...................................................................... 58 Figure 42 Hospital Section of Sendai Model ............................................................................................... 58 Figure 43 Shelter Section of Sendai Model ................................................................................................. 58 Figure 44 Screenshot of Sendai City KML Model Loaded on Google Earth ................................................ 59 Figure 45 A Close Look at the Facilities in Sendai City KML Model............................................................. 60 Figure 46 Observation on Discharged Patient Rate Based on Different Distribution Strategies [27] ........ 62  vii  Acknowledgement I would like to take this chance to express my utmost gratitude to my supervisor Dr. José R. Martí for providing me the opportunity to work under his supervision and guiding me through every academic challenge. Without the support from Dr. Martí, I would not be able to hurdle the obstacles and complete my research work in this short amount of time. During the past two years of my graduate studies, I have received many help and support from my mentors. I am very grateful to Dr. K.D. Srivastava for the invaluable feedback and suggestions he provided on my research and project work. I also want to give my devout appreciation to Dr. Paul Lusina for making all DR NEP project related documentation accessible to me. These documents are precious resources for constructing my thesis. I would also like to thank all the members in I2Sim team. Throughout my research, every member has dedicated their valuable time for me to answer my questions and to help me improve. Special thanks to my teammates: Pranab Kini, for helping me on the web service implementation; Marco Gonzalez, for explaining the database structure; Cesar Lopez, for solving my doubt on I2Sim ontology; Mohammed Khouj, for broaden my knowledge on machine learning. Last but not the least; I would give my most sincere appreciation to my parents for being there for me unconditionally.  viii  Dedication  DEDICATED TO MY PARENTS  ix  1 Introduction The subject of this thesis is to contribute to the development of the Disaster Response Network Enabled Platform (DR NEP), which is a system that utilizes multiple simulators to perform real time simulation and provide suggestions to emergency responders. The research and development of this project has been completed by a sub-division of the Infrastructure Interdependencies Simulation (I2Sim) group led by Dr. José R Martí from the University of British Columbia in cooperation with the University of Western Ontario and the University of New Brunswick. The DR NEP architecture consists of an Enterprise Services Bus (ESB), a database, simulators (includes I2Sim) and a web interface. Each component of the platform will be introduced in the following sections.  1.1 Initiative In the past decade, unexpected natural disasters have had catastrophic impacts on many countries all over the world. In May 12, 2008, an earthquake in Sichuan, China took over 80,000 people’s lives and caused 85 billion US dollars of damages [4]. In January 12, 2010, an earthquake in Haiti was rather devastating. Over 220,000 people died in the disaster and the economic damage was too large to estimate [4]. Just little over a year, a tsunami in Japan killed 15,467 people as of June 20, 2011 in Tohoku region and countless numbers of the people were affected [5]. Table 1 has listed world’s worst disasters over the past 10 years. It is certainly painful to look over the data knowing that innocent people suffered from these unpredictable natural disasters. Even though the random characteristics of natural disasters cannot be altered or controlled it is possible of minimizing the damage and loss after the impact. Rapid rescuing processes, correct allocation of limited resources and effective communication are the key of success in this battle against nature. In order to address issues that are very vital to disaster management, DR NEP was developed to provide support to disaster management experts. By looking into the interdependencies between facilities, available resources and capability of supply in each facility, DR NEP can determine an optimal distribution of available response resources to minimize damage and to improve the rescue process.  1  Table 1 Large Disaster Events over the Period 2000–2010 Impacting on Cities [4] [6]  Popular name  Main countries affected  Japan earthquake  Japan  Haiti earthquake  Haiti  Sichuan earthquake  China  Cyclone Nargis  Myanmar  Java earthquake  Indonesia  Kashmir earthquake  Pakistan United States  Hurricane Katrina Mumbai floods  South Asian tsunami  Bam earthquake  India Indonesia, Sri Lanka, India, Thailand, Malaysia, Maldives, Myanmar  European heatwave  Iran Italy, France, Spain, Germany, Portugal, Switzerland  Dresden floods  Germany  Gujurat earthquake  India  Date of event  Type of hazard  11 March Earthquake and tsunami 2011. 12 January 2010. Earthquake  12 May 2008. 2 May 2008. 27 May 2006. 8 October 2005. 29 August 2005. 26 July 2005.  Main cities affected Sendai, Ichihara, Fukushima, Minamisanri ku, Onagawa, Rikuzentaka ta, Ofunato, Kesennuma Port-auPrince Beichuan, Dujiangyan, Shifang, Mianzhu, Juyuan, Jiangyou, Mianyang, Chengdu, Qionglai, Deyang  Earthquake Tropical cyclone Yangon  Earthquake Yogyakarta Muzaffaraba Earthquake d Tropical New cyclone Orleans Flood  Mumbai  Banda Aceh, Chennai 26 December Earthquake (some 2004. and tsunami damages) 26 December 2003. Earthquake Bam  Summer 2003 11 August 2002. 26 January 2001.  Extreme heat Flood  Various  Dresden Bhuj, Earthquake Ahmedabad  Total number of Total number of deaths affected  Total damages US$  5178 (As of 17.03.2011) Not yet known  Not yet known  222,570  3,400,000  n/a  87,476  45,976,596  85 billion  138,366  2,420,000  4 billion  5,778  3,177,923  3.1 billion  73,338  5,128,000  5.2 billion  1,833  500,000  125 billion  1,200  20,000,055  3.3 billion  226,408  2,321,700  9.2 billion  26,796  267,628  500 million  72,210  Not reported  Not reported  27  330,108  11.6 billion  20,005  6,321,812  2.6 billion  2  1.2 I2Sim Ontology 1.2.1 Concept of Interdependency In order to understand the architectural design of DR NEP, the concept of I2Sim and its associated ontology needs to be explained first. I2Sim is the abbreviation of “Infrastructure Interdependencies Simulation”. Lee provides an excellent explanation of the concept of infrastructure interdependencies [7]: The behavior of infrastructure systems such as power, water, and gas networks is highly nonlinear 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. The illustration in Figure 1 explains the concept of interdependency in a rather simple way. Imagine that before a disaster occurs, a hospital is operating at normal conditions with power and water supplied by an electrical substation and a water pumping station respectively. In addition, in order for the water pumping station functions under normal condition, it requires the electrical substation to distribute a certain percentage of power to this water facility. When a disaster occurs, with regards to resources allocation, hospitals are often ranked as the highest priority facility by emergency responders and disaster management experts. During disasters, the hospital receives a large volume of patients and it is critical to satisfy the hospital demands in order to process triage more efficiently. This resource allocation strategy seems to be rational; however, even experts often miss the interdependencies among the facilities. For instance, Table 2 shows the power distribution at the pre-disaster condition and post disaster condition. Under normal conditions, the water pumping station and the hospital operates just fine with the 50-50 distribution. However, during the disaster, power distribution has been prioritized towards the hospital. In this case, the water pumping station only receives 20% of the power (compared to 50% in the pre-disaster case) and, therefore cannot supply enough water to the hospital. The consequence of this power allocation change is that the hospital will operate at a low efficiency due to lack of water supply. Table 2 Power Resource Allocation Comparison  Power to Hospital Power to Water Station  Pre-Disaster Distribution 50% 50%  Post-Disaster Distribution 80% 20%  The purpose of this example is to demonstrate how interdependency works in I2Sim. It is obvious that the case presented here is overly simplified compare to a real life scenario. The reader may question, with such small scale system, is it really necessary to build such a complex model to determine the 3  interdependency? If disaster responders and disaster management experts are experienced enough, would it be possible for them to make the right call even without the aid of I2Sim? The answer is positive. However, imagine the scale of the system multiplies by a factor of twenty, thirty or even a hundred. It is obvious that the math behind the system is far beyond the computation power of a human brain. I2Sim, on the other hand, could run the simulation and look into every bit of the relationship between all facilities in real time and provide suggestions instantly. As the system gets bigger, the power and convenience of I2Sim will begin to manifest.  Figure 1 Illustration of Interdependencies [8]  1.2.2 Summary of I2Sim Ontology I2Sim is powerful enough to model almost any infrastructure. Just to illustrate the capability of the tool, the current and previous works of I2Sim modeling have already included the critical infrastructures in Table 3. The infrastructures presented are highly complex and do not share many common characteristics. How to model the interdependency between all these infrastructures without touching upon the details of each facility (ex. operation, internal resource distribution and etc.) and unifying the process becomes a particularly challenging problem.  4  Table 3 Critical Infrastructures Which Involved in I2Sim Models [7]  Model UBC Campus Test Case  Vancouver 2010 Winter Olympics Case  UWO Steam Plant Case Japan Earthquake & Tsunami City of Sendai Case  Critical Infrastructures Involved (First two models list are obtained from Lee’s thesis) Hospital, Water Station, Fire Hall, Telecom Generator, Ambulance Services, Transportation, RCMP, Food Services, Classroom and Library, Commercial, Research Lab and Museum, Residential, Administrator, Parking Lots, Services and Utility, Recreation and Society, Power House, Substation, Steam Station. BC Place, GM Place, Cathedral Square Substation, Dal Grauer Substation, Sperling Substation, Murrin Substation, Water Station, Vancouver General Hospital, St. Paul’s Hospital. Boiler, Power Plant, Water Treatment, Condenser, Campus, Water Supply, Hospital, Electrical Supply Power Stations, Impact Zones, Ambulance Dispatch, Emergency Vehicle Dispatch, Water Station, Aggregated Hospitals, Aggregated Shelters.  One approach to solve this problem is to look at the system at a higher level and only deal with the properties of the facilities that are required by the simulation. In I2Sim, a set of common ontology is developed to describe similar types of functions in different infrastructures [9]. There are four categories are currently defined in the I2Sim ontology [9]. 1. Cells: Also known as Production Cells. It is the type of infrastructure that takes inputs which are generated from other facilities or Sources and converts them into a product. The process of this “transfer” or “production” involves a new concept called “Human Readable Table” (HRT), which is going to be introduced in the next section. 2. Token: The input and output of the cells are treated as tokens. Each type of token has its own unit and all tokens can be counted in per-unit. 3. Channels: It is an infrastructure that transports tokens from one cell to another. For example, Channels for electricity are transmission lines; Channels for water are water pipes; Channels for patients are ambulances. 4. Controls: Controls involve both Distributors and Aggregators. Just as the name implies, Distributor send tokens through Channels to different Production Cells. Aggregators add tokens of the same type from different resources to one and typically feed into an Production Cell.  5  1.2.3 I2Sim Toolbox Description The ontology of I2Sim was introduced in the previous section was implemented in Matlab Simulink as an I2Sim toolbox library. Figure 2 shows the complete I2Sim toolbox collection. Each element will be briefly introduced in this section since the blocks are self-explanatory. Detailed implementation and functionality of those components can be found in Liu’s and Lee’s thesis [2] [7].  Figure 2 I2Sim Toolbox Library  6  1. Production Cell  Figure 3 Production Cell and its Property Panel  The Production Cell, which was referred as “cell” in the previous section, is the core component of the toolbox as it represents the critical infrastructures that take different set of tokens to produce a single output of a certain token type. The Production Cells cannot be explained without introducing few core concepts, including “Human Readable Table” (HRT), “Physical Mode” (PM) and “Resource Mode” (RM). An HRT is a structure that defines the relationship between the input tokens and the output token. It is the “equation” that links all the variables. Since these relationships are highly nonlinear in the real world, a table structure is designed to address this problem. Table 4 is a sample HRT that illustrates the concept of the structure. Take the first sub-table as example, the first row indicates that it requires 20 MW of electricity, 51 KL/hour of water, 3333 ft3/hour of natural gas and 100% of the base unit of medical gasses to ensure the patient discharge rate is at 10 patients/hour. The patient discharge rate decreases when any of the resources decrease. For 7  instance, at row two, all available resources are decreased by certain amounts; the patient discharge rate is also decreased to 8 patients/hour, accordingly. Note that, even though the HRT is implemented almost in all function blocks, at the current stage of development of I2Sim only Production Cells and Distributors are utilize with the structure. Physical Modes represent the physical condition of a facility or infrastructure. During a disaster, buildings or machines may suffer from different degrees of damage. Consequently, this results in limitations on the functionality of the facilities. In I2Sim, Physical Modes have been discretized to five different levels. Physical Mode 1 (PM1) represents 100% functionality. Physical Mode 5 (PM5) indicates the infrastructure has been completely damaged and cannot produce any token. In Table 4, the five sub-tables represent the HRT under five different Physical Modes. Take PM2 for instance, the maximum patient discharge rate is at 8 patients/hour, which is the maximum rate that the hospital can archive under that level of physical condition (PM2, 75%). Note that the values in HRTs under different Physical Mode can be different, it is not necessary to keep consistency across different Physical Mode. For example, it is reasonable to assume that more water or electricity are required in a lower physical condition to achieve the same patient discharge rate as when the facility operates under 100% functionality. Even though sometimes a facility is operating at perfect conditions, it is possible that one or more of the resources that are required to produce the token are absent from the supply chain or are lower than the required demand. In such case, the facility will not be able to reach maximum capacity. This is the concept of Resource Mode (RM). During simulation, each available resource is compared against a column of predefined values, the one has the lowest rank determines the Resource Mode of the Production Cell. This resource becomes the “Limiting Factor” [10]. For example, if the hospital is operating in PM1, and the available electricity is 15MW, water is 25 KL/Hour, natural gas is 3500 ft3/hour and medical gas is at 75%; the discharged patients rate will drop to 3 patients/hour. In other words, the hospital is operating at RM4 and the limiting factor is water. The status of the PM and RM of a Production Cell in the I2Sim function block is distinguished by different colours. According to Lee, the colours used in I2Sim are inspired by the “Colour-coded Threat Level System of the U.S. Department of Homeland Security” [7]. Table 5 lists out what each colour represents in PM or RM. Figure 5 illustrates how PM and RM colours are displayed on Production Cells. The colours can change every time step during the simulation. In the later chapters of this thesis will demonstrate how the PM and RM can be changed through web services.  8  Table 4 Sample HRT in Hospital (data is modified from the original version and is only for demonstration purposes) [9]  PM1: Discharged Patients Rate (Patients/Hour)  Electricity (MW)  Water (KL/Hour)  Natural Gas (ft3/Hour)  Medical Gasses (%)  10 8 5 3 0  20 15 10 5 0  51 38 26 13 0  3333 2500 1667 833 0  100 75 50 25 0  Discharged Patients Rate (Patients/Hour)  Electricity (MW)  Water (KL/Hour)  Natural Gas (ft3/Hour)  Medical Gasses (%)  8 5 3 0  15 10 5 0  38 26 13 0  2500 1667 833 0  75 50 25 0  Discharged Patients Rate (Patients/Hour)  Electricity (MW)  Water (KL/Hour)  Natural Gas (ft3/Hour)  Medical Gasses (%)  5 3 0  10 5 0  26 13 0  1667 833 0  50 25 0  Discharged Patients Rate (Patients/Hour)  Electricity (MW)  Water (KL/Hour)  Natural Gas (ft3/Hour)  Medical Gasses (%)  3 0  5 0  13 0  833 0  25 0  Discharged Patients Rate (Patients/Hour)  Electricity (MW)  Water (KL/Hour)  Natural Gas (ft3/Hour)  Medical Gasses (%)  0  0  0  0  0  PM2:  PM3:  PM4:  PM5:  9  Figure 4 Colour Scheme for PM and RM [7] Table 5 Functionality of Infrastructure Associated with Different Colours  Colour Green Blue Yellow Orange Red  Functionality (PM or RM Value) 100% (1) 75% (2) 50% (3) 25% (4) 0% (5)  Figure 5 Colour Display on Production Cell  10  2. Aggregator  Figure 6 Aggregator and its Property Panel  The Aggregator behaves as a simple adder of the same type of tokens. A user can define the number of inputs in the property panel. 3. Channel The Delay Channel in I2Sim is analogous to a transmission line, water pipe, communication cable, evacuation route, etc. in the physical world. In an I2Sim model, cell blocks are connected using lines. Channels simulate delays and losses in these connecting lines. The Channel blocks take an input of tokens; hold the tokens within the block for a certain period of time and release them when the delay time expires. The delay time can be specified in the Channel property panel.  11  Figure 7 Delay Channel and its Property Panel  4. Distributor The Distributor is one of the critical components blocks in I2Sim because the main focus of I2Sim tool is to optimize distribution of resources by looking into interdependencies between different infrastructures. Many engineers and researchers spend hours on how to control the distribution flow in their systems so that it can maximize the outcome of the objective function. Distributors in I2Sim seek to achieve this function in a multi-system environment. Distributors have several ways to control the distribution. The simplest way is through manual control. The user only needs to predefine the ratio in the Distributor property panel. The down side of this method is that once the simulation begins, the ratio is fixed which obviously contradicts to the goal of optimizing the resources allocation. Another way is to set the ratio externally using the functionality of the HRTs. There is an input in the Distributor block called 12  “PM”. This defines the Physical Mode of the Distributor at a given time. At every time step, the Distributor will look into the particular Physical Mode setting based on the PM input. Knowing the available resources that feed into the Distributor, the HRT selects the appropriate Resource Mode and set the distribution ratio. There is a rather straightforward method to set the ratio through inputs. The third Distributor in Figure 8 has two extra inputs other than “in” shown as “f1” and “f2”. These two numbers define the ratio values of “o1” and “o2”. The value for “o3” is the remaining percentage after subtracting the value of “o1” and “o2” from 100%. All these methods of determining the distribution ratio are certainly convenient. The only down side is that once the ratio sets are defined, the values are not alterable during the entire simulation. Even though using the “PM” or “f1”,”f2” methods could possibly simulate a series of events with different ratio combination, these are still fixed pre-defined scenarios and not suitable for real life simulation. In order to address this problem, web services, which will be covered in the later section, are deployed to change the distribution ratio on the fly.  Figure 8 Distributor and its Property Panel  13  5. Source A Source outputs a certain type of token. In most cases, it represents a natural source in real life such as a hydro dam that supplies electricity or a water stations that supply drinking water. However, the Source can be also implemented as an immaterial object such as information or even a disaster like earthquake event. On the current I2Sim development, only natural resources are considered in the ontology. The name, unit and nominal output of the token can be configured in the Source property panel. In addition, a Source is always assumed as a constant and infinite output. Outage of a natural resource can be either paired with an infinite Delay Channel or use the Storage block instead.  Figure 9 Source and its Property Panel  6. Storage A Storage block is often referred to a sink or a container. It is very useful to represent a container with a limited amount of tokens. There is a wide range of uses for Storage. For 14  instance, a hospital waiting room, an ambulance dispatch, a backup electricity generator, a water reservoir, etc. can be represented by a Storage block. The Storage has an initial value which can be set in the property panel. The “in” tag in the Storage block takes an input at every time step and are keeps it in Storage. The “cmd” tag, which stands for command, is to determine how many tokens are flowing out from the Storage. “Level” and “surplus” are redundant information for the convenience of monitoring the Storage. Extra restrictions of the storage such as maximum level and minimum level can be aslo defined in the property panel. Storage is extensively used in the Japan Sendai model, which will be discussed in the use case section.  Figure 10 Storage and its Property Panel  15  7. Visualization & Control The Control and Visualization panel are mandatory for each I2Sim model. The Control panel is used to start, pause and stop the simulation. In addition, the simulation time, time step and time unit can be defined here. By default, all the blocks in the model, will inherit the same time step and units unless specified otherwise. The Visualization panel is a tool to display the simulation results. The model designer can place an I2Sim probe into a point of interest and observe the results throughout the simulation. The Visualization panel can be configured to multiple rows and columns layout and can group similar data together for comparison.  Figure 11 Visualization and Control Panel  1.3 DR NEP Concept 1.3.1 Motivation The advantage of using I2Sim to determine interdependencies between infrastructures is clearly established. I2Sim as a high level simulator has a broad range of usage in different areas. The Disaster Response Network Enabled Platform (DR NEP) on the other hand is a very specific application, which fully utilizes I2Sim targeting disaster response and recovery.  16  Many researchers are looking into ways to provide a platform for disaster responders to exchange information efficiently. With the aid of state-of-the-art super computing power, many facilities have the capability to perform real time or quasi real time simulation to assist disaster responders making decisions. However, those facilities, such as power station or water station can only provide feedback within their own system. Not only are the interdependencies missing, there is no unified platform for the disaster management experts to review the whole picture. Disaster responders need to gather information through different channel and evaluate these data based on their experience to decide evacuation plans and resources allocation. In the year of 2006, Hauenstein et al. introduced a real time cross-functional service-oriented architecture in emergency medical response that enables real-time information sharing between “Emergency Medical Service (EMS), Fire, and Police. Many health services facilities, including hospitals, auxiliary care centers and public health departments” using their Advanced Health and Disaster Aid Network (AID-N) [11]. This is a critical work for improving the interoperation between emergency response organizations [11]. After carefully evaluating existing similar platforms include Eden that was developed by Sahana Software Foundation [12], AID-N which was designed by the Johns Hopkins University Applied Physics Lab [11] and some other online information system such as infoasaid which is mainly focused on communications between emergency responders [13], researchers and engineers in the DR NEP team decided to develop a rather adaptive system. The system should encompass the following attributes: 1. Information should be exchanged through a unified bi-directional channel. 2. Components (simulators, web portal, sub-systems) of the system should be independent of each other, i.e. adding or removing a component from the system would not affect the normal operation of the system. 3. The Database structure should be constructed in a way that is universal to simulators, i.e. minimum effort should be required to add or delete any component from DR NEP. 4. There is a central user interface for disaster responders to view information and control the platform. 1.3.2 General Structure of DR NEP The basic structure of DR NEP shown in Figure 12 is designed based on the specification described in 1.3.1 Motivation section. The architecture of DR NEP ensures the encapsulation of all the required characteristics in to the blueprint. 1. An Enterprise Service Bus (ESB) is developed as the channel to the components in DR NEP. XML, as one of the most favorable markup languages used in web services, is utilized to carry information among different components. 2. Every Simulator has its own adaptor to the services. In this way, simulators have complete independence from others. If additional members would like to participate in DR NEP, only a simple adaptor (translator) and a web service needs to be created before it can communicate 17  with other simulators. Of course, I2Sim, as the primary simulator cannot be absent from the simulation. Otherwise, it would defeat the purpose of creating DR NEP in the first place. 3. All information gathered from each simulator is consolidated into the same type of data structure through web services. Therefore, only one database schema needs to be constructed for universal use. All data will be persisted in the “Database”, as shown in Figure 12. 4. There is a web portal and Google Earth KML models available to emergency responders. The web portal provides all information that the user requests and displays it according to the role of the responder. The Google Earth KML model gives the user a direct view of the disaster zone and all physical status of the infrastructure in that area.  Figure 12 DR NEP Structure  Over the next chapter, the detailed implementation of the DR NEP architecture will be introduced. The main focus is going to be the methodology of applying web services on disaster response.  18  2 DR NEP and Web Services The architectural design of the DR NEP structure was briefly introduced in the 1.3.2 General Structure of DR NEP section. In this chapter, the detailed implementation of the platform and the web services in DR NEP will be explained. The web services are designed with a complex multilayer structure. In order to provide a better explanation to the readers, a simple web service example of setting distribution ratios is described throughout the 2.2.2 Web Service Architecture section.  2.1 Pre-development Decisions Disaster response is a very demanding task. It requires responders to be highly professional and organized. As a tool to assist disaster responders to make critical decisions, DR NEP needs to be stable, efficient and secure. Therefore, choosing the right platform and the development kit to implement DR NEP becomes a vital decision. In addition, just like other software development, upgradability and scalability are needed to be considered from the beginning stage of the planning. As a partner of the I2Sim team, experts at IBM proposed an architectural solution implemented on an IBM existing state-of-the-art platform. With the collaboration between IBM developers and I2Sim engineers, the development environment was determined and summarized in the following section [14]. 2.1.1 Software Stack Operating System The operating system is the foundation and the core of the platform. All applications will be installed and run over the system. For a system like DR NEP, a Linux server seems be the obvious choice because of its well-known features, such as security, stability and expandability. Over many choices of Linux distributions, Red Had Enterprise Linux (RHEL) 5 was chosen for the following several reasons. IBM and Red Hat have had a long term partnership; IBM systems are enabled and fully tested running on RHEL [15]. This cooperation provides DR NEP with reliability and stability. In addition, Red Hat Enterprise Linux has been in the market for almost a decade and most commercial available software is fully compatible with the system. At the beginning phase of the project, RHEL 5 had been in the market for about three years, i.e., the product has been well examined by IT professionals and software developers. Even though RHEL 6 has many interesting features, it had only been released for few months. After comparing the advantages and disadvantages between the two versions, stability won over functionality and RHEL 5 (code: Tikanga) was chosen as the main operating system. Virtualization Platform The concept of virtualization discussed here is referring to the development environment virtualization. Since DR NEP is a collaboration project between UBC, UNB (University of New Brunswick), UWO 19  (University of West Ontario) and IBM, for developers and researchers reside in cities across Canada, a portable development is ideal. Instead of installing the operating system on bare metal (Directly installing the operating system on the machine, like the conventional way), RHEL 5 is installed in VMWare player and all associated development tools are configured properly on the system. The advantage is that VMWare player encapsulates the system in a transferrable file. The file can be moved to another machine and can be opened by the VMWare player installed on that machine. The process is completely independent from the host operating system. This way, the developer gets an identical copy of the operating system with all preset configurations. Of course, this is a short term solution for code development. When the project is launched in production mode, the system needs to be deployed in clusters. Those dedicated server clusters will provide much higher computing power and integrity of the system. Application Server and RDBMS The WebSphere Application Server (WAS) has been in the industry for over a decade. As one of IBM’s flagship products for service-oriented architecture (SOA), it has been deployed in many companies worldwide. The DB2 database is a high performance, scalable database solution from IBM that works seamlessly with the WebSphere Application Server. The WAS and DB2 combination are normally used in enterprise level application development. Implementing the I2Sim web service on such large scale architecture may seems unnecessary. However, the functionality of each layer or component in IBM SOA is well defined, which provides great structure for future expansion. Once the structure is defined, web services can be created with minimum effort and the process would become robotic. The version of the software used in DR NEP is the following: • •  Application Sever: WebSphere Application Server 7.0 RDBMS: DB2 9.5  2.2.2 Standards, Technologies and Development Environment Once software stacks are defined, all the remaining decisions are straightforward. The technologies, development tools and other related software are summarized in Table 6. Java Platform, Enterprise Edition is a widely used programming language for web services and the WebSphere Application Server is a fully certified environment for Java EE development. Many modules and packages in J2EE are available for web service implementation. The Rational Application Developer (RAD) is a dedicated Integrated Development Environment (IDE) for the WebSphere Application Server designed by IBM. To deploy all IBM certified tools and technologies reduce significantly the development time because developers do not need to consider compatibility issues. All items mentioned in Table 6 are standardized technologies and are well documented in the corresponding website. The discussion here does not intent to cover all aspects of these technologies; only the ones that are related to the DR NEP project will be presented.  20  Table 6 Development Technologies Decisions [14]  Technologies JavaEE SOAP JDK Unit Testing Development IDE Architect IDE Revision Control Defect Tracking System Virtual Machine Simulation GIS Rendering  Description 5 (in WAS 7.0) SOAP 1.2 with MTOM support for binary GIS objects 6 (in WAS 7.0) JUnit 4 Rational Application Developer (RAD) 7.5 – IBM Rational Software Architect (RSA) 7.5 -IBM Subversion TRAC: https://dev.ece.ubc.ca/projects/drnep/report VMWare Player Matlab Simulink I2Sim toolbox Google Earth, Google Map  2.2 Software Architecture Figure 12 in section 1.3.2 General Structure of DR NEP has already illustrated the basic architecture of DR NEP. The following section will provide detailed explanations to each element in the structure. 2.2.1 Database The database schema was designed to capture structure of I2Sim and its simulation data while remaining as generic as possible so that it could also store data from other simulators with minimum modification. A standard relational database design principle is used to define the schema. This data model has gone through iterations of refinements. One of the main database architects Gonzalez [16] has divided the database into three principle groups, including model group, scenario group and step group. The current database structure has been updated to five major categories, which are organizational group, model group, simulation group, port replication group and raw data group as shown in Figure 13. 1. Model group: This group is the core of the database. After an I2Sim model is constructed in Matlab Simulink, all information of the model that is going to be used in the web services is captured in this group. The MODEL table stores general information such as name, description and location of the I2Sim model. The geographic location of the model is captured in the LOCATION table. All physical infrastructures, including Production Cells, Channels, Sources and Distributors are categorized in the CRITICAL_INFRUSTRUCTURE table. This table is similar to a library of infrastructure that participated or will participate in simulations. The PHYSICAL_ENTITY table stores information of real infrastructures such as Lion’s Gate Bridge, UBC Electrical Substation, etc. Each physical entity is required to belong to one of the type in the CRITICAL_INFRUSTRUCTURE collection. The 21  PHYSICAL_ENTITY table is designed to be abstract enough to cover all the characteristics of these infrastructures. As mentioned in earlier sections of this thesis, different infrastructures play quite different roles in the simulation. The type identifier is a field called ENTITY_PLUG_TYPE. Note that the ENTITY_PLUG_TYPE of an infrastructure can be different than its CRITICAL_INFRUSTRUCTURE type, the former type only indicates what role it plays in a simulator. For example, a bridge can be a Channel or a Production Cell in a simulation depending on the different situation. The PHYSICAL_ENTITY table has several one-to-one and one-to-many child tables to capture miscellaneous information. Depending on the type of physical entity, some tables may not need to be used. This multi-table design can avoid an excess of redundant information to be stored in one table and slow down reading and writing operations. For example, if a physical entity is a Source or a Channel, it might not need to fill the PHYSICAL_MODE and RESOURCE_MODE tables. In addition, the CONTINUOUS_FUNCTION stores information about distribution ratios and, therefore, only Distributors will utilize this table. Every physical entity, as long as rendering on Google Earth is required, will have a record in the LOCATION table, which consists of four GEO_POINT fields. Each GEO_POINT has a record that points to an entry in the GEO_PIOINT table, which captures a physical location on earth. The PORT table, which is a child table of PHYISICAL_ENTITY table, is designed to store information of input and output from each physical entity. It is a one-to-many relationship, i.e., a physical entity could have multiple ports. The PORT table contains information such as the token type, unit, direction of the port (input or output), base value, etc. The PORT table has a child table named CONFIGURATION. It is the link between two ports, i.e., it determines the direction of the token flow, from one port (source) to another (destination). Once the model is defined in I2Sim, it can be simulated multiple times. These simulations are captured as events and stored in the SIMULATION table. This table is like a catalog for a simulation. With a MODEL_ID, all records of simulations can be pulled out from this table. 2. Organizational group: This group organizes models and simulations from a high level perspective. It is a collection of all scenarios and disasters. The DISASTER table along with the DISASTER_TYPE table stores all historical events, such as the Japanese Sendai tsunami and earthquake, in a simulation form. In a disaster simulation, multiple simulators might work together as a system. The SYSTEM_COMPONENT and MODEL_SYSTEM_COMPONENT table captures information about simulators used in the historical event. These two tables can be considered as child tables for DISASTER. The SYSTEM_EVENT and SYSTEM_EVENT_PM are in charge of storing the ‘port’ value and the ‘Physical Mode’ of infrastructures at a particular instant. For example, a bridge collapses during an earthquake; the Physical Mode of that bridge will drop from 1 to 5. This information will be 22  captured in these tables. This historical information is a preparation for disaster analysis and to assist emergency responders play “what-if” scenarios and optimize the rescue plan. 3. Simulation group: This group can be interpreted as a sub group of the SIMULATION table. All the detailed the information of simulations is stored in this group. This is a critical group for the emergency responders because it provides both real time and historical simulation results. Emergency responders can use the web interface to access these results and support their decisions. The name conventions of the tables in this group are self-explanatory. The CURRENT_PHYSICAL_MODE, CURRENT_CONTINUOUS_FUNCTION and CURRENT_PORT_VALUE are dynamic tables and are designed to store current time step values. In contrast, the CONTINUOUS_FUNCTION_STEP, PORT_STEP and RESOURCE_MODE_STEP are associated with STEP table and store information for each time step. 4. Port Replication Group: Port replication is an on-going development on inter-simulator communication. The main concept is to duplicate the information of a collection of ports from one simulator to a set of ports of another simulator. This group is not related with web services and is beyond the scope of the research in this thesis. 5. Raw Data Group: This user group is also under development. This group is intended to store raw GIS (Geographic Information System) information from disaster regions as packages. A web service will interpret the information and extract useful data and automatically feed it into the corresponding tables in the model group. The main focus of this thesis is the web services implementation in DR NEP. Therefore, the port replication group and the raw data group will not be discussed extensively.  23  Figure 13 Current Database Schema for DR NEP  24  2.2.2 Web Service Architecture Simply stated, the web services discussed here are a method or a process that allow the DR NEP user to retrieve information from the database over the network with specific requests. The response that is displayed, either on a web browser or GIS rendering engine like Google Earth, depends on the type of the request. Web services design can be accomplished by the combination of standard open source tools, such as PHP, MySQL and XML. The services can directly access the database through SQL queries. Prototyping and implementation can be straightforward and fast. However, DR NEP is a research project and could possibly become a long term comprehensive development. A fast prototype is not the first priority; reliability, reusability, scalability and security are the core features that need to be considered. The Java Platform Enterprise Edition is used extensively in business applications. Broemmer commented on the advantage of using J2EE as “it provides a robust development upon which to build flexible, reusable components and applications” [17]. J2EE is a very sophisticated tool that allows many variations and structures on web services. Singh et al. introduced several common J2EE patterns in his book [18] such as the Multitier Application Scenario, Stand-Alone Client Scenario, Web-Centric Application Scenario and Business-to-Business Scenario. Each pattern serves a different purpose depending on the application specification. To construct the architecture for a specific system, many design factors need to be considered. As Singh et al. commented on the pattern selection [18]: “The applications-level decisions and choices are ultimately a trade-off between functional richness and complexity.” The architecture adopted in DR NEP is a five-layer (arguably four layers) service oriented architecture (SOA) as illustrated in Figure 14. At the client side, DR NEP uses the Struts 1 framework to provide web control, which deals with sending requests and receiving responses. When a web request is sent to the Server Data Object (SDO) Layers, it generates a response based on a pre-defined Web Services Description Language (WSDL) and then maps it to the Data Transfer Objects (DTO) Layers. The DTO layer functions in DR NEP as a business logic layer, it defines all the rules of how data will be fetched from the database based on the request. In other words, the DTO layer is the bridge and filter between the SDO layer and the Data layer. DTO does not communicate to the database directly; instead, the Data Access Object (DAO) layer, which contains all the SQL queries to the database, creates a link between the two. The DTO layer only needs to call methods from the DAO layer and it will query the database and return results as objects. The final layer is the database. As mentioned in the earlier chapter, DB2 was selected for the DR NEP project and a relational database schema was developed upon. For easier access to the database, the Java Persistent API (JPA) was used to map the relational database to objects. The use of JPA significantly simplified the data persistence procedure. The following section will explain the functionality of each layer in great detail. This section is intended to stay at the conceptual level. The detailed implementation, which includes procedures and the code implementation, is included at the end of the report in the Appendix A: Sample Code for Web Service of Setting Distribution Value section. To provide a better explanation on the structure, an example of 25  setting distribution ratios is broke into parts and added into the corresponding areas throughout this section.  Figure 14 DR NEP Web Service Architecture  1. Struts 1 (Web) layer: According to Apache official website [19], struts is a “framework that provides its own web controller component and integrates with other technologies to provide the Model and the View”. On the ‘model’ side, struts is interacting with Enterprise JavaBeans (EJB), a standard data access technology, to access information needed from the database. On the View side, struts is initiating request and rendering the responded information on JavaServer page (JSP).  26  Figure 15 Struts Work Flow (Eg. Set Physical Mode for Electrical Substation)  To demonstrate how this layer works, Figure 15 illustrates a complete process of setting the Physical Mode of an electrical substation in struts. When the ‘Submit’ button is clicked on the set Physical Mode JSP page, a request of Physical Mode change is initiated. ‘Set Physical Mode Form’ collects necessary information such as ‘physical entity ID’ and ‘Physical Mode value’ from the web page. ‘Set Physical Mode Action’ is acting like an agent. The Action class receives the information from the form class and converts it to a façade request. This process is the ‘View’ to ‘Model’ conversion. ‘Model Façade’ is the bridge between the struts layer to the SDO layer. A 27  ‘SetPhysicalModeRequest’ is initialized from façade and passed to the next layer. The SDO layer then wait for the ‘SetPhysicalModeResponse’, and then passes the response back to the Action class through Façade class. Struts invokes a JSP page and display the response on a new JSP page. The struts layer can be considered as the door to access to the internal structure of the platform. In the example of setting distribution ratio, when the user clicks on the “submit” button, the corresponding JSP page collects the distribution ratio and passes it to the form layer. The action class initiates a request with the distributor id and the ratio values that was compiled from the form layer through façade. Once the values are stored in the database, the action class will receive a confirmation and create a new JSP page for results rendering. 2. SDO (Service) Layer: Portier introduces the SDO layer as follows [20]: SDO is a unified framework for data application development, which includes an architecture and API. The main reason for adopting the SDO layer is to simplifying the J2EE data programming model in DR NEP structure. Developers do not need to be familiar with other technology-specific APIs in order to access and utilize data [20]. Instead, the developers only need to understand the SDO framework, which works pleasantly with data in multiple data form, including RDBMS, entity EJB components, XML, etc. [20] Using the SDO API significantly reduces the development time for writing requests and the associated responses. Figure 16 illustrates the process of creating SDOs in this layer.  28  Figure 16 SDO Generation Process [21]  In the SDO layer, the Web Services Definition Language (WSDL) and XML schema documents (XSD) need to be defined. The WSDL file is a description of web services, which include the following information: • request and response messages are in the web service • the type of fault should be introduced when there is a communication error • internet protocols that are bound in the service such as Simple Object Access Protocol (SOAP) and Hypertext Transfer Protocol (HTTP) There is an individual XSD file for both the request and response methods. Definition of these XSD file is absolutely vital for the SDO layer implementation because it determines what parameters the services need in order to invoke the method and what parameters are included in the response message. The core advantage that simplifies the data programming model is that the parameters in the XSD files do not need to be primitive types like ‘integer’ or ‘string’; as long as an object is defined in the common library, such as a ‘Port’, the parameter could be set as such. Most of the J2EE Integrated Development Environments (IDEs), such as Rational Application Developer, have a data APIs generation tool. The tool takes the description files and outputs data APIs in Java classes. These java classes can be called from ‘Façade’ in struts and directly used as Service Data Objects (SDOs).  29  To link to the Data Transfer Objects (DTO) layer from the SDO layer, a mapping framework is required. A mapping framework is useful in a layered architecture where you are creating layers of abstraction by encapsulating changes to particular data objects vs. propagating these objects to other layers (i.e. external service data objects, domain objects, data transfer objects, internal service data objects). A mapping framework is ideal for using within Mapper type classes that are responsible for mapping data from one data object to another [22]. Dozer is defined as a “Java Bean mapper that recursively copies data from one object to another” [22]. Once a dozer mapper is established, which in DR NEP is a Java file named DrNepServiceDozer; mapping can be done directly through a XML file (dozerBeanMapping.xml). The dozer mapper also takes care of type conversion when copying one data model to another. Continuing from the example of setting distribution ratios web service, the SDO layer is functioning as a model or object construction factory. In order for the SDO layer to understand how the request from the struts layer can be converted to an object, the object needs to be constructed first. In the WSDL and XSD files, all attributes associated with the object such as the ID of the distributor, the values of the distribution ratios, etc., are defined. The object generator takes all these attributes and constructs an object mold in the service layer. When a request is initiated from the struts layer, the SDO layer will choose the right mold and fill it in with the information that is passed to this layer. When the object assembly completes, it will be transferred to the DTO layer by the SDO/DTO mapper. 3. DTO (Business Logic) layer: The terminology ‘business logic’ is a conventional concept that refers to the part of the application that deals with performance of business-related tasks [23]. As Esposito mentions [23]: Code in the BLL operates on data that attempts to model entities in the problem domain— invoices, customers, orders, and the like. In many SOA applications, the business logic layer (BLL) contains both the services layer (SDO) and the data transfer layer (DTO). In DR NEP, we borrowed the functionality of the DTO and tailored it to fit our needs. This layer separates the service layer from the data layer and acts as a bridge/filter. DTO layers receives a requests from the SDO, generates a data query request to the Data Access Object layer, assembles the results in a container and returns them back to the SDO. In simpler terms, the SDO only needs to tell the DTO what data it wants from the database. How and where the data is obtained or what method will be used to filter the data is completed in DTO. Depending on the scale of the application, many software architects may choose to eliminate the DTO layer. Adding the DTO layer introduces a significantly unnecessary complexity to a small 30  web application. However, for the DR NEP, the use of the DTO is critical. Esposito summarizes the advantage of deploying the DTO as follows: If DTOs are used, a change in the requirements that forces a move to a different amount of data doesn't have any impact on the service layer or even the domain. You modify the DTO class involved by adding a new property, but leave the overall interface of the service layer intact [23]. In the example of setting distribution ratios web service, the DTO layer is acting like a filter through the process. As a research project, specifications in the DR NEP change quite frequently. For instance, the current specification of the setting distribution ratios web service only requires the service to return the latest distribution ratios upon completion of the request. If the specification of the web service changed and now requires a set of history distribution ratios, instead of rewrite the complete web service, developer can simply changes the filter to fetch more result from the database. Deploying an extra layer in the web service certainly costs more development time. However, in the long run, the time to set up the DTO layer is just a fraction of the cost of rewriting the complete web service. In addition, one very important piece of this work, the KML generation for Google Earth, will be discussed in a latter section, also resides in this business layer. 4. DAO (Data Access) Layer: In database design, one key factor that measures performance is the number of I/O costs. Loosely speaking, to reads and writes a large chunk of data from a hard drive all at once is faster compared to reads and writes of small amounts of data several times due to the seeking time and rotational delays of the hard drive. When the business layer initiates a request, the methodology of accessing the database is implemented in this layer. The DAO layer is designed to manage the connection with the database to fetch and store data. An optimized store procedure or query written in the DAO can drastically reduce the response time of a web service. In addition to boosting performance, the DAO layer functions as an intermediary between the business layer and the underlying data. This characteristic isolates the relational database management systems (RDBMSs) from the rest of the application. If an alternative RDBMS is selected during the development, developers can easily rewrite the DAO layer to cope with the change. 5. Database (DB2) Layer: This layer is where files and tables persist. The schema of the database has been discussed extensively in section 2.2.1 Database. One important framework that the DR NEP adopted that 31  has not yet been discussed in the thesis is the JPA, which stands for the Java Persistence API. Simply defined, the JPA is a collection of technologies of persistence that map the relational database to object-oriented ‘entities’. Instead of writing complex SQL queries and storing procedures, the rows in the tables are transformed to objects or entities. Any object-orient programmer can access this information from the database and manipulate the data with a minimum relational database background. A multi-layer web service architecture is the core technology of the DR NEP. The structure ensures the stability, expandability and security of the system. Nevertheless, as a tool for assisting in emergency response, the user interface is just as important as the architecture. During disasters, with a very limited amount of time, the system should present information as comprehensive as possible to the emergency responders in a user friendly form. The web interface and the use of Google Earth as a GIS representation tool will be discussed in the following section.  2.3 Web Interface and Google Earth 2.3.1 Web Interface Design The web interface design is an essential component for an emergency response platform. A simple and clear web layout with organized information would significantly speed up the rescue process. After many stages of modifications, the DR NEP researchers have implemented a system that meets the design specifications. The system starts with a simple login page as shown in Figure 17. The web site was designed as a role based control system. Each login account is associated with certain roles such as ‘emergency responder’, ‘emergency commander’, simulation experts’, etc. in the database. When a user logins with his/her credentials, the system directs the user to the associated control panel.  32  Figure 17 DR NEP Login Page  At the current stage of development, only the simulation and control part of the system has been completed. The current implementation of the website design allows the emergency commander to control the i2Sim simulation and view results of each infrastructure. Figure 18 illustrates the control web page that will be displayed when the user logs in as an emergency simulation expert. The user can choose to either to start a new simulation or to review saved simulation results. When the ‘View Saved Simulation’ button is clicked, the system will forward the user to Figure 19 Simulation Result Page. The user can then review a detailed report for any simulation that was persisted in the database. On the bottom of the page, the user can check different options to view the filtered results.  33  Figure 18 Simulation Selection Page  Figure 19 Simulation Result Page  34  If the user wants to start a new simulation, they would click on the ‘New Simulation’ button. The system will bring the user to the simulation specification page as shown in Figure 20. On this page all parameters that are related to the simulation can be configured. In the 2.2.1 Database section, the concept of the model and how a model can be persisted in the data schema is discussed in detail. The first parameter that the user needs to determine is which model, such as the ‘Sendai Model’, ‘UWO Boiler Incident Model’, ‘UBC Hospital Model’, etc., will be simulated. This selection will command the system to fetch the right model from the database. The ‘Type of Disaster’ and ‘Magnitude of Disaster’ are recently added features. In pre-disaster scenarios, the type and magnitude of a disaster can be used to intelligently define the Physical Mode damages for the infrastructures. For example, during an earthquake with Richter magnitude of 8, an electrical substation that is geographically located near the epicenter would result hold considerable damage; and consequently, the initial Physical Mode would set at 4-5. Both the ‘Total Simulation Time’ and ‘Time Step’ are very important concepts for the numerical simulation. The time step is the frequency of computers calculating the new states based on the previous states. Simply said, in I2Sim, the time step represents how often I2Sim collects information from the ESB and compute the output, for example, the patient discharge rate. The total simulation time is the number of time steps that the whole simulation runs. The unit here (for example, hour) reflects the unit in real time. The actual computation time, however, depends on the computation power of the simulator. As long as the computational time is less than the real time, the simulation can be consider as real time simulation.  Figure 20 Simulation Specification Page  35  Once the simulation gets created, the simulation control panel as shown in Figure 21 will be displayed. The user can use the panel to pause, resume and stop the simulation. During the simulation, the user can view the lasts simulation results at each time step.  Figure 21 Simulation Control Panel  The following Figure 22 and Figure 23 are sample screenshots of simulation results. During the simulation, physical damage status of facilities can be changed through Google Earth, which will be introduced next. The change of PM will result in different row selections in the HRTs, and the consequence results in different outputs from the Production Cells. Once the output of one cell is changed, the other facilities that are dependent on this damaged facility might suffer from a resource deficiency and would reduce the Resource Modes. From Figure 22 to Figure 23, the PM of the Electrical Substation drops from 100% operation to 25% operation, in the second time step, the Resource Modes of all facilities are dropped to 25%. As indicated in the ‘Limiting Factor’ column, both the Hospital and Water Station are suffering from lack of electricity.  36  Figure 22 Simulation Result 1  Figure 23 Simulation Result 2  37  The DR NEP web interface is capable of showing further details of the simulation results. The ‘Show Model Component’ in Figure 23 will direct the user to the model components page as shown in Figure 24. This is a complete list of the model components in a particular I2Sim simulation. The simulation results of each component including the Production Cells, Distributors and external Sources are summarized in different categories. Take ‘Hospital’ for example; Figure 25 shows the complete simulation result for every time step. The ‘Plot Graph’ function can plot data in a 2-D graph, which provides emergency responders a direct visualization.  Figure 24 Model Components  38  Figure 25 Detail Report of Hospital Component  2.3.2 Google Earth 2.3.2.1 Overview Geographical information is a consequential piece in a disaster response platform. A direct visualization of GIS information improves rescue efficiency and reduces fatal errors for emergency responders. There are many geographic information system (GIS) rendering engines on the market. Excluding those large scale GIS servers, most of them are available to run on commercial PCs and even on mobile devices such as iPhone or Android phones. Any GIS software has its own advantages over others which make it tough to decide which one to adopt. In fact, many of the software are qualified in DR NEP specifications. Due to lack of methodology in regards to selection, one can only download and try them individually in order to actually make a choice. After many tests, Google Earth stood out from the rest of the tools for the following reasons: • •  A comprehensive virtual globe, map and GIS program Stable and compatible for almost all major operating system including mobile device platforms 39  • •  Easy to access information and native support for Keyhole Markup Language (KML) The user can place customized information on the 3D maps using KML or even place 3D models using Google Sketchup  Once the tool is defined, the second challenge is how to integrate the tool with the DR NEP. Just like the other services, Google Earth as part of the visualization tool communicates with the ESB and database through web services. It is fortunate that there is a Java API developed for KML (JAK), so the KML model can be generated dynamically using J2EE. The following section will be used to introduce the methodology of developing an interactive KML models on Google Earth using Java and web service technology. 2.3.2.2 KML and JAK Keyhole Markup Language (KML), which was originally created by Keyhole Inc., is an XML based notation that can represent geographic information and displays it on a 2D or 3D KML compatible GIS visualization software such as Google Earth, ESRI and Microsoft Virtual Earth. KML is a very flexible tool that generates structures or models overlaid on top of a geographical map. With the assistance of JAK, using web services to generate a KML model on Google Earth becomes even easier. Note that the KML and JAK specification standards are well documented on their corresponding websites and detail explanation will not be included in this thesis. Table 7 KML and JAK Specification  Language KML JAK  Website http://www.opengeospatial.org/standards/kml/ http://labs.micromata.de/display/jak/Home  Figure 26 illustrates the complete process of KML generation for DR NEP. A simple KML file contains a <NetworkLink> tag, which points to the IP address of the DR NEP server, is loaded in Google Earth. For every predefined time step, Google Earth will initiate a request to the DR NEP server to request for a KML model file. The server will execute the web service and send a request to the database through the ESB. The database returns the latest model with simulation results back the web service. The web service assembles the information at the business logic layer and then generates a KML model using JAK. Google Earth will load the new KML model and display it on a 3D map. The code associated with this process is included in the Appendix B: Sample Code for the KML Generation section.  40  Figure 26 KML Generation Process  A sample screenshot of Google Earth with a test model is shown in Figure 27. At this stage of development, the major components of the KML model include the Production Cell, Channel, Source and Distributor. All of these components are structured in the similar fashion with slight variations.  Figure 27 KML Demo Model  41  For the sake of explanation, all the KML related tags, which are used to identify different types of information in KML, will be enclosed in angle brackets “<>”. 1. Shape: Once the model is loaded onto the web service from the database, the KML generator loops through all the components of the model and constructs KML components one by one. Each component, regardless of whether it is a Production Cell, Channel, Source or Distributor, has four geographic coordinates. Each coordinate consists of longitude, latitude and altitude. The <Placemark> is located in the first geo-coordinate. Along with the other three coordinates, KML uses <MultiGeometry> to generate the shape of the <Polygon> structure. 2. Colour: The <OuterBoundary> of the <Polygon> is painted in black and frames the location of the infrastructures. The <Polygon> is filled with one of the five Physical Mode colours, of theI2Sim colour code. With the live update feature in <NetworkLink>, users from all over the world are able to input their assessment of the Physical Mode of physical entities in real time. Since the Physical Mode of Channels, Sources and Distributors have not yet been implemented in the current version of I2Sim, gray as the default colour is applied to those components. 3. Icon: A set of customized icons (Table 8) were developed by the DR NEP team and are placed on the same location as the <Placemark> of each KML <Polygon>. The icons are very useful tools for identifying infrastructures. Without searching for names, users can quickly determine the location of any entities in a large scale geographic region. In addition, on the left side panel of the Google Earth interface, the physical entities are sorted based on the icons. This feature allows emergency responders to efficiently identify the correct facility and make changes to the corresponding parameters.  42  Table 8 List of Icons Used in DR NEP KML Model  Icons  Infrastructures Channel Distributor Electrical Source Electrical Substation Hospital Water Source Water Station Venue (House, School, Shelter) Boiler  2.3.2.3 Web Service in Google Earth In addition to the “KML generation web services” mentioned in the previous section, other web services were developed that can be accessed from the Google Earth build-in web browser. 1. Physical Mode Update During a disaster, the I2Sim simulator will run in real time. At every time step, I2Sim suggests the ideal resource allocation and the best evacuation route to emergency commanders throughout the DR NEP platform. Emergency responders circle around the disaster area searching for survivors and report back on the damages sustained. The emergency responders can use Google Earth on their laptop or mobile devices to update the Physical Mode of physical entities like electrical substations, hospitals, etc. 43  After the emergency responders load the KML model on their devices, a complete view of the disaster region with all critical infrastructures is displayed on their devices. The emergency responders can click on the icon of a specific physical entity and the Physical Mode selection page will be displayed in the build-in browser. The user could view the current Physical Mode of the facility and the time stamp that the entity got updated. Then based on the professional judgment of the emergency responders, they can use the radio button to update the Physical Mode of the entity. With two simple clicks as shown in Figure 28 and Figure 29, the Physical Mode of that facility is updated to the database. At the next time step, I2Sim will pick up the latest physical status of each facility and re-calculate the optimized solution for the emergency commanders.  Figure 28 Update Physical Mode of the Venue (part 1)  Figure 29 Update Physical Mode of the Venue (part 2)  44  2. Distribution Ratio Override When a model is in automatic mode or intelligent mode, I2Sim calculates and sets the optimized distribution ratios for each Distributor. There are times when commanders might have a second opinion on the distribution strategy and want to override the values manually. This distribution ratio override function is designed for such purpose. The process of setting the ratio is similar to set the Physical Mode. First the user chooses a Distributor and clicks on the hyperlink. The distribution control panel flashes in and user can manually input the distribution ratios and override the original ones. The ratios are displayed as positive decimals. The total ratio has to add up to 1, otherwise will cause internal error.  Figure 30 Set Distribution Ratio 1  45  Figure 31 Set Distribution Ratio 2  3. Source and Channel Delay Update This part of the web service is still under development. Source values and Channel delays are updated through the same web service. When the user clicks on one of these facilities, based on the physical entity Id which uniquely identifies the entity, the web service will direct the service to the corresponding web page. The following figures are the examples of setting the Channel delay factor. Once the delay value is submitted, the value will be converted to the proper unit and persist in database. At the next time step, the Channel will pick up the value and change the delay parameter in I2Sim.  Figure 32 Channel Delay Update 1  46  Figure 33 Channel Delay Update 2  3 Case Study To put DR NEP into action, a case study was carefully chosen from the research that the DR NEP team conducted in the past year. This section is intended to demonstrate how DR NEP can be used in real scenarios and bespoke the value of the platform in different types of studies.  3.1 Case Background On March 11, 2011 at 2:46 PM in Japan local time, a magnitude 9.0 earthquake, which was the most powerful known earthquake that has ever occurred in Japan, struck near the east cost of the Honshu region. The earthquake triggered a devastating tsunami which travelled 70 KM from the epicenter and hit the coast areas of several prefectures in Tohoku. According to the National Police Agency in Japan, the disaster caused the deaths of 15,467 people with 7,482 people not yet found as of June 20, 2011. Soon after tsunami impacted the coast, a number of nuclear reactors suffered from level 7 meltdowns in the Fukushima Daiichi Nuclear Power Plant. It is another major incident after the Three Mile Island accident in the United States and the Chernobyl meltdown in Ukraine, which brought the world’s attention again on the catastrophic impact of the post nuclear power plant failure effects [24]. As the consequence of the incident, there are “dozen dead towns ringing the broken power station” and over 80,000 of residents were forced to be evacuated from the radiation zone [25]. With a great deal of frightful news continuing to be published on the internet, researchers at UBC decided to initiate a project that applied DR NEP to model the incident. Conducting the project in a 47  reputable university could raise the awareness of disaster response to the public. This project could also put DR ENP in real action and evaluate the usefulness of the platform in assisting emergency responders.  3.2 Modeling Methodology Designing a large scale model requires sophisticated planning. Figure 34 delineates the methodology path of the Japan earthquake modeling.  Figure 34 DR NEP Modeling Methodology [26]  3.2.1 Information Collection There was a massive amount of information over the internet and newspapers after the incident. Not all information, however, was useful for the modeling process. The earthquake and tsunami impacted twenty prefectures in the Tohoku region. Building a model that encapsulates the entire Tohoku region is almost impossible. From a bottom-up approach, a small region should be targeted for modeling and expansion can resume once the model is verified. Sendai city was the first region that was selected for modeling because of the accessibility of comprehensive reports and information in this location due to its municipal importance in Miyagi Prefecture, Tohoku region. Once the city was chosen, the next step was to determine the infrastructures to be included in the blueprint of the model. Many factors were suggested in the planning meeting. However, due to time and information limitations, only the following few key factors were considered to be modeled. • • • • • •  Electricity Steam Water Transportation Emergency Responders Residents to be evacuated 48  •  Hospital  There were thousands of news and updates on newspapers and websites every day. Filtering information based on the infrastructure decision was a very lengthy yet critical task. Since most of the information is written in Japanese, language became a challenging factor. The DR NEP team decided to add a new member from Japan for collecting and translating information. In order to design the HRT to accurately represent the operation of the infrastructures, the sources of information need to be reliable. Instead of blindly searching on the internet, the following channels were adapted for data collection. • • • • •  Newspapers (including online information from reliable news website) Miyagi prefecture/Sendai city/Governmental office disaster response websites and reports Universities’ reports (Tokyo University, Kyoto University, etc.) Disaster Response Map (published after the disaster) Direct contact with Sendai city office (Water Bureau, Tohoku Electric Power, Emergency Responders)  Information gathered from the above sources were aggregated and categorized into documents for modeling.  3.2.2 Historical Time Line Formulation Normally, disasters are recorded in a specific order to form a timeline. In this particular case, the tsunami hit the impact zone 29 minutes after the earthquake occurred. There were hundreds of aftershocks soon after the main earthquake. As part of the information collection process, recording a timeline helped in approximating the damage of facilities at particular instances. A complete scenario was created based on the timeline. Scenario development is a major part of historical validation process and can be used for “what-if” studies. Of course, the timeline is a simplification and approximation of the real incident. Based on the information collected over time, a timeline was formed and is summarized in Table 9.  49  Table 9 Historical Timeline in Sendai City during Disaster [26]  No 1 2 3 4 5 6 7 8 9 10 11 12 13 14  Time (min) 0 46 53 54 75 95 160 220 221 300 400 500 600 800  Event Normal conditions (fact) Earthquake M = 9.0 (fact) A tsunami warning is issued for the coastal area of Japan (fact) An evacuation process is going on (fact) The first tsunami wave hits the impact zone (fact) Water retreats (fact) Survivors start evacuating the impact zones (assumption) Road are prepared to begin the triage, search and rescue process (assumption) The process for transportation of survivors and casualties begins (assumption) Ambulance dispatch goes down Ambulance dispatch restored Medical supplies depleted at serious injury hospitals Additional medical supplies provided to serious injury hospitals Food decreases at shelter  3.2.3 Model Scenario Development This stage of development mainly involves model components decision, HRT approximation, and event scripting, which are high level decisions. The detail implementation is yet being refined. Very often, researchers may realize there some critical information missing in the development and the modeling process cannot proceed without the missing piece. The developers will then have to go back and revisit the information or even repeat stage 1 to gather more information.  3.2.4 Implement Model Concept Once the model developer collects all the information required, a concept model can be constructed. Based on the location of the geographic region in Sendai city, the area was divided into three regions, as shown in Figure 35. Along the coast, a size of twenty seven kilometers by eight kilometers area was defined to be the impact zone. Then, four kilometers away from the impact zone is the evacuation zone. This is where residents from the impact zone gathered for evacuation. The shelter zone is twelve kilometers further from the evacuation zone and is where the shelters and hospitals were located. Note that part of the evacuation zone is also used as shelter zone since the evacuation is a lengthy process and could take days to complete. Some temporary shelters were installed near the impact zone for emergency responders to rest.  50  Due to the demographic and geographic differences, the impact zone was divided into three parts for more accurate simulation. The demographic differences in population include age, mobility, gender, etc. The evacuation process has to take these factors into consideration because they will significantly affect the evacuation efficiency. The geographic differences refer to the distance from the region to the shelter zone and hospitals and the terrain condition of the evacuation routes, which are also key factors to evacuation effectiveness.  Figure 35 Disaster Zones  Figure 36 Impact Zones  51  Modeling is a high level abstraction of the critical infrastructures. The key role of DR NEP is to figure out the interdependencies between the infrastructures. For the model, many of the operation details were ignored or approximated. With the region clearly defined at this stage, designing the concept model becomes convenient. Figure 37 is a sample sketch of the Sendai city concept model. All the critical infrastructures are connected using arrows with different colours which represent different type of tokens. In this concept model, four electrical substations are supplying electricity to different impact zones and hospitals. Electricity in the shelter area, however, is assumed to be self-generated. Water supplies are an aggregation of all possible resources including water station, reservoir from schools and residential area. Ambulance dispatch distributes ambulances circulating around the three impact zones and delivers patients to the Serious Injury Hospital and Light Injury Hospital. Note the two hospital facilities are aggregation of hospitals based on injury types. According to hospital websites and information forums, we summarized the hospital into two major categories as shown in Table 10. The Emergency Vehicle Dispatch sends emergency vehicles to the impact zones and the vehicles deliver healthy people to the Shelter area.  Figure 37 Concept Model for Sendai City  52  Table 10 Hospital Aggregation in Sendai Region  Type of Injury Serious Injury Light Injury  Hospitals Sendai Municipal Hospital (Wakabayashi Ward) Tohoku University Hospital: Advanced Tertiary Emergency Medical Center (Aoba Ward) JR Sendai Hospital (Aoba Ward) Sendai Teishin Hospital (Aoba Ward) Sendai Medical Center (Miyagino Ward) Sendai Open Hospital (Miyagino Ward) Self Defense Force Hospital (Miyagino Ward) Nakajima Hospital (Miyagino Ward) Kosei Nenkin Hospital (Miyagino Ward) Sendai Emergency (Wakabayashi Ward) Sendai Orthop Hospital (Wakabayashi Ward) Kohnan Hospital (Taihaku Ward) Sendai Red Cross Hospital (Taihaku Ward) Nagamachi Hospital (Taihaku Ward)  3.2.5 I2Sim Model Implementation The concept model provides a foundation of the schematic design for the I2Sim implementation. An I2Sim model design can be broken into two steps. Based on the concept model, all function blocks can be placed accordingly. Figure 38 is a screenshot of the I2Sim model for Sendai city. The model is consistent with the schematic design of the concept model which consists of a resource section, an impact zone section, an emergency responders section and hospital plus shelter section. The Sendai city model is solely implemented by the basic components from I2Sim toolbox. The complexity of the system design well demonstrated the competency of I2Sim. 1. Resource Section Both the electrical system and water system are included in this section as they share the similar structure. A magnified version of the system is shown in Figure 39. Multiple electrical Sources feed into the Production Cells which represent the electrical substation located in the Sendai region. An external function block is controlling Physical Mode of each substation. The trigger is designed to simulate power outage during disasters. The output of each substation is connected to a Distributor that direct electricity to each facility based on the distribution ratio. The ratio is also controlled by an external function block. When DR NEP is connected to the model, all these function blocks are monitored and operated by web services. 2. Impact Zone Section  53  This section is the most intelligent part of the system. The impact zone incorporates the rescue process, triage process and evacuation plan. For each impact zone, a Storage cell is used to hold the residents who are ready to be evacuated. Depending on several key factors, including demographics, guidance, rapid response, geographic layout [27] and emergency information, an evacuation rate is selected from an HRT in the Production Cell. The rate becomes the output rate of the Storage. Once the residents are evacuated from the impact zone, a Distributor splits the people into healthy refugees and patients. The healthy refugees are directly delivered to the evacuation zone and the patients go through a triage process. Depending on the condition of the patients, the triage process divides the group into red and yellow casualties. The red casualties require treatment from hospital facilities and will be sent to the patient discharge zone and prepared to be transported. Yellow casualties, on the other hand, only require first aid treatment and these patients are treated on site. In I2Sim, a Delay Channel is used to simulate the treatment process. Once the yellow casualties are treated, they will merge with the healthy refugees from the impact zone and to be delivered to evacuation zone. Both the patient discharge zone and evacuation zone are represented by Storage cells. Available ambulances and emergency vehicles circulate around these areas and transport people to designated areas. 3. Emergency Responders Section This section is where the ambulance and emergency vehicles dispatched are located. Both of the dispatch centers are designed the same way. Vehicle pools hold all standby vehicles. When the dispatcher/commander sends an order to the pool, the ambulances and emergency vehicles are heading off to the designated areas. Channels are used to simulate the delay from the dispatch centers to the evacuation zones. 4. Hospital Plus Shelter Section Patients from different impact zones are aggregated in the hospital waiting rooms and wait for treatment. The treatment rate is depending on available electricity, water, natural gas, medical gas and steam. Of course, other factors may also be critical, but only the resources mentioned here are considered in the simulation. Channels are used to simulate the average treatment time. During a disaster, each hospital has a certain capacity and can only accept and treat a certain amounts of patients. Treated patients have to be delivered to the discharge center immediately and prepared to be transported to the shelter area. The implementation of the shelter zone was particular challenging. The concept of HRT was introduced in the 1.2.3 I2Sim Toolbox Description section. According to the ontology, the values in the HRTs are supposed to be increased monotonically. Simply said, when available resources increase, a Resource Mode with larger output value should be selected. The shelter is designed in a way that the refugees from different impact zones are merged using an Aggregator and are kept in a Storage block. When the Storage exceeds its capacity or there are not enough resources to maintain the health of these people, we want to output the patients and deliver 54  them to the hospitals. If we follow the ontology convention, with more medicine supply and food, a higher value of output patient rate would be selected. This design, however, contradicts the original ontology. To solve this problem, we had to borrow some components from Simulink toolbox. The shelter design is illustrated in Figure 43. A Production Cell is used to keep track of how many healthy people the shelter can maintain. Then the level value of the Storage is used to compare against the output from the Production Cell. If the difference is greater than zero, it means the shelter holds more people than it can actually support. Consequently, the difference, which represents the amount of patients, will be used to command the Storage to output patients to the hospital. If the difference is negative or zero, the shelter is operating under normal condition and no patients would be generated. This ‘work around’ solution is certainly a high level approximation of shelter operation. Many other factors might be introduced in future developments to improve the accuracy of the model.  55  Figure 38 I2Sim Model Overview  56  Figure 39 Resource Section of Sendai Model  Figure 40 Impact Zone Section of Sendai Model  57  Figure 41 Emergency Responders Section of Sendai Model  Figure 42 Hospital Section of Sendai Model  Figure 43 Shelter Section of Sendai Model  58  3.2.6 DR NEP Integration The next step in the process is to integrate the DR NEP web service with the I2Sim model so that the user could control the model externally through Google Earth and web browsers. For a large scale model with hundreds of components like the Sendai city case, to construct an equivalent Google Earth KML model is nearly impossible. First, we need to identify what components that the users would like to visualize and control. After the components are selected, a database administrator needs to manually key in the initial values of those components into database. The initial values are the geo-location, port connection, default Physical Mode and Resource Mode, default distribution ratio and available resource of the facilities. Once the data model is in place, the user can use the KML file which contains <NetworkLink> tag to request a KML model through web services. The web service will load all the initial values and construct a KML model on Google Earth. Figure 44 is a screenshot of the Sendai city KML model rendered on Google Earth. All facilities, including electrical substations, a water station, emergency responders, hospitals and impact zones are displayed in the actual geographic location in Sendai region.  Figure 44 Screenshot of Sendai City KML Model Loaded on Google Earth  During the simulation, the can could view the physical status of all infrastructures in real time. In addition, all the web services mentioned in the 2.3.2.3 Web Service in Google Earth section are  59  integrated with these facilities. The user can update the Physical Mode, change the distribution value, alter the available resource and set the Channel delays on this KML model.  Figure 45 A Close Look at the Facilities in Sendai City KML Model  Integrating DR NEP with I2Sim increases the power of the disaster response platform and improves the efficiency of the communication between responders. With the complete model in hand, many types of studies can be conducted in the system. 3.2.7 Historical Validation/Verification One more step before the model can be used for simulation studies is historical validation. This is a very important part of the modeling process because if the model is not verified, which means the simulation results do not match the historical event, the studies that are conducted with the model are meaningless. Historical validation is also the most challenging and crucial part of the model development process. This is analogous to quality assurance and debugging in software development. If the validation fails, it would require a lot of tweaking of the data in the HRT and other parameters to obtain reasonable results. Sometimes, developers might have to change the model structure or even redesign the model. In addition, even though the model is validated in one scenario, it does not necessary mean it will fit other scenarios. Historical verification is a very lengthy process. Especially with a large scale model like the Sendai case, many parameters might affect the simulation results. At the current stage of the development, we managed to validate some scenarios from the timeline that we organized, but certainly not all situations apply.  60  3.2.8 “What-If” Scenarios A “What-if” scenario is a type of study that uses simulation to reconstruct a historical event, and then it alters decision parameters and evaluates the new results to determine the optimal decision strategy. Based on the assessment of the outcomes, we can then determine if there are areas of improvement in the evacuation process, resource allocation, etc. A “what-if” study was conducted in January, 2012 for a technical audit [28]. The situation is described as follows: At a particular instant, the aftershock earthquake partially damaged the electrical substations. All stations were functioning in Physical Mode 2, which means they were functioning at 75% of their maximum capacity. The electricity supply before the aftershock was just barely meeting the demand. A reduction of 25% of electricity indicates that the emergency commanders will have to adjust the distribution ratio and supply electricity to most critical facilities. At this moment, the emergency responders do not have information about the resource requirements of the other system components, such as hospitals and water stations [28]. Due to lack of information, the disaster responders developed some strategies as shown in Table 11, based on the information at hand. Through multiple simulations, the responders hope to gain some insight and determine the optimal strategy. Table 11 Strategies for Electricity Distribution in What-If Scenario [28]  Plans Scenario without damage (SwoD)  Business as usual (BAU) Prioritize the impact zones with the largest populations (H-Pop) Prioritize the impact zones with the greatest degree of damage (H-Dam)  Detail Implementation This is a scenario without the damage factors and is for other strategies to compare with. No facility is damaged and everything functions at its 100% capacity. No change on the distribution ratio. With the damages on the electrical substation, everything operates as if there is no damage occurred. Higher population zones have more injured people to evacuate and therefore allocate more resource. Impact zones with the most damage need more resource to evacuate patients.  Each of these strategies was applied to the Sendai model. The damage on the electrical substation is simulated by changing the Physical Mode of those substations using the Google Earth interface. On the next time step, the distribution ratio of the electricity Distributor is changed according to the plan. At the end of each simulation the patient discharge rate is recorded for comparison.  61  Figure 46 Observation on Discharged Patient Rate Based on Different Distribution Strategies [28]  As shown in Figure 46, the number of discharged patients using different strategies is plotted against each other and some interesting facts can be observed. The result of the scenario without damage case is the best performance that can be achieved for obvious reasons. Surprisingly, the High Population strategy achieved the best results among the other three strategies. Looking into further detail, allocating the electricity to the higher population density zone, effectively utilizes the electricity to speed up the evacuation process. The BAU case, on the other hand, does not perform well due to lack of water. With normal distribution ratios, the water station receives less electricity and therefore produces less water. Since both water and electricity are key factors to hospitals, water soon becomes the limiting factor and will significantly reduce the patient discharge rate. The High Damage strategy seems to be the choice of common sense. Supplying more resource to the highly damaged area would possibly help speed up the evacuation process. Based on the simulation results, however, is certainly not the case. With more damage, the Physical Mode of the impact zone is very low. Electricity is no longer the limiting factor. Instead, the physical status of the impact zone affects the evacuation rate. By supplying more resource to this region, the resources are simply put to waste. These observations and results are difficult to discover because of hidden interdependencies among infrastructures. With the help of DR NEP and I2Sim, emergency responders can quickly identify these interdependencies to avoid making fatal mistakes. By applying “what-if” studies, many non-obvious results can provide insight to the emergency responders and assist them to make the right decisions. 62  4 Conclusion 4.1 Contribution to Disaster Response System  This thesis described a contribution to the disaster response system by developing and integrating the Disaster Response Network Enabled Platform (DR NEP) to the existing Infrastructure Interdependencies Simulation (I2Sim). Originally, I2Sim was designed to simulate the hidden interdependencies between different infrastructures. One important application of I2Sim is to simulate disasters and emergency responses. Disaster response is a fast-paced mobile action that requires extensive communication between emergency responders. Running I2Sim on an offline computer is certainly not the best solution. The development of DR NEP provides a unified server platform for I2Sim and other simulators to communicate and exchange information. In addition to communication among simulators, DR NEP uses web service technology to allow emergency responders to update information and manage resources using standard tool like Google Earth and Web browsers. In this thesis, the I2Sim ontology and each component in the I2Sim toolbox was briefly introduced at the beginning. Then, the DR NEP architecture and the web services implementation were introduced in Chapter 2. All the software and technology specifications were included as references. The design of the database is an important part of DR NEP because it captures all the critical information of all simulators as a unified schema. The implementation of web services was introduced next. As the core part of this thesis, the functionality of each layer in the software structures was explained in detail. The design of the Google Earth KML model and the web interfaces are critical to emergency responders. The methodology of designing the interfaces is included in the third part of the Chapter 2. The third chapter describes how DR NEP can be used in a real case and the value of the application of the methodologies to a real disaster response is examined throughout the study. An I2Sim model was developed for the catastrophic earthquake and tsunami incidents that occurred at Tohoku region in Japan in March, 2011 and was integrated with the DR NEP interface. By developing different type of scenarios and reviewing the emergency response process, we are hoping to gain some insight of how the efficiency of disaster response can be improved. From information collection to scenario studies, the modeling methodology of the Sendai City was carefully explained throughout the chapter.  4.2 Future Work  The development of DR NEP is still at a research stage. Many parts of the model construction process are accomplished through manual input. One possible future development is to build an automatic generator to construct the model through a web interface. The user will only need to provide information such as name, description, location, etc. of the infrastructures. The system will convert the information to a model component and persist it in the database. After all the components are added to the system, the user will be able to define a region of interest and the web services will select the proper components in this geographical area and automatically construct the I2Sim and KML models. 63  The implementation of this model generator is quite a challenge. However, once the generator is completed, it could significantly reduce model development time. The validation process for the Sendai Model is another challenge. To successfully validate the model, more detailed information about the city has to be collected. The HRTs in productions cells require tuning to provide better estimation and approximation of the real situation. There is no methodology clearly defined for model validation at this stage. Researchers can possibly develop a unified process to deal with model validation. The web interface prototype in DR NEP is stable and rich in functionality. However, as one possible area of improvement, web-end developers could look into ergonomic and user-friendly web layouts. A professionally designed website can provide better user experiences, enhance user performance and certainly improve emergency response efficiency. Finally, a role-based access control system is yet to be completed. This intelligent system is designed to direct the users to tasks and specific panels based on their login credentials. The future development of this system involves the login structure, complete back-end web services for each role and unique control panels tailored to specific tasks.  64  Bibliography [1] José R. Martí. (2007, June) INFRASTRUCTURE INTERDEPENDENCIES SIMULATION (I2SIM) TEAM. [Online]. http://www.i2sim.ca/ [2] Lu Liu, "Prototyping and Cells Modeling of the Infrastructure Interdependencies," EECE, 2007. [3] University of British Columbia. (2011) DR-NEP UBC. [Online]. http://drnep.ece.ubc.ca/index.html [4] Denis McClean, "World Disasters Report 2010," Geneva, 2010. [5] National Police Agency Japan, "Special Report I: Police Activities and the Great East Japan Earthquake," National Police Agency Japan, Tokyo, White Paper 2012. [6] OCHA, "Japan Earthquake & Tsunami Situation Report No. 6," Geneva, 2011. [7] HyunJung Lee, "Infrastructure Interdependencies Simulation (I2Sim) System Model and Toolbox," 2010. [8] Paul Lusina, "DR NEP Architecture V1.1," Vancouver, 2011. [9] José R. Martí and I2Sim team, "Modeling Critical Infrastructure Interdependencies in Support of the Security Operations for the Vancouver 2010 Olympics," 2010. [10] Cesar Lopez, "Multi-energy Systems Simulator for Hourly Management and Optimization of GHG Emissions and Fuel Costs," 2011. [11] Logan Hauenstein et al., "A Cross-Functional Service-Oriented Architecture to Support Real-Time Information Exchange in Emergency Medical Response," in IEEE Engineering in Medicine and Biology Society. Conference., United States, 2006. [12] Sahana Software Fundation. (2012) Eden. [Online]. http://sahanafoundation.org/products/eden/ [13] Infoasaid. (2012) inforasaid: Imporving Communication with Crisis-Affected Communities. [Online]. http://infoasaid.org/ [14] Cameron Dale. (2010) DR-NEP: Disaster Response, Network Enabled Platform Architectural Decisions. [Online]. https://dev.ece.ubc.ca/projects/drnep/wiki/ArchitecturalDecisions [15] IBM. IBM and Red Hat Solutions. [Online]. http://www.ibm.com/solutions/alliance/us/en/index/redhat.html [16] Marco A. Gonzalez, José R. Martí, and Philippe Kruchten, "A Canonical Data Model for Simulator Interoperation in a Collaborative System for Disaster Reponse Simulation," , Niagara Falls, 2011, p. 65  IEEE CCECE 2011. [17] Darren Broemmer, J2EE Best Practices: Java Design Patterns, Automation, and Performance, 1st ed., Theresa Hudson, Ed. Indiana, United States of America: Wiley Publishing, Inc., 2003. [18] Inderjeet Singh, Beth Stearns, and Mark Johnson, Designing Enterprise Applications with the J2EE Platform, 2nd ed., Lisa Friendly, Tim Lindholm, and Jim Inscore, Eds. Palo Alto, United States of America: Addison-Wesley, 2002. [19] The Apache Software Foundation. (2000-2008) Welcome to Struts 1. [Online]. http://struts.apache.org/1.x/ [20] Bertrand Portier. (2004, September) Introduction to Service Data Objects. [Online]. http://www.ibm.com/developerworks/library/j-sdo/ [21] Fuhwei Lwo. (2007, April) How to use dynamic data APIs for Service Data Objects 2.1 in a Web service. [Online]. http://www.ibm.com/developerworks/library/ws-sdoapis/ [22] Maven. (2012, June) Dozer, why map? [Online]. http://dozer.sourceforge.net/documentation/whymap.html [23] Dino Esposito, "Pros and Cons of Data Transfer Objects," MSDN Magazine, vol. I, no. 2009, p. 1, August 2009. [24] Hugo Altomonte, "Japan's Nuclear Disaster: its impact on electrical power generation worldwide," IEEE Power & Energy Magazine, vol. 10, no. 3, p. 96, May/June 2012. [25] Eliza Strickland, "24 Hours at Fukushima - Part of the Fukushima and the Future of Nuclear Power Special Report," IEEE Spectrum, vol. I, pp. 34-42, November 2011. [26] Paul Lusina. (2011, September) Disaster Response Network Enabled Platform (DR-NEP) Technical Review. Powerpoint presentation slides. [27] Catherine AE Martí, "Cultural Factors as Modifiers of an Egress Model for the Vancouver 2010 Olympics," The University of British Columbia, Vancouver, Research Report 2009. [28] Paul Lusina. (2012, January) Disaster Response Network Enabled Platform (DR-NEP) Technical Review. Powerpoint Slides.  66  Appendices Appendix A: Sample Code for Web Service of Setting Distribution Value ModelService.wsdl <?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions name="ModelService" targetNamespace="http://model.services.drnep.ubc.ca" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://model.services.drnep.ubc.ca" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:fault="http://fault.services.drnep.ubc.ca" xmlns:sdoReq="http://request.sdo.model.services.drnep.ubc.ca" xmlns:sdoResp="http://response.sdo.model.services.drnep.ubc.ca" xmlns:svcMsg="http://message.model.services.drnep.ubc.ca" > <wsdl:documentation> Service interface definition for the ModelService. </wsdl:documentation>  <wsdl:types> <xsd:schema targetNamespace="http://message.model.services.drnep.ubc.ca"> <xsd:import namespace="http://fault.services.drnep.ubc.ca" schemaLocation="ServiceBaseFaults.xsd" /> <xsd:import namespace="http://request.sdo.model.services.drnep.ubc.ca" schemaLocation="ModelServiceRequest.xsd" /> <xsd:import namespace="http://response.sdo.model.services.drnep.ubc.ca" schemaLocation="ModelServiceResponse.xsd" /> </xsd:schema> </wsdl:types> <wsdl:message name="SetListContinuousFunctionRequestMessage"> <wsdl:part element="sdoReq:SetListContinuousFunctionRequest" name="setListContinuousFunctionRequest"/> </wsdl:message> <wsdl:message name="SetListContinuousFunctionResponseMessage"> <wsdl:part element="sdoResp:SetListContinuousFunctionResponse" name="setListContinuousFunctionResponse"/> </wsdl:message> <wsdl:message name="ServiceFault"> <wsdl:documentation> Message to return on a Service Fault </wsdl:documentation> <wsdl:part element="fault:serviceFault" name="ServiceFault"/> </wsdl:message>  <wsdl:message name="DataValidationFault"> <wsdl:documentation> Message to return on an service input data validation error </wsdl:documentation> <wsdl:part element="fault:dataValidationFault" name="DataValidationFault"/> </wsdl:message>  67  <wsdl:portType name="ModelServiceInterface">  <wsdl:operation name="setListContinuousFunction"> <wsdl:documentation> Set the List of continuous function for a distributor </wsdl:documentation> <wsdl:input message="tns:SetListContinuousFunctionRequestMessage"/> <wsdl:output message="tns:SetListContinuousFunctionResponseMessage"/> <wsdl:fault message="tns:ServiceFault" name="ServiceFault"/> <wsdl:fault message="tns:DataValidationFault" name="DataValidationFault"/> </wsdl:operation>  </wsdl:portType>  <wsdl:binding name="ModelServiceBinding" type="tns:ModelServiceInterface"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>  <wsdl:operation name="setListContinuousFunction"> <soap:operation soapAction="http://model.services.drnep.ubc.ca/setListContinuousFunction"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> <wsdl:fault name="ServiceFault"> <soap:fault name="ServiceFault" use="literal"/> </wsdl:fault> <wsdl:fault name="DataValidationFault"> <soap:fault name="DataValidationFault" use="literal"/> </wsdl:fault> </wsdl:operation> </wsdl:binding>  <wsdl:service name="ModelService"> <wsdl:port binding="tns:ModelServiceBinding" name="ModelService"> <soap:address location="http://localhost:9080/DrNepService/ModelService"/> </wsdl:port> </wsdl:service> </wsdl:definitions>  68  ModelServiceRequest.xsd <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sdoCommon="http://sdo.common.services.drnep.ubc.ca" xmlns:sdoModel="http://sdo.model.services.drnep.ubc.ca" xmlns:tns="http://request.sdo.model.services.drnep.ubc.ca" targetNamespace="http://request.sdo.model.services.drnep.ubc.ca" elementFormDefault="qualified" attributeFormDefault="unqualified">  <xsd:import namespace="http://sdo.common.services.drnep.ubc.ca" schemaLocation="ServiceCommon.xsd"/> <xsd:annotation> <xsd:documentation> Schema definition for the ModelService requests. The message is language independent </xsd:documentation> </xsd:annotation> <!-- elements definition --> <xsd:element name="SetListContinuousFunctionRequest" type="tns:SetListContinuousFunctionRequest"/>  <!-- types definition -->  <xsd:complexType name="SetListContinuousFunctionRequest"> <xsd:annotation> <xsd:documentation> Request data for the Model setListContinuousFunction service </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:extension base="sdoCommon:ServiceRequest"> <xsd:sequence> <xsd:element name="portId" type="xsd:int" maxOccurs="unbounded" minOccurs="0"> <xsd:annotation> <xsd:documentation> The database ID of the current continuous function to set. Note: this ID is corresponding to a specific portId that applies to a ContinuousFunction record </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="transferFunction" type="xsd:string" maxOccurs="unbounded" minOccurs="0"> <xsd:annotation> <xsd:documentation> The transfer function to set on the ContinuousFunction record. Currently, only transfer functions containing a floating point number are allowed. The floating point number should be the factor to multiply the PhysicalEntity's input port value by, to get the output value for this port. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:schema>  69  ModelServiceResponse.xsd <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sdoCommon="http://sdo.common.services.drnep.ubc.ca" xmlns:tns="http://response.sdo.model.services.drnep.ubc.ca" targetNamespace="http://response.sdo.model.services.drnep.ubc.ca" elementFormDefault="qualified" attributeFormDefault="unqualified" xmlns:sdoModel="http://sdo.model.services.drnep.ubc.ca">  <xsd:import namespace="http://sdo.common.services.drnep.ubc.ca" schemaLocation="ServiceCommon.xsd"/> <xsd:import namespace="http://sdo.model.services.drnep.ubc.ca" schemaLocation="ModelCommon.xsd"/> <xsd:annotation> <xsd:documentation> Schema definition for the ModelService responses. The message is language independent. </xsd:documentation> </xsd:annotation> <!-- elements definition --> <xsd:element name="SetListContinuousFunctionResponse" type="tns:SetListContinuousFunctionResponse"/> <!-- types definition -->  <xsd:complexType name="SetListContinuousFunctionResponse"> <xsd:annotation> <xsd:documentation> Response data for Model setListContinuousFunction service operation. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:extension base="sdoCommon:ServiceResponse"> <xsd:sequence> <xsd:element name="currentContinuousFunctionId" type="xsd:int" maxOccurs="unbounded" minOccurs="0"> <xsd:annotation> <xsd:documentation>The database IDs of the CurrentContinuousFunction copied from the request.</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="CurrentContinuousFunction" type="sdoModel:CurrentContinuousFunctionType" maxOccurs="unbounded" minOccurs="0"> <xsd:annotation> <xsd:documentation>The updated CurrentContinuousFunction record. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:schema>  70  ModelServiceBindingImpl.java package ca.ubc.drnep.services.model; import javax.ejb.EJB; import javax.jws.HandlerChain;  import ca.ubc.drnep.common.logging.DebugLog; import ca.ubc.drnep.common.logging.LogFactory; import ca.ubc.drnep.common.util.DateTimeUtil; import ca.ubc.drnep.common.util.StopWatch; import ca.ubc.drnep.services.common.DrNepServiceValidator; import ca.ubc.drnep.services.common.ServiceBinding; import ca.ubc.drnep.services.handler.ModelHandler; import ca.ubc.drnep.services.model.sdo.request.SetListContinuousFunctionRequest; import ca.ubc.drnep.services.model.sdo.response.SetListContinuousFunctionResponse;  @javax.jws.WebService (endpointInterface="ca.ubc.drnep.services.model.ModelServiceInterface", targetNamespace="http://model.services.drnep.ubc.ca", serviceName="ModelService", portName="ModelService") @javax.xml.ws.BindingType (value=javax.xml.ws.soap.SOAPBinding.SOAP11HTTP_MTOM_BINDING) @HandlerChain(file="../../../../../WEB-INF/config/ws-handler-chain.xml") public class ModelServiceBindingImpl extends ServiceBinding { /** Logger */ private static DebugLog logger = LogFactory.getDebugLog(ModelServiceBindingImpl.class.getName()); /** Validator */ private static DrNepServiceValidator validator = new ModelServiceValidator(); @EJB ModelHandler modelHandler;  public GetListContinuousFunctionResponse getListContinuousFunction(GetListContinuousFunctionRequest getListContinuousFunctionRequest) throws DataValidationFault, ServiceFault { try { GetListContinuousFunctionResponse response = new GetListContinuousFunctionResponse(); StopWatch stopWatch = initializeService(logger, getListContinuousFunctionRequest, response); logger.debug("received getListContinuousFunction request: " + getListContinuousFunctionRequest.getPhysicalEntityId());  ca.ubc.drnep.services.dto.model.GetListContinuousFunctionResponse dtoResponse = modelHandler.getListContinuousFunction( getListContinuousFunctionRequest.getPhysicalEntityId()); mapper.map(dtoResponse, response);  }  finalizeService(logger, stopWatch, response); return response; } catch (RuntimeException e) { throwServiceFault(e, ServiceFault.class); throw e; // Never happens }  71  SetListContinuousFunctionRequest.java package ca.ubc.drnep.services.model.sdo.request;  import java.io.Serializable; import java.util.ArrayList; import java.util.List; import javax.xml.bind.annotation.XmlAccessType; import javax.xml.bind.annotation.XmlAccessorType; import javax.xml.bind.annotation.XmlElement; import javax.xml.bind.annotation.XmlType; import ca.ubc.drnep.services.common.sdo.ServiceRequest; @XmlAccessorType(XmlAccessType.FIELD) @XmlType(name = "SetListContinuousFunctionRequest", namespace = "http://request.sdo.model.services.drnep.ubc.ca", propOrder = { "portId", "transferFunction" }) public class SetListContinuousFunctionRequest extends ServiceRequest implements Serializable { @XmlElement(type = Integer.class) protected List<Integer> portId; protected List<String> transferFunction;  public List<Integer> getPortId() { if (portId == null) { portId = new ArrayList<Integer>(); } return this.portId; }  }  public List<String> getTransferFunction() { if (transferFunction == null) { transferFunction = new ArrayList<String>(); } return this.transferFunction; }  72  SetListContinuousFunctionResponse.java package ca.ubc.drnep.services.model.sdo.response;  import java.io.Serializable; import java.util.ArrayList; import java.util.List; import javax.xml.bind.annotation.XmlAccessType; import javax.xml.bind.annotation.XmlAccessorType; import javax.xml.bind.annotation.XmlElement; import javax.xml.bind.annotation.XmlType; import ca.ubc.drnep.services.common.sdo.ServiceResponse; import ca.ubc.drnep.services.model.sdo.CurrentContinuousFunctionType; @XmlAccessorType(XmlAccessType.FIELD) @XmlType(name = "SetListContinuousFunctionResponse", namespace = "http://response.sdo.model.services.drnep.ubc.ca", propOrder = { "currentContinuousFunctionId", "currentContinuousFunction" }) public class SetListContinuousFunctionResponse extends ServiceResponse implements Serializable {  @XmlElement(type = Integer.class) protected List<Integer> currentContinuousFunctionId; @XmlElement(name = "CurrentContinuousFunction") protected List<CurrentContinuousFunctionType> currentContinuousFunction; public List<Integer> getCurrentContinuousFunctionId() { if (currentContinuousFunctionId == null) { currentContinuousFunctionId = new ArrayList<Integer>(); } return this.currentContinuousFunctionId; }  }  public List<CurrentContinuousFunctionType> getCurrentContinuousFunction() { if (currentContinuousFunction == null) { currentContinuousFunction = new ArrayList<CurrentContinuousFunctionType>(); } return this.currentContinuousFunction; }  73  SetListContinuousFunctionResponse.java (in DTO) package ca.ubc.drnep.services.dto.model; import java.util.ArrayList; import java.util.List;  import ca.ubc.drnep.services.dto.common.BusinessResponse;  public class SetListContinuousFunctionResponse extends BusinessResponse { private List<Integer> currentContinuousFunctionId; private List<CurrentContinuousFunctionType> currentContinuousFunction; public List<Integer> getCurrentContinuousFunctionId() { if (currentContinuousFunctionId == null) { currentContinuousFunctionId = new ArrayList<Integer>(); } return this.currentContinuousFunctionId; }  public void setCurrentContinuousFunctionId(List<Integer> value) { this.currentContinuousFunctionId = value; }  public List<CurrentContinuousFunctionType> getCurrentContinuousFunction() { if (currentContinuousFunction == null) { currentContinuousFunction = new ArrayList<CurrentContinuousFunctionType>(); } return this.currentContinuousFunction; }  }  public void setCurrentContinuousFunction(List<CurrentContinuousFunctionType> value) { this.currentContinuousFunction = value; }  74  ModelHandlerIImpl.java package ca.ubc.drnep.services.handler.impl; import java.util.ArrayList; import java.util.Date; import java.util.List; import java.util.Set;  import javax.ejb.EJB; import javax.ejb.Stateless; import org.dozer.Mapper;  import ca.ubc.drnep.common.logging.DebugLog; import ca.ubc.drnep.common.logging.LogFactory; import ca.ubc.drnep.entities.Configuration; import ca.ubc.drnep.entities.ContinuousFunction; import ca.ubc.drnep.entities.CurrentContinuousFunction; import ca.ubc.drnep.entities.CurrentPhysicalMode; import ca.ubc.drnep.entities.CurrentPortValue; import ca.ubc.drnep.entities.Model; import ca.ubc.drnep.entities.PhysicalEntity; import ca.ubc.drnep.entities.PhysicalMode; import ca.ubc.drnep.entities.Port; import ca.ubc.drnep.entities.enums.EntityPlugType; import ca.ubc.drnep.services.config.DrNepServiceBusinessDozer; import ca.ubc.drnep.services.dao.ControllerDao; import ca.ubc.drnep.services.dao.ModelDao; import ca.ubc.drnep.services.dto.model.ContinuousFunctionType; import ca.ubc.drnep.services.dto.model.CurrentContinuousFunctionType; import ca.ubc.drnep.services.dto.model.CurrentPortValueType; import ca.ubc.drnep.services.dto.model.SetListContinuousFunctionResponse; import ca.ubc.drnep.services.handler.ModelHandler; import ca.ubc.drnep.services.rules.ModelRules; /** * Session Bean implementation class ModelHandler */ @Stateless public class ModelHandlerImpl implements ModelHandler {  /** Logger */ private static DebugLog logger = LogFactory.getDebugLog(ModelHandlerImpl.class.getName()); private Mapper mapper = DrNepServiceBusinessDozer.getInstance().getMapper();  @EJB ModelDao modelDao;  @EJB ControllerDao controllerDao;  @EJB ControllerHandler controllerHandler;  /** * Default constructor. */ public ModelHandlerImpl() { }  @Override  75  public SetListContinuousFunctionResponse setListContinuousFunction(List<Integer> portId, List<String> transferFunction) { logger.debug("Setting transfer function to " + transferFunction + " for port: " + portId); List<CurrentContinuousFunction> currentContinuousFunction = modelDao.setListContinuousFunction(portId, transferFunction);  logger.debug("Updated the continuous function: " + currentContinuousFunction);  SetListContinuousFunctionResponse response = new SetListContinuousFunctionResponse(); List<CurrentContinuousFunctionType> currentContinuousFunctionResponse = new ArrayList<CurrentContinuousFunctionType>(); List<Integer> currentContinuousFunctionIdResponse = new ArrayList<Integer>(); for (CurrentContinuousFunction currentContinuousFunctionTemp : currentContinuousFunction){  currentContinuousFunctionIdResponse.add(currentContinuousFunctionTemp.getCurrentContinuousF unctionId());  currentContinuousFunctionResponse.add(mapper.map(currentContinuousFunctionTemp, CurrentContinuousFunctionType.class)); } response.setCurrentContinuousFunctionId(currentContinuousFunctionIdResponse); response.setCurrentContinuousFunction(currentContinuousFunctionResponse); }  }  return response;  76  ModelDaoImpl.java package ca.ubc.drnep.services.dao.impl; import java.util.ArrayList; import java.util.Date; import java.util.List;  import javax.ejb.Stateless; import javax.persistence.EntityManager; import javax.persistence.NoResultException; import javax.persistence.NonUniqueResultException; import javax.persistence.PersistenceContext; import javax.persistence.Query;  import ca.ubc.drnep.common.exception.ServiceErrorConstants; import ca.ubc.drnep.common.exception.ServiceException; import ca.ubc.drnep.common.logging.DebugLog; import ca.ubc.drnep.common.logging.LogFactory; import ca.ubc.drnep.entities.ContinuousFunction; import ca.ubc.drnep.entities.CurrentContinuousFunction; import ca.ubc.drnep.entities.CurrentPhysicalMode; import ca.ubc.drnep.entities.CurrentPortValue; import ca.ubc.drnep.entities.Model; import ca.ubc.drnep.entities.PhysicalEntity; import ca.ubc.drnep.entities.Port; import ca.ubc.drnep.entities.PhysicalMode; import ca.ubc.drnep.entities.PortReplicator; import ca.ubc.drnep.entities.core.EntityManagerHelper; import ca.ubc.drnep.entities.enums.BooleanType; import ca.ubc.drnep.entities.enums.EntityPlugType; import ca.ubc.drnep.services.dao.ModelDao; /** * Session Bean implementation class ModelDao */ @Stateless public class ModelDaoImpl implements ModelDao {  /** Logger */ private static DebugLog logger = LogFactory.getDebugLog(ModelDaoImpl.class.getName()); @PersistenceContext(unitName = "DrNepEntities") EntityManager entityManager;  /** * Default constructor. */ public ModelDaoImpl() { }  @Override public List<CurrentContinuousFunction> setListContinuousFunction(List<Integer> portId, List<String> transferFunction) { List<CurrentContinuousFunction> currentContinuousFunctionCollection = new ArrayList<CurrentContinuousFunction>(); for(int i = 0; i < portId.size(); i++ ){ Port port = entityManager.find(Port.class, portId.get(i)); StringBuilder queryString = new StringBuilder();  77  queryString.append("SELECT ccf FROM CurrentContinuousFunction ccf " + "WHERE ccf.portId = :port "); queryString.append("AND ccf.expiredDate IS NULL"); Query query = entityManager.createQuery(queryString.toString()); query.setParameter("port", port);  CurrentContinuousFunction oldContinuousFunction = (CurrentContinuousFunction) query.getSingleResult();  CurrentContinuousFunction newContinuousFunction = new CurrentContinuousFunction(); newContinuousFunction.setTransferFunction(transferFunction.get(i)); newContinuousFunction.setPortId(port); Date now = new Date(); newContinuousFunction.setEffectiveDate(now); if (oldContinuousFunction != null) { oldContinuousFunction.setExpiredDate(now); logger.debug("Expiring old CurrentContinuousFunction: " + oldContinuousFunction); }  } }  }  entityManager.persist(newContinuousFunction); entityManager.refresh(newContinuousFunction); currentContinuousFunctionCollection.add(newContinuousFunction);  return currentContinuousFunctionCollection;  78  GetListContinuousFunctionResult.jsp <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><%@page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> <%@taglib uri="http://struts.apache.org/tags-html" prefix="html"%> <%@taglib uri="http://struts.apache.org/tags-bean" prefix="bean"%> <%@taglib uri="http://struts.apache.org/tags-logic" prefix="logic"%> <html:html> <head> <link rel="stylesheet" href="theme/Master_i2Sim.css" type="text/css"> <title>DR-NEP List Continuous Function Page</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <meta name="Keywords" content="I2Sim, Infrastructure Interdependencies Simulator, The University of British Columbia, UBC, Dr. Marti, Prof. Jose Marti, The Power Systems Lab at the UBC Electrical and Computer Engineering Department" /> <meta name="Description" content="I2Sim - Infrastructure Interdependencies Simulator." /> <link rel="shortcut icon" href="images/favicon_i2Sim.ico"> </head>  <div class="header"> <jsp:include page="common/header_no_menu.jsp" flush="false"></jsp:include> </div>  <body> <div id="wrapper"> <div class="page-content"> <html:form action="/modelSetListContinuousFunction"> <TABLE width="500" cellpadding="2" border="1"> <THEAD> <TR> <th align="left" bgcolor="#DCDCDC" width="340">To Physical Entity</th> <th align="left" bgcolor="#DCDCDC" width="160">Current Distribution Value:</th> <th align="left" bgcolor="#DCDCDC" width="600">New Distribution Value:</th> </TR> </THEAD> <TBODY>  <logic:iterate id="port" name="port" scope="request"> <bean:define id="currentContinuousFunctionType" name="port" property="value"></bean:define> <TR> <TD align="left"><bean:write name="port" property="key.portName"/></TD> <TD align="left"><bean:write name="currentContinuousFunctionType" property="transferFunction"/></TD> <TD align="left"><html:text property="transferFunction"/></TD> <html:hidden property="portId" value="${port.key.portId}"></html:hidden> </TR> </logic:iterate> </TBODY> </TABLE> <br> <html:submit property="Update" value="Update"></html:submit>&nbsp; <html:reset /> </html:form> </div> <div class="footer"> <%@include file="common/footer.jsp"%></div> </body> </html:html>  79  ModelSetListContinuousFunctionAction.java package ca.ubc.drnep.web.actions; import java.util.Arrays; import java.util.List;  import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import org.apache.struts.action.Action; import org.apache.struts.action.ActionMessage; import org.apache.struts.action.ActionMessages; import org.apache.struts.action.ActionForm; import org.apache.struts.action.ActionForward; import org.apache.struts.action.ActionMapping; import ca.ubc.drnep.common.logging.DebugLog; import ca.ubc.drnep.common.logging.LogFactory; import ca.ubc.drnep.common.util.DateTimeUtil; import ca.ubc.drnep.services.model.sdo.response.SetListContinuousFunctionResponse; import ca.ubc.drnep.web.facade.ModelServiceFacade; import ca.ubc.drnep.web.forms.ModelSetListContinuousFunctionForm; public class ModelSetListContinuousFunctionAction extends Action {  /** Logger */ private static DebugLog logger = LogFactory.getDebugLog(ModelSetListContinuousFunctionAction.class.getName());  public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception { ActionMessages errors = new ActionMessages(); ActionForward forward = new ActionForward(); logger.debug("Received request: " + form);  ModelSetListContinuousFunctionForm modelSetListContinuousFunctionForm = (ModelSetListContinuousFunctionForm) form; logger.debug("portId: " + modelSetListContinuousFunctionForm.getPortId());  List<Integer> portId = Arrays.asList(modelSetListContinuousFunctionForm.getPortId()); List<String> transferFunction = Arrays.asList(modelSetListContinuousFunctionForm.getTransferFunction()); logger.debug("Running action with input: " + portId + ", " + transferFunction); ModelServiceFacade facade = new ModelServiceFacade();  request);  SetListContinuousFunctionResponse wsResponse = facade.setListContinuousFunction(portId, transferFunction, logger.debug("Request completed with response: " + wsResponse);  request.setAttribute("currentContinuousFunction", wsResponse.getCurrentContinuousFunction()); request.setAttribute("currentContinuousFunctionId", wsResponse.getCurrentContinuousFunctionId());  if (!errors.isEmpty()) {  80  saveErrors(request, errors);  // Forward control to the appropriate 'failure' URI (change name as desired) forward = mapping.findForward("failure");  } else { }  }  }  // Forward control to the appropriate 'success' URI (change name as desired) forward = mapping.findForward("success");  // Finish with return (forward);  81  ModelSetListContinuousFunctionForm.java package ca.ubc.drnep.web.forms; import java.util.ArrayList; import java.util.List;  import javax.servlet.http.HttpServletRequest; import org.apache.struts.action.ActionErrors; import org.apache.struts.action.ActionForm; import org.apache.struts.action.ActionMapping;  public class ModelSetListContinuousFunctionForm extends ActionForm { private Integer[] portId = null; private String[] transferFunction = null; public Integer[] getPortId() { return this.portId; }  public void setPortId(Integer[] portId) { this.portId = portId; } public String[] getTransferFunction() { return this.transferFunction; }  public void setTransferFunction(String[] transferFunction) { this.transferFunction = transferFunction; } public void reset(ActionMapping mapping, HttpServletRequest request) {  }  portId = null; transferFunction = null;  public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) { ActionErrors errors = new ActionErrors();  }  return errors; }  82  ModelServiceFacade.java package ca.ubc.drnep.web.facade; import java.util.Date; import java.util.List;  import javax.servlet.http.HttpServletRequest; import javax.xml.ws.BindingProvider; import javax.xml.ws.soap.SOAPBinding;  import ca.ubc.drnep.common.exception.ApplicationException; import ca.ubc.drnep.common.util.DateTimeUtil; import ca.ubc.drnep.services.model.DataValidationFault; import ca.ubc.drnep.services.model.ModelServiceProxy; import ca.ubc.drnep.services.model.ServiceFault; import ca.ubc.drnep.services.model.sdo.ModelType; import ca.ubc.drnep.services.model.sdo.request.SetListContinuousFunctionRequest; import ca.ubc.drnep.services.model.sdo.response.SetListContinuousFunctionResponse; import ca.ubc.drnep.web.config.DrNepWebProperties; public class ModelServiceFacade extends DrNepServiceFacade {  public SetListContinuousFunctionResponse setListContinuousFunction(List<Integer> portId, List<String> transferFunction, HttpServletRequest request) throws ApplicationException { SetListContinuousFunctionRequest req = new SetListContinuousFunctionRequest(); req.setHeaderRequest(createRequestHeader(request)); req.setPortId(portId); req.setTransferFunction(transferFunction);  // define the end point location (use port 9080 if not using TCP/IP monitor) String endpoint = DrNepWebProperties.getModelServiceEndpoint();  ModelServiceProxy proxy = new ModelServiceProxy(); BindingProvider provider = (BindingProvider) proxy._getDescriptor().getProxy(); SOAPBinding binding = (SOAPBinding) provider.getBinding(); binding.setMTOMEnabled(true); proxy._getDescriptor().setEndpoint(endpoint);  }  }  // make the call and print the result SetListContinuousFunctionResponse ret; try { ret = proxy.setListContinuousFunction(req); } catch (DataValidationFault e) { throw new ApplicationException( e.getFaultInfo().getDataValidationErrors().get(0).getCode(), e.getFaultInfo().getDataValidationErrors().get(0).getDefaultMessage(), e.getFaultInfo().getDataValidationErrors().get(0).getFieldName(), e.getFaultInfo().getDataValidationErrors().get(0).getRejectedValue()); } catch (ServiceFault e) { throw new ApplicationException( e.getFaultInfo().getErrorCode(), e.getFaultInfo().getErrorMessage(), e.getFaultInfo().getCauseType(), e.getFaultInfo().getCauseMessage()); } validateServiceResponse(ret); return ret;  83  Appendix B: Sample Code for the KML Generation GisHandlerImpl.java package ca.ubc.drnep.services.handler.impl; import java.io.ByteArrayOutputStream; import java.io.FileNotFoundException; import java.util.ArrayList; import java.util.List; import javax.ejb.EJB; import javax.ejb.Stateless; import org.dozer.Mapper;  import ca.ubc.drnep.common.exception.ServiceErrorConstants; import ca.ubc.drnep.common.exception.ServiceException; import ca.ubc.drnep.common.logging.DebugLog; import ca.ubc.drnep.common.logging.LogFactory; import ca.ubc.drnep.entities.CurrentPhysicalMode; import ca.ubc.drnep.entities.File; import ca.ubc.drnep.entities.Model; import ca.ubc.drnep.entities.Package; import ca.ubc.drnep.entities.PhysicalEntity; import ca.ubc.drnep.entities.PhysicalMode; import ca.ubc.drnep.entities.Port; import ca.ubc.drnep.entities.Configuration; import ca.ubc.drnep.entities.enums.EntityPlugType; import ca.ubc.drnep.entities.enums.KmlType; import ca.ubc.drnep.services.config.DrNepServiceBusinessDozer; import ca.ubc.drnep.services.dao.GisDao; import ca.ubc.drnep.services.dao.ModelDao; import ca.ubc.drnep.services.dto.common.ColorType; import ca.ubc.drnep.services.dto.gis.FileInfoType; import ca.ubc.drnep.services.dto.gis.FileType; import ca.ubc.drnep.services.dto.gis.ListFilesRequest; import ca.ubc.drnep.services.dto.gis.UploadRequest; import ca.ubc.drnep.services.handler.GisHandler; import ca.ubc.drnep.services.rules.ModelRules; import de.micromata.opengis.kml.v_2_2_0.*; import ca.ubc.drnep.services.config.DrNepServiceProperties; @Stateless public class GisHandlerImpl implements GisHandler {  /** Logger */ private static DebugLog logger = LogFactory.getDebugLog(GisHandlerImpl.class.getName()); private Mapper mapper = DrNepServiceBusinessDozer.getInstance().getMapper();  @EJB GisDao gisDao; @EJB ModelDao modelDao;  /** * Default constructor. */  84  public GisHandlerImpl() { } @Override public String uploadPackage(UploadRequest request) { Package pack = gisDao.createPackage(request.getName(), request.getZone(), request.getUser()); String url = null; for (FileType requestFile : request.getFile()) { File file = gisDao.addFileToPackage(pack, requestFile.getName(), requestFile.getData(), requestFile.getFileType()); url = file.getUrl(); } return url; } @Override public List<FileInfoType> listFiles(ListFilesRequest request) { List<FileInfoType> fileList = new ArrayList<FileInfoType>();  List<File> files = gisDao.findFiles(request.getPackageName(), request.getZone(), request.getUser(), request.getFileName(), request.getUrl(), request.getFileType()); for (File file : files) { FileInfoType fileInfo = new FileInfoType(); fileInfo.setPackageName(file.getPackageId().getName()); fileInfo.setZone(file.getPackageId().getZone()); fileInfo.setUser(file.getPackageId().getUser()); fileInfo.setFile(mapper.map(file, FileType.class));  }  fileList.add(fileInfo); } return fileList;  @Override public List<FileType> downloadFiles(List<Integer> fileIds) { List<FileType> fileList = new ArrayList<FileType>(); List<File> files = gisDao.retrieveFiles(fileIds);  for (File file : files) { FileType fileType = mapper.map(file, FileType.class); fileType.setData(gisDao.retrieveFileData(file));  }  fileList.add(fileType); } return fileList;  @Override public byte[] getKmlModel(int modelId) { /** * This method will get called when deploy to the interface and Dao object * will be created automatically. */ logger.debug("Creating KML for model: " + modelId); // Retrieve the requested model from the database Model model = modelDao.getModel(modelId);  85  logger.debug("Found model: " + model);  // Verify the model exists if (model == null) { throw new ServiceException(ServiceErrorConstants.ERR1301, ServiceErrorConstants.ERR1301_MSG, ServiceErrorConstants.MISSING_JPA_ENTITY_TYPE, "Could not create KML for model, not found: " + modelId); } // Populate the KML object from the model Kml kml = createKmlFromModel(model);  // Marshal the KML into a file (byte array) ByteArrayOutputStream kmlOutput = new ByteArrayOutputStream(); try { kml.marshal(kmlOutput); } catch (FileNotFoundException e) { throw new RuntimeException("This should never occur", e); }  if (logger.isDebugEnabled()) { logger.debug("Created new KML for model: " + kmlOutput.toString()); }  }  return kmlOutput.toByteArray();  /** * Method for getting icon href for different physical entities * @param KmlType * @return */ private static String iconHref(KmlType kmlType) { String IpAddress = DrNepServiceProperties.getIpAddress(); switch (kmlType) { case DISTRIBUTOR: return IpAddress + "DrNepWeb/images/KML/Distributor64.png"; case ELECTRICAL_STATION: return IpAddress + "DrNepWeb/images/KML/ElecSub64.png"; case HOSPITAL: return IpAddress + "DrNepWeb/images/KML/Hospital64.png"; case VENUE: return IpAddress + "DrNepWeb/images/KML/Venue64.png"; case WATER_STATION: return IpAddress + "DrNepWeb/images/KML/WaterSub64.png"; case ELEC_SOURCE: return IpAddress + "DrNepWeb/images/KML/ElecSource64.png"; case WATER_SOURCE: return IpAddress + "DrNepWeb/images/KML/Water64.png"; case CHANNEL: return IpAddress + "DrNepWeb/images/KML/Channel64.png"; default: return IpAddress + "http://maps.google.com/mapfiles/kml/pushpin/ylw-pushpin.png"; } } /** * Parses the Model and its children and populates the KML object. * @param model the Model entity to parse  86  * @return the populated KML object */ protected Kml createKmlFromModel(Model model) { /** * Main section to work on, using JAK to create complete model. */ // Create a new KML object to populate with the model Kml kml = new Kml();  /** * Model retrieving using iterator */ /*Iterator<PhysicalEntity> placemarkItr = model.getPhysicalEntityCollection().iterator(); PhysicalEntity placemarkEntity = new PhysicalEntity(); while(placemarkItr.hasNext()){ placemarkEntity = placemarkItr.next(); } String placemarkName = placemarkEntity.getPhysicalEntityName(); double placemarkLog = placemarkEntity.getLocationId().getGeoPointId1().getLongitude().doubleValue(); double placemarkLat = placemarkEntity.getLocationId().getGeoPointId1().getLatitude().doubleValue();*/  String IpAddress = DrNepServiceProperties.getIpAddress(); /** * Model retrieving using for-each loop */ ArrayList<String> placemarkName = new ArrayList<String>(); ArrayList<String> sourceName = new ArrayList<String>(); ArrayList<String> destinationName = new ArrayList<String>(); ArrayList<Integer> physicalEntityId = new ArrayList<Integer>(); ArrayList<PhysicalMode> placemarkMode = new ArrayList<PhysicalMode>(); ArrayList<Boolean> distributorCheck = new ArrayList<Boolean>(); ArrayList<Boolean> sourceCheck = new ArrayList<Boolean>(); ArrayList<String> placemarkIcon = new ArrayList<String>(); ArrayList<Double> placemarkLog1 = new ArrayList<Double>(); ArrayList<Double> placemarkLog2 = new ArrayList<Double>(); ArrayList<Double> placemarkLog3 = new ArrayList<Double>(); ArrayList<Double> placemarkLog4 = new ArrayList<Double>(); ArrayList<Double> placemarkLat1 = new ArrayList<Double>(); ArrayList<Double> placemarkLat2 = new ArrayList<Double>(); ArrayList<Double> placemarkLat3 = new ArrayList<Double>(); ArrayList<Double> placemarkLat4 = new ArrayList<Double>(); ArrayList<Double> placemarkAlt1 = new ArrayList<Double>(); ArrayList<Double> placemarkAlt2 = new ArrayList<Double>(); ArrayList<Double> placemarkAlt3 = new ArrayList<Double>(); ArrayList<Double> placemarkAlt4 = new ArrayList<Double>(); ArrayList<Double> pathConnectionOutLog = new ArrayList<Double>(); ArrayList<Double> pathConnectionOutLat = new ArrayList<Double>(); ArrayList<Double> pathConnectionOutAlt = new ArrayList<Double>(); ArrayList<Double> pathConnectionInLog = new ArrayList<Double>(); ArrayList<Double> pathConnectionInLat = new ArrayList<Double>(); ArrayList<Double> pathConnectionInAlt = new ArrayList<Double>();  for (PhysicalEntity placemarkEntity : model.getPhysicalEntityCollection()){ if(placemarkEntity.getKmlType()!= null){ placemarkName.add(placemarkEntity.getPhysicalEntityName()); logger.debug("This placemark name is "+placemarkEntity.getPhysicalEntityName()); physicalEntityId.add(placemarkEntity.getPhysicalEntityId()); if(placemarkEntity.getEntityPlugType().equals(EntityPlugType.DISTRIBUTOR)){  87  }else{  distributorCheck.add(true);  distributorCheck.add(false); } if(placemarkEntity.getEntityPlugType().equals(EntityPlugType.SOURCE)||placemar kEntity.getEntityPlugType().equals(EntityPlugType.EXTERNAL_SOURCE)||placemar kEntity.getEntityPlugType().equals(EntityPlugType.CHANNEL)){ sourceCheck.add(true); }else{ sourceCheck.add(false); } if(placemarkEntity.getEntityPlugType().equals(EntityPlugType.DISTRIBUTOR)||plac emarkEntity.getEntityPlugType().equals(EntityPlugType.SOURCE)||placemarkEntity .getEntityPlugType().equals(EntityPlugType.EXTERNAL_SOURCE)||placemarkEntity. getEntityPlugType().equals(EntityPlugType.CHANNEL)){ logger.debug("I'm here and my entityPlugType is "+placemarkEntity.getEntityPlugType()); PhysicalMode physicalModeTemp = new PhysicalMode(); physicalModeTemp.setPhysicalModeConsecutive((short) 0); placemarkMode.add(physicalModeTemp); }else{ for (CurrentPhysicalMode currentPhysicalMode: placemarkEntity.getCurrentPhysicalModeCollection()){ if(currentPhysicalMode.getExpiredDate()==null){ placemarkMode.add(currentPhysicalMode.getPhysicalModeId()); } } } placemarkIcon.add(iconHref(placemarkEntity.getKmlType())); if(placemarkEntity.getPortCollection() != null){ for (Port port: placemarkEntity.getPortCollection()){ if(port.getConfigurationBySourceCollection() != null){ for(Configuration portConfiguration :port.getConfigurationBySourceCollection()){ sourceName.add(placemarkEntity.getPhysicalEntityName());  pathConnectionOutLog.add(placemarkEntity.getLocationId().getGeoPointI d1().getLongitude().doubleValue()); pathConnectionOutLat.add(placemarkEntity.getLocationId().getGeoPointI d1().getLatitude().doubleValue()); pathConnectionOutAlt.add(placemarkEntity.getLocationId().getGeoPointI d1().getAltitude().doubleValue()); PhysicalEntity destinationEntity = portConfiguration.getDestination().getPhysicalEntityId();  destinationName.add(destinationEntity.getPhysicalEntityName());  }  pathConnectionInLog.add(destinationEntity.getLocationId().getGeoPointI d1().getLongitude().doubleValue()); pathConnectionInLat.add(destinationEntity.getLocationId().getGeoPointId 1().getLatitude().doubleValue()); pathConnectionInAlt.add(destinationEntity.getLocationId().getGeoPointId 1().getAltitude().doubleValue()); } } }  88  placemarkLog1.add(placemarkEntity.getLocationId().getGeoPointId1().getLongitude().doubleValue()); placemarkLog2.add(placemarkEntity.getLocationId().getGeoPointId2().getLongitude().doubleValue()); placemarkLog3.add(placemarkEntity.getLocationId().getGeoPointId3().getLongitude().doubleValue()); placemarkLog4.add(placemarkEntity.getLocationId().getGeoPointId4().getLongitude().doubleValue()); placemarkLat1.add(placemarkEntity.getLocationId().getGeoPointId1().getLatitude().doubleValue()); placemarkLat2.add(placemarkEntity.getLocationId().getGeoPointId2().getLatitude().doubleValue()); placemarkLat3.add(placemarkEntity.getLocationId().getGeoPointId3().getLatitude().doubleValue()); placemarkLat4.add(placemarkEntity.getLocationId().getGeoPointId4().getLatitude().doubleValue()); placemarkAlt1.add(placemarkEntity.getLocationId().getGeoPointId1().getAltitude().doubleValue()); placemarkAlt2.add(placemarkEntity.getLocationId().getGeoPointId2().getAltitude().doubleValue()); placemarkAlt3.add(placemarkEntity.getLocationId().getGeoPointId3().getAltitude().doubleValue()); placemarkAlt4.add(placemarkEntity.getLocationId().getGeoPointId4().getAltitude().doubleValue()); } } Document document = kml.createAndSetDocument().withName(model.getModelName()+".kml"); Folder folder = document.createAndAddFolder().withName(model.getModelName()).withOpen(true); Folder folderProductionCell = folder.createAndAddFolder().withName("ProductionCell").withOpen(true); Folder folderPath = folder.createAndAddFolder().withName("Path").withOpen(true); for (int i = 0;i < placemarkName.size();i++){ /** * Create Style section on KML */ ColorType physicalModeColorType = ModelRules.populatePhysicalModeColor(placemarkMode.get(i)); String physicalModeColor = physicalModeColorType.getKmlCode(); Style physicalEntityStyle = document.createAndAddStyle().withId(placemarkName.get(i)+"Style"); String href = placemarkIcon.get(i); IconStyle iconStyle = physicalEntityStyle.createAndSetIconStyle().withScale(1.2); iconStyle.createAndSetIcon().withHref(href); physicalEntityStyle.createAndSetPolyStyle().withColor("ff"+ physicalModeColor).withColorMode(ColorMode.NORMAL); physicalEntityStyle.createAndSetLineStyle().withColor("ff000000").withWidth(4.0d); /** * Create Ploygon section on KML */  Placemark placemark = folderProductionCell.createAndAddPlacemark() .withName(placemarkName.get(i)) .withStyleUrl("#"+placemarkName.get(i)+"Style"); if (distributorCheck.get(i) == true){ placemark.withDescription("<![CDATA[" + "<p> <a href = "+ IpAddress + "DrNepWeb/modelGetListContinuousFunction.do?physicalEntityId=" + physicalEntityId.get(i)+"> Click here to view and change the distribution</a></p>"); }else if(sourceCheck.get(i) == true){ placemark.withDescription("<![CDATA[" + "<p> <a href = "+ IpAddress + "DrNepWeb/modelGetSourceFunctionNew.do?physicalEntityId=" + physicalEntityId.get(i)+"> Click here to change the value</a></p>"); }else{ placemark.withDescription("<![CDATA[" + "<p> <a href = "+ IpAddress + "DrNepWeb/modelPhysicalModeList.do?physicalEntityId=" + physicalEntityId.get(i)+"> Click here to change the Physical Mode</a></p>"); } MultiGeometry multiGeometry = placemark.createAndSetMultiGeometry(); multiGeometry.createAndAddPoint().addToCoordinates(placemarkLog1.get(i),placemarkLat 1.get(i),placemarkAlt1.get(i));  89  }  multiGeometry.createAndAddPolygon() .createAndSetOuterBoundaryIs().createAndSetLinearRing() .addToCoordinates(placemarkLog1.get(i),placemarkLat1.get(i),placemarkAlt1.get(i)) .addToCoordinates(placemarkLog2.get(i),placemarkLat2.get(i),placemarkAlt2.get(i)) .addToCoordinates(placemarkLog3.get(i),placemarkLat3.get(i),placemarkAlt3.get(i)) .addToCoordinates(placemarkLog4.get(i),placemarkLat4.get(i),placemarkAlt4.get(i)); *//** * Function is disabled for presentation purpose *//*  /*for (int i = 0;i< sourceName.size();i++){ *//** * Create path style for KML *//* Style pathStyle = document.createAndAddStyle().withId(sourceName.get(i)+" to "+destinationName.get(i)+" Style"); pathStyle.createAndSetLineStyle().withColor("ffff0055").withWidth(3.0d);  "+destinationName.get(i))  *//** * Create path section on KML *//* folderPath.createAndAddPlacemark().withName(sourceName.get(i)+"to  .withDescription(sourceName.get(i)+" to "+destinationName.get(i)+" channel") .withStyleUrl("#"+sourceName.get(i)+" to "+destinationName.get(i)+" Style") .createAndSetLineString().withTessellate(true) .addToCoordinates(pathConnectionOutLog.get(i), pathConnectionOutLat.get(i), pathConnectionOutAlt.get(i)) .addToCoordinates(pathConnectionInLog.get(i), pathConnectionInLat.get(i), pathConnectionInAlt.get(i)); }*/ /*List<PhysicalEntity> placemarkEntity;  while(placemarkItr.hasNext()){ placemarkEntity.add(placemarkItr.next()); }*/ }  }  return kml;  90  

Cite

Citation Scheme:

    

Usage Statistics

Country Views Downloads
United States 22 2
Canada 12 0
China 5 4
Trinidad and Tobago 4 0
Thailand 3 0
Russia 3 0
Japan 3 0
Indonesia 2 2
Turkey 2 2
France 1 0
Tunisia 1 0
Netherlands 1 0
Republic of Korea 1 0
City Views Downloads
San Francisco 11 0
Unknown 7 32
Ashburn 4 0
Shenzhen 4 4
Port of Spain 4 0
Bangkok 3 0
Vancouver 3 0
Ottawa 3 0
Wilmington 3 0
Tokyo 3 0
Istanbul 2 2
Langley 2 0
Calgary 2 0

{[{ mDataHeader[type] }]} {[{ month[type] }]} {[{ tData[type] }]}
Download Stats

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-0072996/manifest

Comment

Related Items