SARAA_Project_Summary_Final

Project Summary
SARAA Project
6/30/2010
ENGR 545
Rachael Dietz and Jake Smail

Project Summary
SARAA Project ENGR 545 Page 2
Introduction
This document summarizes the work performed on the Search and Rescue Aerial
Assistance (SARAA) project. The SARAA project was executed from January thru June 2010 as a
capstone project for Masters of Engineering in Systems Engineering program at the University
of Colorado at Colorado Springs. This document will review the application of the systems
engineering process to the project, highlighting every phase of the process from the Concept
Development Stage, including the Needs Analysis, Concept Exploration, and Concept Definition
phases, up to the Engineering Development stage, including the Advanced Development and
Engineering Design, and Test and Integration phases, and briefly discuss Post-Development
work. It will also give concise overviews of the major project deliverables; the Architectural
Framework, Concept of Operations (CONOPS), Requirements Document, Preliminary Design
Review (PDR), and Critical Design Review (CDR).
System Overview
SARAA is an Unmanned Aircraft System (UAS) intended to provide reconnaissance video
for search and rescue missions. SARAA will be launched from potentially austere environments
at the site of the rescue effort to provide video of the targeted search area, making searches
more precise and efficient. SARAA will be piloted by remote control. Real-time video will be
transmitted to the ground station which will be scanned by the search and rescue (SAR) team.
The SAR team will control the path of the aircraft as well as the direction and focus of the
camera to identify potential signs of the subject. Additionally, the team can analyze the video
to determine the safest path to reach the subject, and reduce risk to team members by
identifying potential hazards along the way.

Project Summary
Figure 1: Subsystems and Key Components of SARAA
Concept Development Stage
Concept Development is the first major stage in the systems engineering process. In this
stage, the team identifies and validates a need or opportunity, develops requirements, analyzes
feasibility, generates concepts to meet the requirements, and selects the best concept to meet
the need. The Concept Development stage consists of three major phases: Needs Analysis,
Concept Exploration, and Concept Definition. The following sections describe the work
performed in each phase applied to SARAA.
Needs Analysis
The Needs Analysis phase takes an operational deficiency or technology-driven
opportunity, analyzes it for feasibility, identifies required functions, and ultimately produces a
set of operational requirements. This phase is the foundation of the entire systems
engineering process. The team must make sure it is pursuing a valid need with a feasible
solution and identify the right system-level operational requirements. Failure to successfully
execute this phase will most likely create major problems further into the process.

Project Summary
SARAA is driven by a need to improve a specific task in the SAR process – locating the
subject of the search. Having identified the basic need, the team started by first engaging the
user. The potential user, a member of El Paso County Search and Rescue (EPCSAR), was
interviewed in order to frame the task of locating the subject in the context of the entire SAR
process. From this interview, the team did a functional analysis of a typical search and rescue
mission to better understand the circumstances in which SARAA would operate. This analysis
provided the team with a better understanding of the storage, transportation, and environment
of the system.
The team then looked at the step of the SAR mission most directly impacting SARAA –
locating the subject – and established a rough mission profile and operational concept. The
operational concept can be found in the Architectural Framework and Figure 2 in this
document. The team generated a number of functions SARAA must accomplish from take-off
to landing. These functions were then used to clarify the subsystems required as shown in
Figure 1 in the System Overview section. The functions were put into operational objectives,
which were then quantified into system-level requirements which evolved into Section 4 of the
Requirements Document. The team also explored the storage, maintenance and transportation
needs of SARAA through interviews with the user. Through feedback iterations, the results of
this investigation took the form of User Requirements found in Section 6 of the Requirements
Document.
The operational requirements were validated by two rounds of feedback with both a
user and aerospace engineer. The user gave feedback regarding whether or not the
requirements would meet their needs, while the aerospace engineer gave feedback in regards
to the feasibility of achieving the objectives with existing technology. In this case, design
engineers with knowledge of cameras and communication systems would have been helpful to
better vet the imaging and communication requirements of the system. In addition to the
requirements based on the need, there are also requirements based on regulations. The team
found a large list of standards governing UAVs. These standards are called out in the
Requirements Document and the CONOPS.

