Problem Defined

Over the last couple of weeks I have spoke with a number of search and rescue volunteers from all across the state of Massachusetts. I have chosen to focus the project on the challenge of communication in the search environment. 

Problem Statement:

Speed and completeness are paramount during search and rescue. The faster you are able to find the person the better chance you have of survival and the smaller the cost of the search is. During search it is critical that command knows where everyone is and are able to communicate directives and locations quickly and accurately. Further, the searcher need to be able to communicate current location and finds to command as quickly and effectively so that command can make the best decisions about allocation of recourses.

Today, communication is a slow process fraught with inconsistency and error. Coincidentally searchers spend a significant amount of time standing around and not looking for the subject. Also, it is not always clear if an area has been effectively searched until well after the fact. This leads to the potential of missed clue and finding people when it is too late.

We can use local networks, and advanced aerial technology, and other technology to help improve the struggles around communication, ultimately improving the effectiveness of searchers.

Potential Directions:

Solution 1:

Using a tethered drone system to get a HF radio repeater up in the air. This would allow for the creation of a good coms networks and would make the radios currently being used more effective. The design requirements would be:

• something that can be easily loaded and carried in the back of a car.

• be able to be in the air for extended periods of time without needing to land (continuous or hot swappable power source).

• be stable in poor weather conditions.

• be completely autonomous. Just press a single button and it goes and stays up til you tell it to come down.

• Able to work with both police and civilian equipment with a certain degree of security and encryption.

This solution address the need for better verbal communication and the connection issues with radio. It does not address the inherent problems of using radio to communicate information and communication bottlenecks.

This solution has the potential to have other benefits as well, like being able to do a quick aerial scan of the surroundings.

Solution 2:

System for quickly getting people checked in and coordinate/tasks assigned. Would need to be super simple but cover all of the legal bases. Would need to be able to process multiple people simultaneously to eliminate bottlenecks. This system would also be used as the interface for “debriefing” people and downloading there track data. This would allow for command to receive critical information faster and for searchers to spend less time waiting in lines and just standing around.

This solution does not address communication problems while in the field.

Solution 3:

A device that would allow for real time tracking of the searchers, that would allow them to communicate the location of finds with the press of a button, eliminating the need to communicate UTM and Lat/Long coordinates over radio. This device would automatically sync the desired search area as well as the desired coordinate system of command so that things don't become long in translation.

This tool would be cheap to produce, and utilize a local area network.

• Local area network to ping and triangulate cell phones currently in the area

Central Mass SAR Training Day

On February 19th, I attended a search and rescue training event with Central Mass Search and Rescue to get some first hand experience with what it is like to be a searcher. Coincidentally it happened to be the coldest day of the year thus far, bringing the mercury below -10ºF before accounting for wind chill. Needless to say the weather brought with it unique challenges that the team faced during the numerous exercises. 

Some of the key insights gathered from the training are:

• Stokes basket is, heavy, cumbersome, slow, missing ergonomic features, easy to hurt patient when sliding them in, not insulated, if they could be set on wheels when not on rough terrain it would be great.

• Patient was cold even after being placed in hypo wrap 

• Coms was not immediate. Distinct time delay between responses. Radios only work one way at a time. When two teams try to check in at the same time it doesn’t work.

• Keeping search lines straight, while seemingly a simple task was often difficult in practice. 

• Lots of standing around waiting to be told what to do. 

• Communicating specific information, such as location, patient condition, was very slow and not very accurate. 

• One the patient is in the stokes being carried out there is no way to keep track of vitals.

It Begins

This semester I am embarking on an Olin Independent Student (OSS) centered around designing for search and rescue (SAR) volunteers. This is a self designed course where I will be working under the guidance to Scott Harris a long time search and rescue volunteer and head of product definition at Onshape, inc. The goal of the project is to identify key needs of a SAR team and iteratively design a solution to one fill one of those needs.

I will be keeping this blog as an ongoing documentation of my process and work through the semester. 

The semester is broken into three phases: research, prototyping and testing, and then final presentation.

The first phase will be focused on researching SAR and meeting with experts to learn as much as possible about their needs. The last two weeks of this phase will be narrowing the focus of the project and clearly defining the problem.The deliverable for the research phase will be a document that thoroughly outline the needs of SAR, identifies areas of potential for future design and clearly a defines a problem.

The second phase with consist of a number of prototyping/testing loops focused on getting the most learning for the littlest amount of time and effort. Refining the design and ideas based off of the feedback from users at each step. This phase will be the bulk of the semester and there will be bi-weekly reports on the progress made and things learned.

The final phase will be solidifying the work of the semester and generating document (poster, paper or website) to present my findings and validated design concepts. This final document will be done such that anyone wishing to continue the project will have enough information about the problem scope, design decisions, rationale and assumptions, technical feasibility and prototype design.

Throughout the project there will be weekly review meetings between Scott and myself to talk about the current state of the project.