SAR-Scenarios

This project aims to document various scenarios where a small unmanned aerial vehicles (UAV) might prove to be a useful tool to emergency services, especially in Search And Rescue situations.

The reason for the project is to help technologists (primarily CanberraUAV) communicate with people in the Emergency Service Community, to better understand there needs and discover where the real value lies.

The first chapter introduces the project, and the last chapter describes hardware (UAV and Payload) capabilities and constraints. Each of the chapters in between cover a specific use-case, or type of scenario that has been considered. These chapters should eventually contain a number of realistic scenarios, taken from real world rescues and training exercises. For each scenario, various combinations of airframe and payload will be evaluated from a flight/mission planning perspective, and promising configurations will be evaluiated further with computer simulation and (eventually) field exercises.

Introduction

About this document / project

The theories behind this project are:

• documented user-stories might be a good way for us to engage SAR community
• iterating over documented user-stories might be a development path to joint exercises with the SAR community (stories evolve into workshops -> computer simulations -> desktop exercises -> experimental field exercises, etcetera)
• engagement with the SAR community over user-stories might drive “real world” qualities into our next OBC entry.

We know we have been successful if:

• the SAR community are motivated to contribute content to the user-stories
• the SAR scenarios prove useful in helping us prioritise technology development efforts

Development Road-map

This project has a short term plan and a long term plan.

Short term plan

The objectives of the short term plan are:

• discover new requirements / scenarios
• obtain more elaborate information about known scenarios
• validate requirements by finding people in the SAR community that can verify the requirements are real
• develop a vehicle to focus / nurture relationship with the SAR community

Activities of the short term plan are:

• list and describe various relevant hypothetical stories
• seek SAR community review/feedback
• update scenarios, summarise feedback
• keep iterating as long as we keep getting valuable feedback

When we have a well-validated (by SAR community) short list of scenarios that are compatible with CanberraUAV technical development goals (OBC 2014), change focus.

Outstanding questions related to the short term plan:

• apart from the user-story itself, what meta data do we need to capture?
• how to evaluate the usefulness of each scenario? voting system / straw poll?
• how to relate user-stories to technology features? how to get these requirements driving development?

Long term plan

The short term plan describes the first of four phases, which might be though of as requirements discovery. The subsequent phases are about delivering practical solutions to some of the key requirements.

The second phase will be requirements elaboration. In this phase we will identify some stories that are well matched to CanberraUAV development goals, and seek more detailed information about them. For example identify variations/alternatives, operational/functional requirements, conduct risk and hazard analysis, etcetera.

During the second phase, we may participate in table top exercises and workshops. Ongoing technology development will continue during all phases of this project (although it will increasingly be driven by the requirements documented here), however during the second phase we expect to be able to demonstrate progress against some of the requirements at this stage.

The third phase will be experimental joint exercises, which is where we will demonstrate that free, open source UAV technology is capable of being useful tool to emergency services.

The fourth phase is transitional capability, which will be whatever it needs to be to get these useful tools into active service.

Requirements Modelling

The goal of our requirement analysis is to evaluate combinations of hardware that are potentially effective in different mission profiles, and use that information to guide our development program.

Broadly speaking, we have modeled the functional requirements of the Unmanned Aerial System (UAS) as “use cases”. These can be thought of as “types of situation where a UAV might be useful”.

Use-cases are generic and abstract. We make them more real by describing one or more “mission profile”, which are instances (examples of) the use case. Each use case might have a number of mission profiles, representing of the variation in the use case that might be encountered in real life. They are an intermediate level of abstraction, and include details such as a maps, mission brief (SMEAC or equivelent), etc. Mission profiles are the layer where we hoipe to engage discussion with the SAR community.

The finest grain of requirement are “scenarios”. These represent a combination of airframe and payload, applied to a mission profile. Scenarios are fine-grained, and contain enough information for us to simulate the performance of some specific hardware against a mission profile. When simulation shows a combination of payload and airframe might be apprpriate for a certain mission profile, the simulartion results will be are presented and discussed.

use-case ideas

• Training - we must be able to provide training to operators
• System evaluation - users must be able to evaluate tools before they can plan to incorporate them
• Component evaluation - developers should be able to work with [potential] users to evaluate performance of components (e.g. evaluate thermal camera with SES assistance)

todo: new sections

• hardware - airframes
• hardware - payloads

Only then can we start developing simulations, assessing specific scenarios, etc.

Aerial Search

Contrary to what we had imagined, the OBC search area is not unrealistically small. In fact, SES are routinely deployed to search areas under 1 square km.

Searching for an unobscured, high visibility target that strongly contrasts a monotonous background is however unrealistic. It’s clear we need to push our vision system harder with some more difficult scenes. Various scenarios were discussed, and the focus was on effectively detecting people in different terrain. It was suggested we continue those discussions with personnel involved in spotting from full scale aircraft (this is not something the SES do themselves).

