A Proposal for Developing a Real-time Geospatial Data Collection System for SAR Operations
GEOG 583 – Term Project
Loren Pfau
19 June 2010
Abstract:
A significant challenge in managing wilderness Search and Rescue (SAR) operations is the lack of real-time geospatial data being available to mission leaders and planners responsible for analysis and decision-making at the base of operations. Effective mission management requires that field team, clue, and subject position informationbe constantly collected and analyzed in a GIS or electronic mapping package to help maintain situational awareness and to document field activities for post-event analysis and reporting. Until recently there have been few mobile tracking/reporting devices available to wilderness SAR teams due to cost, size/weight, technology limitations, or some combination of these constraints.
The objective of this project is to researchtechnologies and systems that have been applied to this problem area. Based upon the findings of the research a proposal will be prepared that describes the work effort to gather requirements, develop high-level systems designs, prototype likely candidate systems, outline testing scenarios and list the benefits and limitations of the candidate systems. This proposal may be used by wilderness SAR teams to guide their investigations of designs solutions that can meet their operational needs for real-time geospatial data.
- Introduction
One of the biggest challenges in managing wilderness Search and Rescue (SAR) operations is the lack of real-time geospatial data being available to mission leaders and planners responsible for analysis and decision-making at the base of operations. This document proposes an approach that may be employed to design, evaluate and implement a real-time tracking system that will capture field team positions, display progress and archive the data for additional data analysis that may be conducted at a later time.
- Problem Statement
2.1.Need for Real-time Geospatial Data for SAR Mission Management
Being able to ascertain the position, and document the tracks, of field teams conducting search operations is a primary concern of mission managers. Knowing where a team has been aids in planning future search strategies such as new areas to cover, or areas to re-search in order to increase the probability of detection of the missing party.
Many SAR teams use periodic radio calls to teams, requesting reports on position. But this is inadequate for a number of reasons: teams may not be called on a regular basis; position information may be incorrect because of copying errors on either side of the transmission; and managing large numbers of teams with this manual method becomes unwieldy.
The development of an automated system that collects real-time positional information from field teams and captures that information in a GIS or mapping package increases data quality and frequency, which in turn enhances mission management decision-making.
2.2.Constraints
The three main constraints on any proposed design are weight, ease of use, and cost. Weight is a major consideration for the components of the system that will be carried by field teams. Field teams are already burdened with significant amounts of personal and team gear and any additional weight will impede the team’s speed of entry into the field. So any gear that adds to that burden will not be well received and my well be “forgotten” at the base of operations.
Ease of use impacts both fielded and command post system components. Field teams want a “start it and forget about it” tool that doesn’t require constant monitoring or adjustments, activities that will slow them from completing their assignments. The operators and planners at the command post will demand interfaces that are straight-forward and simple to use, and which are preconfigured to make common tasks easy.
Cost will be a major consideration. Most SAR teams are either self-funded or receive very modest funding from local and state governments. A system that meets the functional needs of a team may simply be unaffordable. System designs that make use of existing team equipment and low-cost or no-cost (i.e., open source software) components are likely to be looked upon very favorably.
- Research on Existing SAR Geospatial Systems
Prior to undertaking detailed design efforts a survey will be conducted of the current body of knowledge pertaining to wilderness SAR tracking systems. The problem of maintaining situational awareness of field teams is not unique to any single team or geography and undoubtedly there are existing design solutions that may be employed as-is or only slightly modified to meet a particular team’s needs. For an example of the type of work that would be surveyed please see Neys (2005) and Wong (2009).
The results of the survey will be used with the results of a Needs Assessment as an input to the creation of the systems architecture and details of the system components.
- Design Approach
The design approach proposed for this effort envisions starting with a Needs Assessment, which will be comprised of persona and scenario development. These will be tied to key roles that would be employed on a large, multi-day search operation. An analysis of the scenarios and personas, and interviews with individuals that have been active in wilderness search activities will be conducted to develop a set of system requirements. Matching these requirements with the known technology components will allow for the identification of potential hardware and software components that could be integrated into an overall system.
After candidate components have been identified several prototype designs will be generated, most as systems designs and displays on paper, but operational prototypes will be considered if the budget so allows. Figure 1 depicts the overall planning, design and selection process.
Figure 1 – SAR Tracking System Design and Selection Process
4.1.Needs Assessment
4.1.1.Personas
Personas will be developed that convey the attributes of key users of the system. Three preliminary personas:
John is a mission leader (incident commander) overseeing the search operation for a missing hiker. John’s main concerns are in getting field teams into the high probability search areas; assessing their positions and progress, ensuring the safety of the teams and planning possible means of extrication should the subject be located. His secondary concern is planning for the next operational period and briefing his successor should the mission go into the next day. John is not going to be operating a computer; he wants to be able to glance at a screen to quickly assess the locations of his teams and clues and he relies upon his operators and planners for detailed information extraction from the tracking system.
Mike is a planner co-located at the incident command post with John. Mike is operating the data communications gear and computers that house the GIS data bases and displays the positions of field teams over geographic layers of interest. Mike needs to be able to quickly generate visuals or reports to support John’s decision-making by being able to answer questions such as “Show me the tracks of the field teams that have gone through Sector A in the past 3 days” or “Plot the positions of all clues and label them with a date and time stamp.” Mike is computer-literate but not necessarily a GIS expert so the system needs to be relatively easy to operate.
Jim is a field team leader. Jim’s primary concerns are to get his team to his assigned area quickly and safely and to conduct his search. He does not want himself or his team to be burdened by heavy, bulky or difficult to operate tracking gear. Anything he has to deal with that interferes with his assignment is a distraction, hence the tracking gear carried by the team needs to be essentially self-operating.
4.1.2. Scenario
On a large, multi-day search mission the incident commander and planners require ready access to detailed maps, imagery and other geospatial assets in order to develop and maintain situational awareness of field teams, clues and assets available to assist in the search. As the search progresses information on areas searched, areas remaining to be searched and items of interest are continually documented and analyzed and used as input to the decisions regarding the activities of the next operational period. Real-time information on the positions of all field teams are required to document coverage of search assignments and to understand teams may be able to assist the team that locates the subject should they need aid in extrication. Geospatial information needs to be updated continuously and via an automated means for maintaining situational awareness of teams and documenting coverage patterns for evaluations of probability of detection and post-incident evaluation.
4.1.3. Interviews
In addition to the personas and scenario development interviews of actual SAR team members will be conducted during the Needs Assessment. Interviews may be in-person or through survey instruments such as questionnaires. The objective is to collect the thoughts of experienced SAR personnel on their view of key attributes of a real-time tracking system. Through this process we would hope to learn about the importance of things such as the importance of system interoperability with other SAR teams’ solutions.
4.1.4. Requirements
The output of the Needs Assessment phase will be a prioritized set of requirements that any proposed system design must address. The requirements will be an input to the system concept development phase and will also form the basis of the design evaluation criteria.
4.2.System Concept Development
4.2.1. High-level Architecture
Figure 2 illustrates a high-level view of the main system components and relationships that will be required regardless of the particular technologies employed. Beginning on the left side of the drawing, the architecture envisions multiple field teams carrying equipment that is some combination of a GPS unit and RF transmitter. These units are continuously transmitting the field team locations via radio frequencies and the data transmissions are received by an access point. The access point is in turn connected to a PC which houses a GIS or electronic mapping software package. The positional data is captured and archived by the software and made available for display and analysis purposes.
Figure 2 – High-level System Architecture
4.2.2. Hardware Candidates
Hardware components can be broadly divided into field components, access point and PC at incident command. The PC hardware selection may be determined or influenced by the software package selected as there may be particular requirements in the form of processor speed, memory and operating system.
The field units will be a combination of a GPS unit, RF transmitter and data encoding components. They may be fully integrated or individual items that are combined into a single package. Possible candidates for consideration:
- Amateur (Ham) radio transmitters with Automatic Position Reporting System (APRS) capabilities (Noskowicz, 2010)
- Commercial handheld radio transmitters combined with GPS gear
- Cell phones
- FRS and GMRS radios combined with GPS gear
- Satellite telephone combined with GPS gear
- Cellular fleet tracking systems
- Satellite fleet tracking systems
- A hybrid of two or more technologies
4.2.3. Software Candidates
The main software component of the system will be either a GIS , electronic mapping program or web mapping system. A secondary software component may be middleware that provides translations of the incoming data streams from the field units into a format that can be used by the GIS or mapping package if said package is lacking the ability to utilize the data feeds as-is.
The decision as to whether to employ a mapping program or a GIS application will be driven by several considerations including requirements on ease of use (both in learning and operating the software), sophistication of spatial analysis activities, and ability to display multiple layers. Possible candidates may include:
GIS Packages
- Commercial Offerings
- ESRI’s ArcGIS
- Pitney Bowes MapInfo
- Open Source
- uDig
- Quantum GIS
- gvSIG
Mapping Packages
- Ozi Explorer
- National Geographic Topo
- Maptech Terrain Navigator
- Delorme Topo USA
Web Mapping Mashups
- Google-based
- Bing-based
4.2.4. Integration
Integration of the hardware and software components of the system may be simple or complex, depending upon what components are selected in each category. For instance, if APRS over Amateur radio frequencies is selected there exist several open sources and shareware software packages that exist to provide an interface from the RF data feed to the software package (see Wong, 2009). Commercial systems that are prepackaged may be similarly simple.
On the other hand if a new interface needs to be developed, say for a hybrid system, a significant development effort may be required. As such the difficulty of integrating components needs to be evaluated during the system evaluation phase.
4.3.Prototyping
Prototypes will primarily play a role in assessing alternatives for the field units and the user interface for the GIS or mapping package. Mock-ups of the field units will be presented to SAR team members to gather impressions on size, weight, carrying orientation (on or in a pack) and complexity of activating a unit. Similarly paper or electronic simulations of the user screens for the software package will be developed and evaluated. An example of a potential UI is depicted in Figure 3.
Figure 3 – Prototype User Interface
4.4.Testing Scenarios
Testing scenarios will be developed that mimic conditions and situations likely to be encountered on an actual search mission. These scenarios will be used to evaluate system performance and capabilities during the System Assessment and Selection phase of the project.
4.5.System Assessment and Selection
A system design review board will be established to evaluate the proposed designs. They will develop an evaluation matrix based upon the requirements that were developed in the Needs Assessment phase. All designs will be evaluated against the evaluation matrix with total scores used to rank each proposed approach. Those that fail to meet key requirements will be discarded and those that remain will undergo additional scrutiny. An example evaluation matrix of the type envisioned is shown in Table 1.
Table 1 – Sample Design Evaluation Matrix
Ideally, if sufficient budget is available a working prototype of several of the candidate designs should be constructed for the purposes of testing. A less-desirable alternative would be to gain access to existing systems either commercially available or which have been developed by other teams to allow for the evaluation of capabilities.
The final decision will be based upon rank-ordered scoring of the designs against the evaluation matrix, test results and the final recommendations of the review board.
- Recommended Implementation Approach
The selection of a system design is the first step towards implementation. The implementation process needs to be closely managed, especially if the design selection was based primarily on the review and analysis of paper proposals rather than having had the opportunity to evaluate working prototypes.
A project manager should be assigned to manage the implementation process. Key deliverable articles and dates should be jointly established by the project manager and the vendor(s) and incorporated into a project schedule. Rigorous field testing of the system must be planned and conducted prior to the acceptance of the system and contract close-out.
Within the SAR organization itself a training program must be established to enable its members to operate the components of the system which fall within their roles.
- References
Fleet Management Solutions. “Satellite vs. Cellular Fleet Data Communications.” No Date. Retrieved on 16 May 2010 from:
Neys, David. “Intro to Dmapper in Search and Rescue.” 2005. Retrieved on 18 May 2010 from:
Noskowicz, Steve. “APRS Beginner Guide 2010.” 3 Feb. 2010. K9DCIRetrieved on 11 May 2010 from:
Stoffel, Robert. “The Handbook for Managing Land Search Operations.” 2001. Cashmere, WA. Emergency Response International
Wong, Chris. “APRS for Search and Rescue Operation.” 22 Jan. 2009. Retrieved on 18 May 2010 from: