Navigation Assistance Framework for Emergencies Paul Ngo Duminda Wijesekera Department of Computer Science Department of Computer Science George Mason University George Mason University 4400 University Drive, MS 4A4 4400 University Drive, MS 4A4 Fairfax, Virginia 22030 Fairfax, Virginia 22030 Email: pngo1@gmu.edu Email: dwijesek@gmu.edu Abstract—Emergencies occur every day at unexpected times approach is to provide commuters with relevant emergency and impact our lives in unimaginable ways. In any emergency advice based on the type of the emergency. situation, there are two type of victims: direct victims and indirect In 2006, the Federal Government established a Worker victims. Both will have their current plans disrupted in order to deal with the emergency. Federal, State, and Local governments Adjustment and Retraining Notification (WARN) Act that have established a 911 system to assist direct victims. However, supported the research and development of Common Mobile there is still lack of assistance provided to the indirect victims. In Alert System (CMAS) [15]. The proposed CMAS system this paper, we propose a Navigation Assistance Framework that utilizes existing commercial telecommunication infrastructures allows emergency organizations to provide emergency informa- to broadcast emergency alerts and warnings to a specified tion that can assist victims navigating out of the emergency area and reaching their intended destinations in a reasonable amount geographic area. We have extended the usability of CMAS of time. We develop an emergency prototype ERSimMon to to broadcast alerts to small-scale local emergencies [2]. We simulate this capability in a small scale to show the effectiveness convey these local emergencies by sending the GPS location of the proposed solution. In addition, we develop the Emergency of the emergency and the affected area measured by the Response Application (ERApp) for a smart phone platform, radius from the emergency GPS location to mobile users’ which intercepts the enhanced Commercial Mobile Alert System (CMAS) broadcast message, displays the user’s location with devices. We also enhanced the original CMAS limitation on respect to the emergency location on the map and provides the message size of 90 readable characters [1]. Both of these navigational assistance and recommend actions to help the user CMAS enhancements allow local emergency information to navigate out of ongoing emergencies. be broadcast to mobile users more effectively. To provide relevant navigational assistance to mobile users I. I NTRODUCTION in a variety of emergencies, from the most dynamic, like a tornado or hurricane, to the least changing such as construc- According to the Out-of-State and Long Commutes Survey tion road blocks, we need the most up-to-date information 2011 [12], 8.1 percent of U.S. workers had commutes of 60 regarding the emergency. We propose a Navigation Assistance minutes or longer. In addition, 61.1 percent of the workers Framework (NAF) to set a foundation for possible future drove to work alone. Americans spend significant amounts of works. The NAF acts as a central hub, which collects rel- time, on the average of 25 minutes [13] in their vehicles on evant emergency information and distributes it to registered the road to go from home to work on a normal working day. instances of our smart phone application, ERApp. This de- Added to average commute time, local emergencies such as velopment is aligned with the Dynamic Mobile Application car accidents, road construction, inclement weather, etc. may initiative from the US Department of Transportation [20], add extra delays into the average commute time. Commuters which can be adapted to cars to alert drivers when approaching have to adjust to these unexpected delays on a case-by-case work-zones or construction sites [21]. basis. Consequently, they may have to shift their schedule or The rest of the paper is organized as follows: section II rearrange appointments and meetings to accommodate for the discusses NAF requirements and some supporting use cases. time lost sitting in traffic. Sometimes, cancellations and delays Section III discusses the NAF design and implementation. are unavoidable. According to a poll conducted by ABCNews Section IV discusses results of our experiments. Section V on traffic in the United States [14], the average commute time describes related works and we conclude in section VI. on a bad day for Americans is 46 minutes. Clearly, dealing with unexpected delays is a major concern II. NAVIGATION A SSISTANCE F RAMEWORK for commuters. We address this concern with two approaches. R EQUIREMENTS AND U SE C ASES The first approach is to provide commuters with navigational In this section, we specify some requirements and objectives assistance that offers alternative routes to their destinations in that organizations may implement in their processes and order to avoid an impending emergency and its affected area. operations in order to provide emergency information to other This may be a great help to commuters who are not familiar trusted organizations. A requirement contains the word ”shall” with an area or who waste time sitting in traffic. The second and is identified by the letters ”R”. An Objective is a feature STIDS 2013 Proceedings Page 149 or function that is desirable, but not mandatory. An Objective contains the words ”it is desirable” and is identified by the letters ”O”. R#1: There shall be a way to provide current information about any impending emergency. R#2: There shall be a way to provide directions to avoid the impending emergency. O#1: It is desirable that users provide daily events in their calendars and expose them to the trusted entity in order to provide relevant and immediate actions during time of crisis. Fig. 1. Navigation Assistance Framework High-Level Components A. Use Cases In this subsection, we describe use cases that are derived Emergency Sources, Commercial Mobile Alert System from the above requirements. (CMAS) [15], Navigation Assistance Framework, Emergency Use Case 1: A driver with an ERApp running on his hand- Response Application (ERApp), Emergency Response Simu- held device drives to work as a part of his regular routine. lation Monitor, and Google Map Services. The following two use cases occur when the driver receives Emergency Sources are emergency systems that have the a CMAS message informing him that there is an emergency capability to monitor the progression of an emergency and to in the area. ERApp appears on his hand-held device, showing provide updates if needed by other systems. These emergency the location of the ongoing tornado, his location and the work systems can expose their emergency information as a service. location. He then determines that: We provide a set of interfaces in table II that can be im- Use Case 2: his route to work has not been impacted by the plemented by Emergency Sources. For example, the National ongoing tornado. Hurricane Center [18] is considered one of the Sources for Use Case 3: his route to work is impacted by the ongoing emergency information. The Emergency Sources push the tornado. most up-to-date emergency data to the CMAS through a The first use case illustrates a sunny day scenario where web service connection as indicated by the arrow going drivers don’t encounter any problems on the road that pre- from the Emergency Sources to CMAS in Figure 1. The vent them from arriving at work on time. However, traffic CMAS operator will generate the broadcast message based accidents and natural emergencies such as tornados, heavy on the emergency data and broadcast it. We have proposed rains, blizzards, snow storms, hail, or other severe weather a few enhancements [1], [2] to improve the content of the conditions would prevent drivers from arriving at work on broadcast message and the area effected by an emergency. The time. Delays caused by these emergencies can be up to hours. CMAS broadcasts 90-character text messages of emergencies The second and third use cases illustrate that an emergency to all mobile devices through ERApp, a mobile emergency has occurred in the area. In this case, we illustrate with an application installed on the users’ mobile devices (how the impending tornado because the tornado is a medium scale ERApp is certified and installed on mobile devices is beyond emergency and its movement can be tracked by the National the scope of this paper). In addition, the CMAS pushes the Weather Center (NWC) [19]. The NWC then can provide the emergency data to the NAF as indicated by the arrow going Navigation Assistance Framework crucial data such as the from the CMAS to the NAF through a web service connection direction and the speed of the tornado. We can then use these in Figure 1. data to calculate and estimate the impact further. The Navigation Assistance Framework provides a set of interfaces that Emergency Sources need to implement and III. NAVIGATION A SSISTANCE F RAMEWORK acts as a listener to the emergency data and advice policies. A RCHITECTURE AND I MPLEMENTATION Whenever needed, the Navigation Assistance Framework pulls We describe major components and the functionality of the the most up-to-date emergency data and advice policies from Navigation Assistance Framework (NAF) in this section. First, the Emergency Sources as indicated by the arrow going from we provide a high-level description of each component and its the Navigation Framework to Emergency Sources in Figure 1. function in the overall architecture. The ERApp can make an advice policy update request to the NAF when the ERApp detects that the user is in motion A. Architecture Components during an ongoing emergency as indicated by the arrow going Figure 1 shows the high-level architectural components both directions from the ERApp to the NAF in Figure 1. The for the Navigation Assistance Framework. It consists of ERApp uses the Google Map Web Services to display a user’s STIDS 2013 Proceedings Page 150 position with respect to the occurring emergency as indicated allow the Navigation Assistance Framework to be used in the by the arrow going from the ERApp to Google Map Web most effective way and expose its full capabilities. Here is the Services in Figure 1. The ERApp applies the advice policies list of enhancements: to see if the current status of users’ behaviors satisfy the First, we propose an enhancement to the Google Maps conditions on the policy and displays the emergency advice API web services [7] to include a list of constraints and recommended by the policy. For example, the advice policy road blocks. The original URL to get directions from can say that if the user at rest is 3000 meters away from the Google is: http://maps.googleapis.com/maps/api/directions/ center of an emergency, the user needs to consider teleworking xml?origin=[]&destination=[]&sensor=[true|false] where the for the day. Figure 2 shows such a sample policy written origin parameter specifies the origination address. The desti- in XACML [17]. XACML policy language answers yes or nation parameter specifies the destination address. The sensor no to the access control request based on some conditions parameter indicates that the directions request comes from a stated in a policy. Consequently, XACML is not capable device with a location sensor. There are a few optional param- of providing emergency advice. Therefore, the NAF uses eters such as mode= [driving|walking|bicycling|transit], way- XACML to evaluate conditions in emergency advice policies points, alternatives= [true|false], avoid= [tolls|highways], lan- given by Emergency Sources before advising users. guage, units, region, departure time, and arrival time. None In general, these arrows presented in the figure 1 are defined of these parameters provide the directions to avoid emergency by either push, pull or both push and pull web services. road blocks or help navigate around pending emergencies. Implementation and the hosting of these web services are At best alternative parameters provide several routes to the beyond the scope of this paper. destination, without any guarantee that these routes will avoid emergency road blocks or the pending emergency. Therefore, our enhancement adds one parameter eblocks into the Google Maps API web service, which gives the GPS location and the radius of the blocking area. The parameter has three values: latitude, longitude, and radius. For example: eblocks=38.8462236,-77.3063733,500m. In this example, we indicate that the emergency occurs in Fairfax, VA which has the GPS location of 38.8462236,-77.3063733 and we should avoid all the roads within 500 meters of that particular location. The NAF doesn’t depend on the Google Map enhancement to provide alternative routes in order to avoid the area affected by an emergency. But in this paper, we show how Google could implement this enhancement as we describe below. The NAF can use major routes and intersections as preexisting points and build a directed path using the Shortest Path (in time and distance) algorithm [25] to determine the path to the destination. For every connecting point as a new temporary destination, the NAF uses the algorithm 2 to determine that the route to new temporary destination is out of the affected area. Second, we enhance the emergency source services to pro- vide the most up-to-date emergency information. We provide Fig. 2. Emergency Advice XACML Policy emergency sources with a set of APIs so that they can connect with our framework via web services. The Emergency Simulation Monitor (ERSimMon) uses the Navigation Assistance Framework to simulate an emergency B. NAF Functionality and the people who are trying to navigate through it. The We describe the functions built into the Navigation Assis- ERSimMon uses the Google Maps API web services to tance Framework to support the use cases given above. In the query the list of emergency constraints and road congestion sunny day scenario, users can get the navigation assistance information in order to suggest the best routes that the user from the regular GPS or the ERApp. Without any emergency can take to reach his destinations. This pulling connection occurrences during rush hours, users can anticipate their on- is indicated by the arrow going from the ERSimMon to the time arrivals at their desired destinations. However, emergency Google Map Web Services in Figure 1. incidents do occur at unexpected times and have the potential For these components to work seamlessly, we need to make to create a long delay in travel time. With the ERApp installed a couple of enhancements to the Google Maps API web service on handheld devices, users are able to receive an enhanced and Emergency Source web service. These enhancements CMAS broadcast emergency message [1], [2] that provides STIDS 2013 Proceedings Page 151 more details about the impending emergency incident. In addi- radius of the affected area to Google Maps, which in turn tion, ERApp is equipped to receive frequent updates about the provides the updated directions to the destination. impending emergency status including tracking information The format of the updated text message sent from the NAF such as GPS location, time, intensity, effected area, etc. This to ERApps must be agreed upon and interpreted. The format information is necessary for the ERApp to better advise and is a list of name-value pairs. The name must be abbreviated direct users to their destinations. The goal is to avoid possible by 2 capitalized characters, where character is one byte, and road blocks and dangerous areas that are being affected by the value must be a primitive type. These names and and emergency incidents. We can achieve this goal if we have associated types must be accessible by the NAF and the updated emergency information. ERApp. Table I provides these names, associated types and 1) Emergency Data: Depending on the type of emergency, short descriptions of each attribute. information may come from different sources. For example, tornado data may come from the National Weather Center. TABLE I T EXT M ESSAGE VALUES Hurricane data may be retrieved from the National Hurricane Center. Road closures in the local area may come from the local police department or the Department of Transportation. Parameter Type Description Therefore, we need to establish a method of retrieving these ID Integer Emergency Identification emergency data from various sources and determine if the ET Integer Emergency Type connection is either push, pull, or both. LT Long Latitude The Navigation Assistance Framework acts as a centralized LN Long Longitude emergency assistance process which dispatches emergency RD Integer Radius information to all devices and receives regular updates from DR Byte Emergency Direction emergency sources. With this, the Navigation Assistance SP Integer Speed of moving emergency Framework needs to subscribe to all of the emergency sources AP String Advice policies in XML format to pull and push emergency data. In addition, the NAF needs to allow ERApp to subscribe in order to receive emergency updates. Depending on users’ circumstances, the NAF supports According to the SMS Specification [9], an SMS Message either pull or push subscriptions from ERApp. has a limitation of 160 readable characters. If we represent this Each emergency has its own data set relevant to our frame- SMS message as readable characters, there may not be enough work. For a tornado, we collect the following emergency data: readable characters to hold values of all these attributes. time when the tornado touched down, its track including the Therefore, we represent these values as binary values and GPS location of the tornado, wind speed and direction, and encode them using the Base 64 Encoding [10] in order to the storm intensity measured in Fujita Scale (F-Scale) [8]. fit within 90 character as described in our previous work [1]. For road closures such as a car accident, road construction, C. Implementation water main break, etc., we collect the following emergency data: starting date and time of the closure, the anticipated date This subsection will detail the implementation of the Navi- and time of the re-opening of the road, GPS location, and the gation Assistance Framework. We also suggest some interfaces radius of the affected area. The purpose of getting this data that Emergency Sources and Google Maps Web Services need is to provide the magnitude of the emergency, GPS location, to implement to make this framework. However, we provide a and its severity. This allows the framework to approximate the prototype implementation of these interfaces working together. danger area and to provide frequent updates to ERApp so that 1) Emergency Data Collection: Figure 1 shows that the ERApp can assist users to navigate around the danger area. NAF receives emergency data from two sources such as 2) Updating the Directions: After the Navigation Assis- CMAS and Emergency Sources (including periodic updates). tance Framework receives the emergency data from the Emer- CMAS sends the CMAS message [1] to the NAF in its broad- gency Source, it sends the updated data using text messaging cast. Two important pieces of data are the GPS location of to all the devices that have installed ERApp and registered the impending emergency and the radius of the affected area. with the NAF. The ERApp determines the next step. ERApp NAF uses this information to load the impending emergency will formulate a new query to get the updated routes to the details onto the map as shown in Figure 3. The Emergency destination, if the impending emergency is going to be in Sources can push it to the NAF directly. Table II shows NAF the forecast path. We make a general assumption that users interfaces with the Emergency Sources. will manually enter into their event calendars the location Method Return Type Parameters Description addresses of where they will be and from what time to sendUpdate int (int iEID, HashMap mapNVP) Send update values for the impending emer- gency. what time they are going to be there. These calendar fields pullUpdate HashMap (int iEID) Return the update name-value pair hashmap for the impending emergency. such as location, time start and time end are in the Internet Calendar Specification [11]. The ERApp will use this location TABLE II address as the destination or allow users to enter their current I NTERFACE FOR IES OURCE I MPLEMENTATION destinations. The ERApp will send the GPS location and the STIDS 2013 Proceedings Page 152 Algorithm 1 :getUpdatedDirections Algorithm (Input: HashMap mapNVP, UserProfile up, String calURL) Require: mapN V P 6= null Require: up 6= null Require: calU RL 6= null 1: xmlDirDoc null 2: calEvent null 3: cCal newCalendarService() 4: cCal.setCreds(up.getW Email(), up.getW EmailP C()) Fig. 3. Impending Tornado 5: calQuery newCalendarQuery(calU RL) 6: resultEvents cCal.query(calQuery) Emergency Data Name Space Data Type Description 7: if resultEvents.getEntries().size() > 0 then TND Longitude Long GPS longitude location. TND Latitute Long GPS location latitude location. 8: resultEvents sortEvents(resultEvents) Tornado TND Direction String Current Direction: East, West, North, South, North-East, South-West, etc. 9: iterEvents resultEvents.getEntries().iterator()) TND Wind Speed Integer Wind Speed measured in miles/hour. 10: while iterEvents.hasN ext() do TND Radius Integer Radius of the affected area measured in mi (miles), m (meters), km (kilometers). 11: calEntry iterEvents.next() Road Blocks RB Longitude RB Latitute Long Long GPS longitude location. GPS location latitude location. 12: if calEntry.getT imeStart() > now() then RB Radius Integer Radius of the affected area measured in mi 13: calEvent calEntry (miles), m (meters), km (kilometers). 14: break TABLE III 15: end if DATA NAME S PACE 16: end while 17: end if 18: if calEvent is N OT null then 19: dest calEvent.getLocation() In order for NAF to interpret data, we use the following 20: erLat mapN V P.get(”LT ”) naming conventions. Table III suggested names and types are 21: erLon mapN V P.get(”LN ”) the binding agreements between the NAF and Emergency 22: erR mapN V P.get(”RD”) Sources, that we use to retrieve associated values and convert 23: urlDir f ormU RL(erLat, erLon, erR, dest) them. 24: url U RL(urlDir) 2) Navigation Update: The NAF sends an updated text 25: inputStream url.openstream() message to all the registered ERApps installed on mobile de- 26: dbf DocumentBuilderF actory.newInstance() vices. ERApps decode the message and extract the emergency 27: db dbf.newDocumentBuilder() information. The ERApp then uses this information to query 28: xmlDirDoc db.parse(inputStream) the Google Maps web services for updated directions. In the 29: xmlDirDoc.getDocumentElement().normalize() prototype implementation, we use Google Calendar to retrieve 30: end if users’ calendar event information such as the location and the 31: return xmlDirDoc time. Algorithm 1 computes driving directions that avoid the affected area of the impending emergency and helps users 8. We create the event iterator on line 9 and go through all navigate to their destinations. The algorithm takes three param- the calendar events on line 10. We retrieve the calendar event eters. The first parameter mapNVP is the hash map containing entry calEntry on line 11. If the event time is greater than the name-value pairs. The second parameter up is the user profile, current time on line 12, we set the calendar event calEvent to which contains the email credentials to access the calendar. calEntry on line 13 and exit out of the while loop on line 14. The third parameter calURL is the Google Calendar web On line 18, the calEvent is tested for null value. If it is null, service URL. On lines 1 and 2, the algorithm initializes then the algorithm ends there and return the null xmlDirDoc on two temporary variables xmlDirDoc and calEvent to null line 31. If calEvent is not null, the destination will be retrieved respectively. The xmlDirDoc is the updated direction in XML from the calendar event on line 19. The algorithm retrieves format, which is the return value for this algorithm. On line the emergency latitude, longitude, radius of the affected area 3, the calendar service is created for the ERApp client cCal. from the hash map name-value pairs mapNVP on lines 20, On line 4, client calendar is set with the credentials including 21, and 22 respectively. The Algorithm then forms the Google the email address and the email passcode, which are used to map URL urlDir with parameters such as the current location, authenticate the calendar service. The calendar query is created destination, affected area radius, and the emergency GPS from the calendar URL on line 5. We begin to query calendar location on line 23. The URL object is created from the events from the calendar service on line 6. We check if there urlDir on line 24. The input stream inputStream is created is any entry in the return result on line 7. We then sort all from the URL object on line 25. On line 26, the document the events based on time from the earliest to the latest on line builder factory dbf instance is created, which in turn creates STIDS 2013 Proceedings Page 153 the document builder db on line 27. The algorithm parses Needed is false. On lines 2 to 4, latitude lat, longitude lng, the input stream to create the XML document xmlDirDoc on and affected area radius rd of the emergency are retrieved. The line 28. The document element is then normalized on line GPS location gpsELoc of the emergency is created on line 5. 29. The algorithm returns the xmlDirDoc on line 31. The The flying distance [16] distUtoE from the user location to the ERApp can invoke any generic built-in application such as emergency location is calculated on line 6. The bearing angle Maps, Navigation, etc. with the xmlDirDoc updated direction bearingEL formed between the North and the line from the to provide assistance to the users. user location to emergency location is calculated one line 7. In this algorithm, we only address the immediate event The bearing angle bearingDest formed by the Northern line that requires a user’s attention and participation during the and the line from the user location to the destination location emergency time. Any calendar events occurring thereafter are is calculated on line 8. The angle angleUEtoT formed by the not addressed in this paper. line from the user location to the emergency location and the 3) Determine the Need for Alternative Routes: This section tangent line is calculated on line 9. The angle angleBE marked discusses the algorithm to determine if commuters need to get the beginning of the emergency effected area is calculated on an alternative route to their destination. If the travel direction line 10. On line 11, the angle angleEE marked the end of the of the mobile users to the destination crosses the emergency emergency effected area is calculated. We are now ready to area determined by the emergency location and its affected verify if the bearing angle of the destination is in the angle area radius, we need to get an alternative route to avoid range of the beginning and end of the emergency affected the emergency area. We can easily retrieve the directions of area on line 12. If the bearingDest is within the range, the users’ moving vehicles by using the Accelerometer sensor isAltRouteNeeded is set to true on line 13 and returned on and GPS sensor to determine the vector (speed and direction) line 15. The figure 4 provides the visual map these locations. of the moving vehicle. But this direction is only temporary and not necessarily the primary direction of where they are heading. Therefore, we need to retrieve the direction from their current position to their destination. We retrieve the location, speed, direction, and the affected area (radius from the emergency location) of the impending emergency from the CMAS message as discussed in section III-C2. Algorithm 2 : isAltRouteNeeded Algorithm (Input: HashMap Fig. 4. Alternative Route Decision mapNVP, GPSLocation gpsULoc, GPSLocation gpsDest) Require: mapN V P 6= null 4) Providing Emergency Advice: The ERApp uses the Require: gpsU Loc 6= null accelerometer sensor built in the hand-held devices to detect Require: gpsDest 6= null the user’s movement. By comparing the (lat, long) acceleration 1: isAltRouteN eeded f alse components, the ERApp can estimate if the user is moving or 2: lat mapN V P.gets(”LT ”) at rest. The ERApp then compares the distance between the 3: lng mapN V P.gets(”LN ”) user location and the emergency location to know if he is 4: rd mapN V P.gets(”RD”) approaching the emergency area. If the distance calculation 5: gpsELoc new GP SLocation(lat, lng) indicates that the user is moving toward the emergency area, 6: distU toE getF lyingDist(gpsU Loc, gpsELoc) the ERApp can provide some intelligent advice to the user 7: bearingEL calculateBearing(gpsU Loc, gpsELoc) based on the nature of the emergency. 8: bearingDest calculateBearing(gpsU Loc, gpsDest) The advice can also be given based on the user location with 9: angleU EtoT arcsin(rd/distU toE) respect to the impending emergency. For example, if the user 10: angleBE bearingEL angleU EtoT is inside the affected area of a tornado, relevant advice would 11: angleEE bearingEL + angleU EtoT be to drive to the nearest shelter immediately. ERApp can 12: if bearingDest angleBE AN D bearingDest  compare the distance from the user location to the emergency angleEE then location with the radius of the affected area to see if the user 13: isAltRouteN eeded true is inside the affected area. 14: end if As described in Figure 2, Emergency Sources sent the 15: return isAltRouteN eeded emergency advice to the NAF in XACML policies. The ERApp applies these policies to see if the user’s behavior Algorithm 2 discusses the need for the alternative routes. status satisfy the conditions on the policy. The ERApp displays The algorithm accepts three parameters: mapNVP, gpsULoc, the recommended advice to the user. and gpsDest. The first parameter is the hash map of the name- value pairs from the SMS message sent by the NAF. The IV. E XPERIMENTATION second parameter is the GPS user location. And the third In order to start the experimentation, we need to generate paramter is the GPS destination location. On line 1, isAltRoute- a tornado alert informing the all people in the local area STIDS 2013 Proceedings Page 154 that the tornado is coming. In our experiment, we set the the marker on the map. Telnet Server is the loopback server emergency location to be in Vienna, Virginia, the radius of that the emulator is running on. The ERSimMon will set the the effected area to be 3200 meters from the center of the new position as the user makes a movement. This process tornado, the expired time, category, certainty, status, urgency, simulates the actual driving of the user and at a certain time and severity of the tornado. We broadcast the CMAS message interval, the GPS on the user hand-held device will detect its to an emulator. Figure 5 shows the preparation of the tornado new position, which triggers the ERApp to update the position alert and the ERApp running on the emulator showing the on the map. user’s location. The ERSimMon simulates the driving of the selected user and spawns the emulator for that user, showing the user’s location and the ongoing tornado. The ERSimMon determines the bearing angle between the user’s location to the destination to be 85.64 degrees, the bearing angle between the user’s location to the first tangent line to the effected area to be 50.35 degrees and the bearing angle between the user’s location to the second tangent line to be 86.73 degrees. Clearly, the user is in the path of the tornado. The ERSimMon presents the alternative route to the user. Figure 7 shows the user driving Fig. 5. Prepare the Tornado Alert at the speed of 55.92 miles per hour into the effected area. The CMAS authority is ready to send the broadcast tornado alert to the emulator by clicking on the Send button. Figure 6 shows the tornado with the effected area in red and the user’s location. Fig. 7. Driving toward the Affected Area If we choose to take the alternative route, the user is taking a different route, Route 50 instead of Route 66 with the driving speed of 29.08 miles per hour. Figure 8 shows that the alternative route helps the user avoid the affected area of the ongoing tornado. Fig. 6. Tornado Alert on ERApp We built an Emergency Response Simulation Monitor (ER- SimMon) prototype to simulate an individual driving to work during an ongoing tornado. Figure 3 shows the map of the area, the ongoing tornado, and several marker points. These marker points represent users that are currently on the map. There are some configuration settings that are necessary for the simulation. In these configuration settings, Distance Increment is set to 50 meters for the duration of 200 milliseconds, which Fig. 8. Avoiding the Affected Area is indicated by the Sleeping Duration. Emulation Location and ADB Location are required to run the Android Phone emulation. Speed Display is set to Miles per Hour. As the V. R ELATED W ORKS user moves from his location to the destination, it can display This section briefly discusses other significant works aimed the speed at which the user is moving. at improving or providing the mobile users’ navigation assis- In addition, the ERSimMon allows to search, add, modify, tance. or delete markers. Two required fields are the user name and Although we haven’t found any publications that are in this the emulator name. The Address indicates the start point of the research area, there are other related works on navigation as- user on the map. The Destination Address indicates the ending sistance. However, their targets have been for different groups point of the user on the map after the simulation is complete. of audiences such as indoor users and blind audiences, one of These addresses are real address because we use the Google which is the Guiding Light system [22] that uses projections Maps API web service to retrieve the user’s location and place based augmented reality from the hand-held projectors to STIDS 2013 Proceedings Page 155 provide way-finding information. This system uses a combi- [5] ATIS-0700007, Implementation Guidelines and Best Practices for nation of hand-held sensors such as proximity, accelerometer, GSM/UMTS Cell Broadcast Service Specification; October 2009. [6] Commercial Mobile Alert Service Architecture and Requirements. compass, and vision to gather and places information on the http://www.npstc.org/documents/PMG-0035 Final Recommendations surrounding spaces. It then compiles all the reference walls, v0.6.pdf paths, and other stationary objects in its repository. The system [7] The Google Directions API https://developers.google.com/maps/ documentation/directions/ then presents the fast-forward clip of the paths and objects that [8] Tornado Data http://www.srh.noaa.gov/oun/?n=tornadodata-county they will encounter when moving from one place to the other [9] Technical realization of the Short Message Service (SMS) http://www. in the building. 3gpp.org/ftp/Specs/html-info/23040.htm [10] Base 64 http://en.wikipedia.org/wiki/Base64 The second is the General Framework for a Collabora- [11] Internet Calendaring and Scheduling Core Object Specification http:// tive Mobile Indoor Navigation Assistance System [23]. This tools.ietf.org/html/rfc5545 system is to provide a cost-effective method to effectively [12] Out-of-State and Long Commutes: 2011 http://www.census.gov/hhes/ commuting/files/2012/ACS-20.pdf transfer what the user is seeing to a remote expert who is [13] Commuting in the United States: 2009 http://www.census.gov/prod/ familiar with the area (e.g., providing museum tours, guiding 2011pubs/acs-15.pdf a lost pedestrian, and providing guided emergency response to [14] Poll: Traffic in the United States http://abcnews.go.com/Technology/ Traffic/story?id=485098&page=2#.UVDUaBkbqL8 an area struck by hurricane), such that interactive assistance [15] Commercial Mobile Alert System (CMAS) http://www.fema.gov/ can be provided to the local user using augmented reality commercial-mobile-alert-system techniques. [16] Calculate distance, bearing and more between Latitude/Longitude points http://www.movable-type.co.uk/scripts/latlong.html Treuillet et al. [24] presents a new approach for localizing a [17] XACML. https://www.oasis-open.org/committees/tc home.php?wg person by using a single-body-mounted camera and computer abbrev=xacml vision techniques to guide and navigate a blind person within [18] National Hurricane Center. http://www.nhc.noaa.gov/ [19] National Weather Center. http://nwc.ou.edu/ a navigation corridor less than 1 meter wide along the intended [20] Dynamic Mobile Application. http://www.its.dot.gov/dma/index.htm path. [21] Imagine... http://www.its.dot.gov/imagine.htm#two Clearly, published works up to now have addressed the [22] J. Chung, I. Kim, and C. Schmandt, Guiding light: navigation assistance system using projection based augmented reality, in Proceedings of indoor navigation assistance or to the specific groups of users. the IEEE International Conference on Consumer Electronics (ICCE11), To the best of our knowledge, there has been little or no IEEE, 2011, pp. 881882, doi: 10.1109/ICCE.2011.5722917. research done in guiding drivers in emergency conditions. [23] Rao, H. and Fu, W.-T. ”A General Framework for a Collaborative Mobile Indoor Navigation Assistance System.” In Proceedings of the ACM International Conference on Intelligent User Interfaces (IUI), Santa VI. C ONCLUSIONS Monica, CA. 2013. We have addressed the navigation problem during an emer- [24] S. Treuillet and E. Royer, ”Outdoor/Indoor Vision-Based Localiza- tion For Blind Pedestrian Navigation Assistance”, International Jour- gency by building a Navigation Assistance Framework for nal of Image and Graphics Vol. 10, No. 4 (2010) 481496. DOI: Emergencies to provide the navigation assistance to mobile 10.1142/S0219467810003937 users or commuters. The NAF is collecting emergency data [25] Shortest Path http://www.cs.princeton.edu/⇠rs/AlgsDS07/ 15ShortestPaths.pdf from Emergency Sources and disseminating it to all the regis- tered mobile users. When there is a new update to emergency data, the Emergency Source pushes the new information to the NAF, which in turn updates all of its register ERApps via SMS message. ERApp sends a new query to Google Maps for an alternative route to the destination in order to avoid the emergency path. We also build the ERSimMon to simulate a tornado event and the driving from one place to another to avoid the tornado and its affected area. It also spawns users’ emulators in the simulation process to show what is being displayed on the user’s ERApp. We suggest interfaces for the Emergency Sources to implement and to send the emergency data to the NAF. R EFERENCES [1] Paul Ngo and Duminda Wijesekera, Emergency Message In CMAS, In Proceedings of the International Conference on Critial Infrastructure Protection - Sixth IFIP WG, Mar 2012. [2] Paul Ngo and Duminda Wijesekera, Enhancing CMAS Usability, In Proceedings of the International Conference on Critial Infrastructure Protection - Fifth IFIP WG, Mar 2011. [3] Paul Ngo and Duminda Wijesekera, Using Ontological Information to Enhance Responder Availability in Emergency Response, In Proceedings of the Semantic Technology for Intelligence, Defense, and Security Conference - STIDS, 2010. [4] ATIS-0700006, CMAS via GSM/UMTS Cell Broadcast Service Specifica- tion; March 2010. STIDS 2013 Proceedings Page 156