Project Summary
SARAA Project
At this point, the team also began to formulate ideas of
This evolved into the operational concept discussed in the Architectural Framework.
Figure 2: Operational Concept of SARAA
The concept of operation
the ground control and the ground control would serve as a relay to the UAV. Sending
commands to the UAV and receiving video and position data from the UAV. Another key
concern is the effect of the harsh Colorado weather o
of operation and the operational
phase.
ENGR 545
eam also began to formulate ideas of how the system would operate.
Operational Concept of SARAA
The concept of operation shows that the primary interface with the SAR team occurs at
concern is the effect of the harsh Colorado weather on the UAV during operation. The conc
of operation and the operational requirements were the primary outputs of the Needs Analysis
Page 5
how the system would operate.
ce with the SAR team occurs at
n the UAV during operation. The concept
requirements were the primary outputs of the Needs Analysis

Project Summary
Concept Exploration
The Concept Exploration phase picks up the system-level requirements and other
analyses and begins digging deeper into the system. This is where the subsystems begin to take
shape and several different alternatives are visualized. Over the course of this phase the team
further refines operational requirements and formulates performance requirements which
represent the engineering requirements as opposed to the operational requirements that
describe what the overall system should accomplish.
In this phase, the team further developed performance requirements and subsystem
requirements. After feedback from the user and aerospace engineer, they evolved into
sections 4 and 5 of the Requirements Document. The team also began identifying the key
components for meeting the requirements as shown in Figure 1. Once the key components are
developed, the team did an interface analysis between subsystems and components. This
exercise broke down each subsystem and showed the functional relationship (mechanical,
power, data, etc) and information flow between key components in other subsystems. Results
of this effort can be seen in diagrams in any one of the major documents. Next, the team
began to evaluate the alternative concepts for the subsystems and identified trade studies
including: Vehicle Body Type, Camera Type, Launch Method, Recovery Method, and Wing
Design. The team performed analysis on selected trade studies. All of this effort was woven
into the Concept of Operations (CONOPS), Requirements Document, Architectural Framework
and Preliminary Design Review.
Concept of Operations
The CONOPS reviews the background, research, justification, and mission description
formulated in the Needs Analysis and Concept Exploration phases. The CONOPS begins with a
brief introduction including the approach and document and system overview. Section 2 goes
on to outline important standards and research sources. A key point to this section is that
many of the standards for UAVs are proposed standards that have not yet gone into effect,
meaning the standards that could impact this project are still in somewhat of a state of flux.
This is a key project risk and should be monitored carefully. Section 3 provides a concise

Project Summary
overview of the project background with some data from EPCSAR. In Section 4, the general
concept of a UAV with contrast video camera is explained along with justification for its need.
Section 5 outlines the basic process of a search and rescue mission today, how SARAA could be
used to enhance the process, and then gives a typical mission profile of SARAA on SAR efforts.
Section 6 turns attention to the Operational Needs Analysis, summarizing high points of the
user interviews about environments and key metrics from an end user perspective. The
CONOPS then addresses details of the environments of SARAA. Section 7 begins with an
operational summary of SARAA from preparing the equipment to storing again and all the
details of its operation in between. It also goes on to give the training requirements to operate
SARAA and the support environment including storage and maintenance. The last substantive
section of the CONOPS is Section 8 which provides a high level view of operational and
organizational impacts. For this project, since there is no predecessor system in the context of
the SAR process, impacts are minimal. The most significant impact is the cost and training time.
All of the information in the CONOPS was derived from various system studies including the
Operations Analysis, Functional Analysis, and Requirements Formulation. These studies were
conducted with constant feedback from the user (a representative of EPCSAR) and an
aerospace engineer.
Requirements Document
The Requirements Document contains detailed information about the specific
requirements the system and subsystems must meet. Section 1 contains a document overview
and a brief system overview. Section 2 breaks down research sources and all applicable
standards much like the CONOPS. Section 3 contains the definition of the system including
description of the system and its subsystems, as well as graphic depiction of the mission profile
for the system. Section 4 then summarizes the operational requirements of the system
developed from the Operational Objectives. Section 5 deals with performance requirements
developed from requirements analysis and are quantified where possible. Both Section 4 and 5
were validated with the user and aerospace design engineer. User requirements are covered
in Section 6 including interfaces with the user and training requirements all these were
validated with a representative of EPCSAR. Section 7 addresses the project assumptions and

