About 3 years ago a group of fire fighters at a fire station in Amsterdam was confronted with a new navigation assistant in the fire truck. From a conceptual point of view the idea of having navigation assistance in a fire truck might be nice, but there are practical implications when using a system designed for normal traffic in an emergency vehicle , remember fire trucks are allowed to defy all the rules in traffic! Without elaborating on why it is not working as it should, the more abstract point is that it gives answers to questions we never asked.
The answer you get from a navigation assistant is based on the question ‘What is my next step in getting to my destination?’ where fire fighters are more interested in ‘What is my final destination?’. Sitting down and discussing the subject the conclusion was that they were interested in an overview on a map with both the location of the fire station as well as the location of the incident marked.
The route itself is not that interesting as the knowledge of the fire fighters about the local area is at such a high level that they easily beat a navigation assistant.
To solve this problem, we were confronted with a few technical requirements:
- Real time, the system has to respond to an alarm at the fire station in a few seconds.
- It should not require any manual interaction.
- Low maintenance at station side.
- We should have access to the raw data
Items 1, 2 and 3 were pretty easy to solve, item 4 however turned out to be a more challenging one.
Although the full message was sent ‘over the air’ via a paging protocol, it wasn’t really a structured data format. It was just a compression of various seemingly random chosen fields into a maximum width of 140 characters.
After some trial and error we were able to extract the various fields with about a 98% accuracy. Now that we had the data and the various pieces of information we needed to distribute this data. In our team we had some discussions about what format to use.
During that time we got introduced to RDF, where the flexibility of the data model was what was intriguing us most. This would perfectly fit with requirement 3. We could still enrich the data dynamically without breaking already installed systems at the fire stations.
How does it work now
After tying all loose ends together the structure of the solution is very elegant and simple.
- We scan the via air broad casted message for station ID’s we are interested in. Whenever a station ID we want is detected we generate RDF data.
- The vocabularies used are partly standard, partly domain specific.
The standard ones include:- Meta data, all the information about the publishing of the data,who/when/where/what: OWMS / DCMI
- Events, the alarm is an event, and we record everything relative to the event: SEM
- Location, the crew is dispatched to a location: GEO
- Address, the incident takes place at a certain address: vCard
The domain specific vocabulary is a subclass of event, describing:
- Units dispatched to the incident
- Fire station involved
- Deployment plans used.
- This information is stored as RDF data on a public URI. This URI is then dispatched to the relevant fire stations.
- The software at the stations uses Semantic Web techniques to retrieve the data from the URI, and show the relevant information on the map.
Advantages
Due to the flexible structure of the data model we have been able to enhance and update the data model without touching the client software. If the clients needed additional functionality it needed a software update of course, but the software update was not necessary to accommodate a data model update.
From a Semantic Web point of view we now start very early in the incident describing the data, we actually do know what we are talking about. Because we gain knowledge about the actual incident at a very early stage we are able to assist and connect multiple sources of information in a later stage.
From a non technical point of view we have some results we didn’t expect. Because the truck driver now has a better idea of where he needs to go, he is more relaxed and better concentrated behind the wheel, resulting in more secure and save driving.
As there is a map at the station, the fire fighters look at the map more often, and get a better idea of their work area.
Outside in development
Due to the close connection with the people actually using the system, we were able to implement modifications and wishes really fast. We didn’t go through highly detailed project plans and endless meetings, but decided to start where we thought it was easiest and just took it from there, never loosing sight of the technical strategical direction we wanted to go and the targets to achieve.
Future plans
Our current focus now is to extend the screens with information from the deployment plans. More on that in the near future….