Create a common operating picture for search and rescue at the edge with AWS

During a disaster response operation, organizations like international nonprofits, state and local governments, local fire departments, and more all need a well-executed common operating picture (COP) that allows incident response commanders to monitor the health and safety of their responders in the objective area. A well-executed COP also allows a commander to coordinate and deconflict among the various organizations supporting a response effort. But running a COP in the immediate aftermath of a disaster involves overcoming multiple challenges, including a lack of reliable power and stable connectivity to the internet at disaster sites. These challenges necessitate a solution that supports collecting, processing, storing, and visualizing data at the edge, and then synchronizing this data with the cloud once connectivity is restored.

Amazon Web Services (AWS) offers a suite of services that provide edge infrastructure and software to bring the computing power of the cloud to locations with limited or no power or network connectivity — and to make sure these services can address the real-life challenges faced by disaster response teams, the AWS Global Social Impact Solutions (GSI) team puts them to the test.

In a recent field testing exercise (FTX), the GSI team developed a prototype cloud architecture and tested it in a search and rescue (SAR) scenario simulating a missing responder crisis. Complex response efforts involving multiple volunteers and organizations in dangerous environments can result in responders becoming victims themselves and requiring rescue – and organizations need to know how to find their people fast, with precision, no matter how remote their location.

This blog post walks through the SAR simulation and result, and provides an overview of the AWS services and technical architecture components the GSI team used to provide a hybrid edge/cloud COP solution that helped locate the missing team member in the simulated scenario.

Simulated scenario overview: Search and rescue at the edge

To simulate a missing team member scenario, we defined a “disaster site” in a remote area of the exercise property and an emergency operations center (EOC) at another location outside the disaster zone that had stable power. Taking into account line-of-sight propagation over challenging terrain, the team established an ad-hoc local area and wireless networks to provide communication between operational points.

Figure 1. Overview of the FTX site, with the EOC location, HQ, in the valley (left) and disaster site beyond the ridge (right).

Our search and rescue simulation scenario was triggered when a responder at the disaster site missed his evening radio check-in with the EOC.

Key AWS services and architecture for search and rescue at the edge

To create a common operating picture at the edge to locate our simulated missing person, the GSI team used the following AWS services and architecture design:

Figure 2. The high-level architecture showing how AWS IoT Greengrass, AWS Snow Family, Amazon Elastic Compute Cloud (Amazon EC2), and sensor nodes interact to provide data for a common operating picture at the edge.

Step 1: Determine missing person’s last known position with IoT at the edge

The first step in the simulation was to determine the responder’s last known position so the team could narrow the search area. To do this, they leveraged AWS IoT Greengrass, an open-source edge runtime and cloud service that helps swiftly and efficiently build, deploy, and manage internet of things (IoT) device software.

The team pulled location data from an AWS IoT Greengrass-managed sensor network that included a software-defined radio (SDR) sensor capable of monitoring for Automatic Packet Reporting System (APRS) beacons. APRS is an amateur radio system used for real-time communication of packet information, which can include GPS locations for registered devices. The sensor—built using a Raspberry Pi microcomputer, SDR dongle, and a high-gain antenna—captured APRS packets and forwarded them over the ad-hoc local area network to a local AWS IoT Greengrass core running on an AWS Snowcone device at the EOC. Snowcone is one of the edge devices in the AWS Snow Family, which provide rugged offline compute and storage capacity at the edge. Upon receipt of these packets, AWS IoT Greengrass components running on the Snowcone decoded the packet data, converted it to a standardized format, and published it for use in the COP application.

We deployed an open-source Team Awareness Kit (TAK) server to an Amazon Elastic Compute Cloud (Amazon EC2) instance on the AWS Snowball Edge Compute Optimized device at the EOC to serve as the local aggregation point and data provider for the COP application. The TAK server is the back-end component of the Android Team Awareness Kit (ATAK) and Windows OS Team Awareness Kit (WinTAK) applications, which are map-based mobile applications for visualizing and sharing data in a geospatial context. When data such as the APRS location beacons are published to the TAK server, all connected client devices receive the update immediately. We also deployed the TAK server in the cloud using Amazon Elastic Container Service (Amazon ECS), which makes it simple to deploy containerized applications in a high availability configuration and allows us to keep a standby instance of the TAK Server ready in the cloud.

We configured federation with the local TAK server on the AWS Snowball Edge, which allowed data collected and published to the COP in the field to automatically replicate to the cloud when internet backhaul was available. Deploying WinTAK in the cloud using Amazon AppStream 2.0 enabled other stakeholders to remotely monitor and provide information directly to responders using the Amazon ECS-based TAK server. Amazon AppStream 2.0 is an AWS service that provides users a way to access traditional thick-client applications through a web browser without requiring a full virtual desktop.

With the APRS data displayed via TAK at the EOC, the team determined the last known position of the responder.

Figure 3. WinTAK application displaying aggregated data and custom annotations.

Step 2: Using position data in real-time to locate missing person

With the missing responder’s last known position determined, the team prepared two off-road capable search vehicles and an unmanned aircraft system (UAS) equipped with a thermal camera. Another Raspberry Pi sensor equipped with a SDR dongle and high gain antenna monitored Automatic Dependent Surveillance-Broadcast (ADS-B) data to locate aircraft in the area. Incident command equipped each vehicle and team member of the search party with a LoRaWAN GPS sensor to track their location in real time. These inexpensive sensors run on AA or AAA batteries and are capable of transmitting their location over 10 miles using the long-range, low-power LoRa radio protocol.

To collect the position data transmitted by these sensors, we deployed a LoRaWAN gateway as part of the IoT sensor network. As with the APRS sensor, it transmitted LoRa data back to the Snowball Edge at the EOC where it was programmatically decoded, processed, and published to the TAK server. The ATAK and WinTAK clients can also consume live video streams, such as the UAS camera feed, and display it in near-real time alongside the map and sensor data. This enabled the command team at the EOC to view the location of the search team as they departed and monitor their progress throughout the search.

Figure 4. SAR team conducting search with an ATAK tablet displaying APRS, LoRaWAN, and drone data.

With this integrated COP solution, the SAR team located and recovered the missing responder within 20 minutes after the missed check in, and demonstrated the value of being able to rapidly aggregate data at the edge during a disaster scenario.

Learn more about AWS for disaster response at the edge

To get started, learn more about the AWS Disaster Response Program, AWS IoT Greengrass, and the AWS Snow Family of edge devices. Do you want to learn more about how AWS can help you with getting started with your own COP or any other of your disaster response solutions? Contact us directly.

AWS offers multiple programs for nonprofits to get started on the cloud, including the AWS Nonprofit Credit Program, which helps organizations offset the costs of implementing cloud-based solutions. Apply for the AWS Nonprofit Credit Program to start your journey with AWS.

About the AWS Global Social Impact Solutions Team

The AWS Global Social Impact (GSI) Solutions Team focuses efforts across the pillars of disaster response, rights and equity, and global health. The GSI Solutions team is an incubator for technical solutions that address customer needs across these pillars. We build rapid prototypes and end-to-end proofs-of-concept using a mix of AWS services, commodity hardware, and homegrown technology.

AWS Public Sector Blog