Project Summary
constraints, primarily focused on the reality of the project team’s lack of detail design expertise
and resources. Section 8 is the Appendix, containing a preliminary maintenance concept.
Architectural Framework
The Architectural Framework for SARAA summarizes information about the construction
and interactions of the system. The document is structured in DoDAF format to standardize
the views it contains. It begins with the All View 1 which contains overview and introduction
information similar to the CONOPS and Requirements Document. All View 2 contains the
Integrated Dictionary which defines common terms and abbreviations.
The document then provides the first 4 Operational Views (OV). OV-1, the operational
concept, is shown in Figure 2 above. OV-2 describes the operational nodes and the needlines of
information flow between them. OV-3, the information exchange matrix, is a table that goes
into more depth about the information exchanged between nodes in OV-2. OV-4 illustrates the
organizational relationships of SARAA constructed from interviews with the user in the Needs
Analysis Phase.
The Framework ends with the first two systems views (SV). SV-1 provides a look at the
interfaces of the systems pulled from the interface analysis. It shows lines of mechanical
support, supply of power, and data flow. The document concludes with SV-2, a picture of the
communications between internal and external to the system.
Preliminary Design Review
With the CONOPS, Requirements Document, and Architectural Framework synthesized,
the team identified several concepts that would meet the needs of the system to varying
degrees of success at varying costs. A total of 4 alternatives were considered. These
alternatives are shown in the Preliminary Design Review (PDR). In a full scale project scenario,
the team would want to at least kick the tires on several other alternative options to find the
best of the best options.
The PDR begins with a review of its purpose and an overview of the project. Next, every
interface is called out in the interface section including physical interfaces, wireless interfaces,

Project Summary
and user interfaces. The key graphic that describes all the interfaces between key subsystem
components is shown below in Figure 3. The Requirements Development Section captures the
important points of the requirements document. The trade studies section shows the analysis
performed and calls out work the team must find detail design experts to assist in validating the
recommendation.
Figure 3: System Interface Graphic
The four alternatives identified by the team are then laid out in the Systems Alternatives
section. The Subsystem slides then explain the function and requirements of each subsystem.
The last group of slides compares the life cycle costs and feasibility of each alternative. More
work is required to get firm life cycle costs – the information in the PDR is estimated due to
resource limitations. A successful PDR marked the conclusion of the Concept Exploration
phase, the primary outputs of which are the candidate concepts and the refined requirements.
Concept Definition
The concept definition phase takes the candidate systems and selects the best
alternative to meet all the requirements set forth in the previous phases. This final phase in the
Concept Selection Stage is very important to the execution of the project to ensure that the

Project Summary
system will meet the needs of the user and is feasible to implement. In this phase the team
further refines requirements, allocates functions to the component level, and then chooses and
further defines the concept that will be taken into the Engineering Development Stage.
The team began the concept definition stage by validating the performance
requirements and adjusting them as needed based on feedback from the users. With
requirements having been vetted by users and engineers, the team further defined the
subsystems and components of SARAA. Also the team refined the cost of each alternative
throughout the lifecycle, shown in Figure 4 below. The team then made a weighted
comparison among the candidate concepts and selected the concept that had the best balance
of performance and cost. Schedule would also have had to be a major consideration in
selection criteria in a real-life project scenario. All of this work is summarized in the Critical
Design Review (CDR)
Figure 4: Comparison of System Alternatives
$0
$5,000
$10,000
$15,000
$20,000
$25,000
$30,000
Option A:
Modify COTS
design
Option B:
COTS parts
prototype

