In part one I described the first attempt of the Emergency Response Dashboard for our fire hall here in Langdon, Alberta.
The basic gist is that we get a message containing some basic information about the incident we need to respond to. This could look like something this:
Add: RGE RD 272/TWP RD 250 ROCK: alias HWY 9/TWP RD 250 Map: 250272 Det: GRA Evt: F2012029054
As you can see, this one-liner is pretty rudimentary but it contains everything we need to know such as:
- Add: means the address,
- alias: sometimes the address is locally known under a different name, there are some roads here in the county which are known under three different names,
- Map: the map number refers to an area which we can then look up in a 6” thick binder containing letter size pieces of detailed mapping. These detailed mapping shows us the location of the property we are responding to in relationship to the road and drive ways. Some properties have one drive way with multiple houses adjacent to it.
- Det: Indicates the type of incident, GRA in this case means Grass fire, there is a list with about a 100 different type of codes ranging in complexity from 29 : “Traffic Accidents – Prealert” to something more detailed like 29D04 being “Traffic Accidents – Pinned Patient”
- Evt: is the Event number, this number is unique per incident, however sometimes multiple Event numbers are generated for the same incident if the incident is reported by multiple people and the description of incident and address varies from each other (under stress people don’t know which road they are on, and have difficulty describe what the incident looks like)
The first solution, as described in part one, contained everything in one web role with a background thread monitoring the Office365 Exchange email account for incoming emails from the 911 dispatch center.
In the image to the right you can see the current structure of the application.
Updated Application Flow
The largest change since the first attempt is the introduction of a worker role and the Azure Service Bus.
The Worker Role
The worker role is responsible for four main things:
- Monitoring the Office365 Exchange account on which the 911 dispatch email comes in,
Once the email came in and it is determined that it is actually coming from dispatch, the worker role starts dissecting the one-line incident information.
- Once the Event data has been determined, the worker role proceeds with storing the data in the SQL Azure database,
- The worker role then constructs a XML messages which it posts on the service bus in a queue with a specific topic
- The worker role then continues to notify all members of our station by email and/or sms. Each member is managed in its own notification thread to minimize the time it takes to notify all members through both the email service and sms gateway
The email and/or sms each member receives is in addition to the radio we carry around when we are in town. The email and or sms is really helpful for the people who work out of town and may decide to come back if it turns out to be a multi-hour incident like structure fires.
The Web Roles
The web roles support the general web site which contains a members only section and also hosts the Dashboard for in the fire hall and a page which is linked to in the email or sms which allows each member to indicate if they are responding to the incident or not.
The web roles start a background process which monitors the queue / topic on the Azure Service Bus for incoming messages from the worker role.
Each Web Role creates a role specific subscription on the topic. This ensures that each role gets a copy of the message which it can then relay back to the client using SignalR. I am using the last character (a number) of the role’s ID to create the unique subscription.
SignalR really makes it easy to allow the Queue Monitor to push the XML to Json converted data to the client.
The dashboard now receives the base data which it displays in the top section of the page. As you can see in the image above we have Google Maps embedded in the dashboard.
The map should give us at a quick glance which direction we need to go, however when the data comes in from the 911 dispatch center we don’t have accurate enough information to build up the map.
Once SignalR has pushed the base data to the client, the jQuery method executed by the SignalR framework then proceeds gathering more information by making async jQuery calls to the web server for mapping data.
Mapping the Incident
The mapping department of Rocky View County has expressed interest in our efforts and has made all the addresses available to us. Each address comes with a Map Number and a roof-top accurate Lat and Long position which makes our mapping effort more interesting and our routing that much more accurate.
Because of this data, we can now use Google maps to create a map and calculate the “best” route from our fire station to the incident.
This works if the caller is able to relay the actual address. In the case of grass fires or a vehicle accident, we receive an approximate cross road address. In this version of dashboard we are not processing cross roads just yet. But… if you look close to the image above you do see a list of addresses on the left. These addresses are all located in the area represented by the Map Number I mentioned at the start of this post.
Because each address we received is also associated with a Map Number and the 911 dispatch center also relays a Map Number to us, we can then collect all addresses and display them on the page.
Using the Lat and Long associated with each address, I am now able to plot an area on the Google map to indicate the area of the incident. With this visual clue we have a pretty good indication of where we need to be.
The addresses in the list have click events associated with them. If you select one of those addresses in the list it will cause the map to redraw and focus on the selected address. If you want you can then recalculate your route.
GPS Tracking in the Trucks
The dashboard in the fire station is one thing and in the two weeks we had this running we had to work out some of the mapping issues, improved the look and presentation of the dashboard and so on but the system processed 18 incidents so far.
The next phase of this project is having iPads or other type of tables in the trucks to receive 911 dispatch updates while on route and use the map to keep track of where we are, especially handing in the pitch black nights here in the rural environment.
Using SignalR we are thinking of implementing the following:
- Getting 911 Dispatch updates delivered to the Truck while on route, sometimes we receive (drastic) address changes or the severity of the incident increases,
- Using the routed path, plot where you are on that route
- If we can use the device’s GPS info to plot where we are on the map, we can also use SignalR to report to the other responding trucks where we are. Sometimes one truck leaves a minute after the primary truck, depending on available resources. Not a critical feature but definitely cool to implement,
- Using SignalR we can push messages to other responding trucks, this of course requires a more technical application development as we are now entering in Incident Management territory, but who knows…
What is left
Although I am still tweaking the mapping and dashboard, the application is in full use. We have hits and misses with the mapping and email/sms notifications due to changing data structures received from 911 dispatch. With only 18 incidents as test case it is not bad but the point here is that non of the issues are caused by the components used; Windows Azure, Azure Service Bus Queues and SignalR. The technology works great and allows us to do things in a short amount of time which was almost impossible to solve before.
I have about 40 hours in development time on this project, most of it goes to playing the HTML5 and CSS to make it look good.
What is left, besides the Tracking in the Trucks is the single point of failure which what the worker role is at the moment. The problem is that I can have only one process monitoring the Office365 Exchange email account. So I have to develop some sort of communication channel for the multiple worker roles to be aware of each other for them to decide which role is the one monitoring the email account.