There was some specific interest in searching over waterways and swampy terrain, where foot traffic is especially slow and we could reasonably expect a UAV to have good visual access to the ground (surface). There was also specific interest in thermal imaging, especially at night, and especially rapid deployment of thermal imaging at crime scenes where the search target might have a fading heat signature.

Mission Profile notes

• helicopter search issues in ACT in summer; low pressure/density
• helicopter search issues in ACT in winter; fog, wind, etc.

Aerial Reconnaissance

Route-finding and route-planning is a significant aspect of ground based search operations. To access a search area, teams sometimes have to travel significant distances through dense or challenging terrain. This can impose a high time-cost on the SAR effort. As well as being difficult and time consuming, the access routes can exposed teams to unexpected hazards (e.g. wild dog packs). Aerial reconnaissance with a UAV could assist the SES team reach the search area faster and more safely.

Scenario: A search team has been tasked with searching an area 8km from the nearest road. Examination of the topographic maps suggest a number of possible routes, but on the information available there is no clear best route. If they chose a good route team might arrive at the search area in as little as 90 minutes, but if they are hampered by terrain or forced to backtrack they might take 3 hours to reach the search area.

It would be of benefit in this situation to have a small UAV reconnoitre candidate routes, and (through image post-processing) augment their existing maps with high resolution orthophotos. For example, if a small fixed wing UAV was deployed at the same time the search party, within 30 minutes it could have travelled 50 km and photographically surveyed all candidate routes. A coordinator at the UAV ground-station (or headquarters if the ground-station has 3G reception) could relay intelligence to the ground team over radio, describing vegetation along various routes and comparing it with vegetation that the team has already passed through, alerting them to hazards or issues, etcetera.

Mission Profiles ideas

• AP / Vegitation mapping
• OBC mission

Aerial contribution to ground-based search of roads

One common mode of operation for SES in a wide area search is to travel along roads/tracks (as opposed to grid-searching). This is a high impact activity typically performed early in a search process. A UAV could act as a “force multiplier” that accelerate this process, so that a combination ground/UAV effort completes the task sooner.

Scenario (without UAVs): A search team has been tasked with scanning the roads between point A and point B. The primary route may be up to 30km. They whole party travels along the primary route for a few Km, where they meet a junction. At the junction, the team splits and a rapid response team are sent to investigate a the side road while the main party travels more slowly along the primary route. The rapid response team travels up the side road, then backtracks to the main road and catches up with the main party. Meanwhile, the main party travels to the next junction and dispatches another rapid response team. The search continues in this fashion until the team arrives at point B, having searched the main route and side tracks.

Scenario with a UAV: A medium sized UAV is deployed from an improvised runway (section of road) somewhere in the vicinity of point A. The UAV is deployed at the same time as the search party, and completes a preliminary search of the primary route within 15 minutes. By 20 minutes, the coordinators have identified numerous junctions/side roads along the primary route and issue updated information to the search team.

During the next 40 minutes, the UAV travels another 80km on it’s return journey. Perhaps 40km of this is spent effectively scanning identified side routes. Many of the side route investigations reveal tracks that are obscured by foliage, and will still require investigation by a ground team. However, some of the side routes are clear and searched effectively by the UAV. Each time a side route is effectively searched by the UAV, the coordinators issue a report to the to the search team informing them that it will not be necessary for them to visit that route during this phase of the search.

Approximately 60 minutes after the UAV/search party have been deployed, the UAV lands. At the 70 minute mark it has been refuelled and relaunched, and goes on to effectively scan another 60km of side route in the next hour (travelling over 120km in the process). This is repeated as many times as necessary.

Patrolling previously searched areas

Roads are rapidly searched during the early phase of a search. During later stages of the search (for example when the ground based teams are occupied with grid searches) it’s possible that the target will self-rescue and arrive on a road. During these later stages, there would be value in repeatedly re-searching (patrolling) the roads from the air.

Mission Profile ideas:

• RFS: check fire trails on day of fire, where to send the blokes with the chainsaws?
• Parks: periodic check of fire trails

Hardware

TODO

Airframes

Describe different classes of airframe, for example:

• ~20kg petrol fixed wing, runway/waterway bound
• ~5kg electric/hybrid fixed wing, launch/land on unimproved fields/roads.
• ~2kg multicopter

For each class, provide examples (including images etc) and nominate a FDM/simulation model representing that class of airframe.

Payloads

Describe different classes of payload...

This is a living document, edits (via GitHub) are automatically built as web pages at readthedocs, and also as a PDF_format. The GitHub site also has an issue tracker and discussion features, which can be used to discuss issues and provide feedback. Contributions very welcome!