*** Field Experience Using the Search Manager V3 Software ***

From:	Martin Colwell
	sarinfo@istar.ca
Date:	28 July 1999
To:	csar@onelist.com

Dear Friends,
We have been using the Search Manager V3 program, as it is being developed, on most of the major SAR operations here in British Columbia, so perhaps I can offer some insights into the procedures we use and the associated problems and benefits.

My first comment is that I think it is necessary for SAR teams to demand commercial-quality software if we wish to have developed the type of high quality software product that our SAR teams really need. Most importantly I believe this is necessary if we are to ensure that the developed program exists beyond release #1. This is one of the primary reasons that Search Manager V3 is being written as a fully-developed commercial product.
Many good programs that are developed in shareware (e.g. CASIE3) never get the major upgrades they deserve simply because the kind volunteers that produce them do not have the time, or financial incentives, to keep improving the program and developing new versions.

This means that SAR teams will eventually have to 'bite the bullet' and recognize that they will have to shell out relatively big bucks to get commercial-quality SAR software. I have spent far too much time in software development houses getting polite interviews - and then being shown the door - to know that adequate funding is absolutely essential to ensure professional software development. So eventually it is the SAR teams themselves that will decide if they wish to support and maintain commercial quality SAR software, including any third-party licenses that may have to be built into the selling price.

Now on to the practicalities of using the software during actual SAR operations...

British Columbia's SAR Resource Kit contains, among many other things, 3 Toshiba laptop computers and associated printers, network hubs and each new beta release of the Search Manager V3 software. This kit is used on most major mutual-aid operations here in BC (and occasionally in Washington State).

A typical incident unfolds as follows: The kit rolls into town typically on the second to 'n'th operational period - by the time the local responders are geting very nervous about the progress, or lack thereof, of their incident. The laptops are setup on folding tables and networked using a small 5-port hub, using Windows Network Neigborhood software. Lots of extra RJ45 network cables and female-female cable connectors are included with the kit. If their is any suspected trouble with any of the network the cables we do not attempt to troubleshoot but simply replaced the cable with one of the spares.

Usually the network is setup on folding tables within a command post building, but sometimes it is setup inside a mobile command post, with the check-in laptops setup on folding tables under an awning, just outside the vehicle. We have found that it is usually practical to use two of the networked computers for the initial check-in of the SAR personnel, leaving the remaining laptop free for search planning (i.e. assignment development). As a rule of thumb, during worst-case scenarios' i.e. no personnel are pre-listed in the Personnel database, we have found that it takes one check-in person (and laptop) for each 30-50 people that have to be checked-in within a reasonable period of time, say 30 minutes. This time-frame assumes that the check-in personnel (typically Emergency Social Services volunteers) have no previous experience with the software and, more importantly, only 'hunt and peck' typing skills.

The Check-In software has been 'tweeked' a number of times to minimize the number of keystrokes and mouse movements required and has been designed to be very easily understood by someone with no previous experience at all of the main program. On a very large operation, say with 100 to 200 people present, all three laptops (or more) have been initally secconded to the check-in procedure.

To further speed up the process on large operations we usually ask people to sign-in on the normal paper forms and then go straight to their briefings, this virtually eliminates frustrating lineups just to check-in. During this time we transfer these paper lists to the laptops and then print out nametags for each checked-in person. These business-card size nametags show the name, organization, role during the incident and the date/time the nametag was created. These cards are inserted in plastic sleeves and placed on a table, in alphabetical order, for their owners to pick up. I have found that on major, multi-team operations, where you often do not know the names of most of the participants, these nametags are invaluable.


The inherent built-in power redundancy mode of laptops (their internal batteries) removes a lot of the potential headaches involved in using external monitors, the risk of generator-induced power spikes, the need for UPS systems, additional cabling and so on. Unfortunately the network hub is typically not battery backed-up and even a brief interuption of 'shore power' can disconnect the network. This failure mode is not always immediately obvious and so is probably a good case for installing a small UPS anyway.

The risk of potential data loss during an operation is always extremely important and so it is advisable to regularly print out existing records to hard copy. The Search Manager program is designed to be inherently conservative and typically only works on copies of the data stored in its databases, not on the original data itself. As yet I have not experienced any data losses, even in beta development mode when we are debugging the system. The software user interface makes it necessary for very specific actions to be taken to delete records, usually removed from the current window interface, and does not allow more than one record to be deleted at a time. Backups are performed after each operational period by copying the entire program directory structure to a zip disk and, if networked, to another networked computer. This means that even if the laptop itself becomes completely damaged the entire program can be very quickly restored to another computer - with all the current mission data intact.

As far as user acceptance and the needs for an IT team to be involved: The problem seems to be not one of user acceptance but how quickly cn we get the program out to the users! An IT team may be a good idea to help handle the occasional hassles of networking, typing skills, familiarity with the software interface and, most importantly, its underlying principles. One potential problem that may arise is the concern, raised by some of the more experienced SAR Managers, is that the program hides most of the mathematics and processes necessary for shifting POA, cumulating POD's, inserting new search areas, prioritizing active assignments, allocating Trail-based POA's etc., and performs most of these functions automatically and, usually, without user intervention. This could lead to the situation where an inexperienced user - perhaps not even a Search Manager - could implicitly rely on the displayed data, without understanding the underlying principles - and their limitations. Up until now this scenario has not been possible but it could occur with the release of the software. Perhaps as much as any other reason, this could be a good argument for having dedicated IT people operating the system.

Well these are just a few thoughts based on our current experiences using Search Manager V3 over the past three years of development. I would be most interested in your comments and opinions, so that we can guide the use of Computers in SAR in the direction that we  are all striving to achieve - better and smarter SAR operations.

Best wishes,

Martin Colwell
SAR Technology.