Project Summary
Critical Design Review
The Critical Design Review captures the team’s work in the Concept Definition Phase.
Arranged in similar format to the PDR, the first sections of the presentation contain the same
type of information, but further refined where necessary. The project overview, system
documentation, system interface, and requirements development sections are all in the same
format as the PDR, but the information has been refined through feedback loops where
possible. The trade study results section illustrates the studies performed by the team where
possible. In some cases, the team had to make a loose recommendation without detailed
analysis due to lack of expertise and resources as noted in the slides.
SARAA system selection section is the key to the entire concept definition phase. The
team performed a weighted comparison between all the candidate systems to select the best
concept. The results are shown below in Figure 5.
Figure 5: Concept Selection Table
The CDR goes on to give more detailed information about each subsystem. In a real
project scenario, the team would have detailed drawings and specifications for each subsystem
and key components, especially focused on the interfaces between them. Maintenance and
operations considerations are then discussed summarizing the work on the maintenance and
operation concept from the entire Concept Development Stage. The next section summarizes
Test and Evaluation considerations for the system. Finally, disposal considerations are
discussed in the last section of slides. The CDR concludes with a recommendation from the
Category
(Weight)
Range
(0.25)
Loiter
(0.2)
Weight
(0.1)
Camera
(0.25)
Cost
(0.2)
Weighted
Total
Option A 0 4 3 4 10 4.10
Option B 4 4 4 5 8 5.05
Option C 7 7 7 6 6 6.55
Option D 8 8 8 8 0 6.40

Project Summary
team. A passing CDR marks the conclusion of the Concept Definition phase and the Concept
Development Stage.
Engineering Development
The Engineering Development stage follows the completion of the Concept
Development stage. In this phase, the materialization of the system gets down to the
component level with detail design engineers designing, testing, and integrating the
components. For example, the team would hand off the structural subsystem design to the
mechanical, the imaging system to an optics expert, and so on. This stage consists of three
phases: Advanced Development phase, Engineering Design Phase, and Integration and
Evaluation.
Advanced Development
The Advanced Development Stage is where the team would break the parts down into
components and sub components and identify any high risk areas that may require further
R&D. Some areas on the SARAA project that could potentially be flagged for this is the contrast
camera and its ability to detect the subject and the battery of SARAA to ensure that it will last
long enough to complete a reasonable reconnaissance mission. Prototypes and development
testing would be useful in both of these areas.
Engineering Design
In the Engineering Design phase, the team would continue to manage the detail design
engineers. This is the phase where the detailed engineering drawings to the part level would
come to fruition. In this phase, the systems engineering team would continue to manage the
interfaces between other components and subsystems. For SARAA, the team would manage all
the interfaces and requirements with regard to the design of the components and parts. Many
subsystems are Commercial off the Shelf (COTS) parts except for the structural system and
ground control so the focus for SARAA would be on the interfaces in the structural subsystem
with the COTS components and the ground control software.

Project Summary
Test and Integration
Once the components are designed, the Test and Integration phase brings parts
together to ensure they meet the requirements allocated to the component, subsystem, and
system level. Parts are integrated into components, components into subsystems, and
subsystems into the system. In the case of SARAA, early testing would focus primarily around
the components and subsystem of the Ground Control and Structural Subsystem. The last step
would be integrating the COTS Camera, GPS receiver, UAV Antenna, and Battery with the
structural subsystem and ground control. As systems engineers, the team would interface with
test engineering to complete this phase and ensure all requirements are validated. This would
conclude the Test and Integration phase as well as the Engineering Development stage.
Post Development
With the Concept Development and Engineering Development complete, the team will
have a further reduced role, but must continue to manage the system into Production phase
and Operation phase. The team had several considerations regarding the production,
operation, maintenance, and phase out listed throughout the documentation in the
maintenance concept and disposal considerations. Because SARAA would be a very low-volume
system, it is unlikely to require the kind of rigorous quality and control plans that apply to high
volume systems; however, testing each product that comes off the line would be required. The
team may also be required to help solve production problems and production and help compile
a training program for the end users as laid out in the Requirements Document.
Conclusion
This document has summarized the work performed on the SARAA project and the work
that would be required of systems engineering in the future stages of the project if executed.
The team consulted with users to build a CONOPS, Requirements Document, Architectural
Framework, PDR, and CDR. These documents have information on background, standards,

Project Summary
requirements, views of the system, and proposed concepts, and the best concept based on the
information available. Had this been a fully funded real project, the team would have needed a
deeper dive in several areas. More resources would have had to have been made available.
The team would have required consultation with experts in optics, GPS, and communications
systems in addition to the aerospace engineer. However, if given proper resources and
funding, the team has shown in the documentation that this project would serve a validated
need and it is feasible to accomplish.

SARAA_Project_Summary_Final

More Related Content

Viewers also liked (8)

Similar to SARAA_Project_Summary_Final (20)

SARAA_Project_Summary_Final