Roig Final Report v1

Systems Engineering Masters
Project
Airfield FOD Detection, Identification, Removal and

Tracking System (AFDIRTS)
Prepared by
Louis R. Roig
Submitted for review:

Mentor: Chuck Olson
The Johns Hopkins University
Whiting School of Engineering
Engineering for Professionals
EN 645.800
Table of Contents
Project Objectives and Approach...
AFDIRTS System Description
Key Performance Parameters... 6

Subsystem Description
AFDIRTS Context Diagram.
13
AFDIRTS CONOPS..
14
Initial Requirements Document.. 15

Originating Requirements 15
Functional Requirements. 28
Performance Requirements 40
Programmatic Requirements. 51
Design Constraints. 54
Functional Architecture. 58
Functional Traceability Matrix. 58
F. Perform AFDIRTS Functions. 63
F.1 Command and Control System. 64
F.2 Operate Safely 78
F.3 Scan Airfield for FOD. 88
F.4 Retrieve FOD 97
F.5 Navigate Airfield. 108
F.6 Locomote System Elements. 123
F.7 Maintain System.. 132
F.8 Provide Power.. 137
F.9 Analyze FOD Trends 142
Physical Architecture.. 150
COMP.1 Command and Control Segment 152
Functional Traceability Matrix 152
Interface Descriptions.. 153
COMP.2 System Health and Monitoring Segment 158
COMP.3 FOD Detection Segment .163

COMP.4 Air Retrieval Vehicle (ARV). 167
COMP.4.11 ARV Movement and Control Subsystem 168
Functional Traceability Matrix.. 170
Interface Descriptions 172
COMP.4.2 ARV Navigation Subsystem .. 182
COMP.4.3 ARV Power Subsystem . 188
COMP.4.4 ARV Retrieval Subsystem 194
COMP.5 Power and Housing Segment. 199
Functional Traceability Matrix. 201
COMP.6 FOD Analysis Segment 205
Functional Traceability Matrix.. 205
Interface Descriptions... 206
Trade Study 208
Battery Alternatives... 209
Selection Criteria 214
Weightings 216
Utility Functions 218
Rankings 222
Sensitivity Analysis... 224
Selection 225
Risk Management 226
AFDIRTS System Specifications. 234
AFDIRTS System Requirements 236

AFDIRTS System Requirement Origin Map 239
AFDIRTS External Interface Specifications 240
Command and Control Segment Requirements.. 242
Requirement Origin Map. 243
Subsystem Specifications. 244
Internal Interfaces.. 246
System Health and Monitoring Segment Requirements.. 247
FOD Detection Segment Requirements Segment Requirements. 252
Air Retrieval Vehicle (ARV) Segment Requirements.. 256
ARV Movement and Control Subsystem Requirements. 260
Requirement Origin Map.. 260
Subsystem Specifications.. 261
Subsystem Internal Interface Specifications. 263
ARV Navigation Subsystem Requirements.. 264
Requirement Origin Map... 265
Subsystem Specifications... 266
ARV Power Subsystem Requirements... 269
Subsystem Internal Interface Specifications 271
ARV FOD Gripping Subsystem Requirements. 272

ARV Housing and System Power Segment Requirements 276
FOD Analysis Segment Requirements .. 280
SM4 Schedule Assessment.... 283
Lessons Learned 288
Appendix A: Original Concept/Proposal Paper ... 290
Appendix B: Original Requirements Analysis Report.. 310
Appendix C: Original Functional Analysis Report .. 409
Appendix D: Original Conceptual Design Report.. 501
Appendix E: Original Trade Study.. 563
Appendix F: Original A-Specification 584
Appendix G: Original Risk Management Report 640
Project Objectives and Approach

The ultimate goal of the SM4 project was to attain, and ultimately demonstrate a level
of mastery of the systems engineering discipline. This was accomplished by applying
the systems engineering method to a real world problem and ultimately developing a
system specification that could solve this problem.
The AFDIRTS system was realized by applying the systems engineering method to the
FOD detection and retrieval problem. To start, operational analysis was performed by
making contact and engaging in discussions with potential stakeholders. Research was
conducted to determine the FAAs current capabilities regarding FOD detection, and a
capability gap was identified. A needs statement was developed and overarching
operational objectives were derived from the perceived need. Once Operational
Objectives were defined, they were uploaded into CORE.
Original Operational Objectives have been listed below:
Original Operational Objectives

1. Provide Safe Operation
1.1. Provide System Redundancy
1.2. Provide Self Diagnostics
1.3. Provide Remote Power Cut-Off to Mobile Units
1.4. Meet or exceed all FAA Regulations
1.5. Meet or exceed all Environmental Regulations
2. Provide Automated FOD Detection
3. Provide Automated FOD Retrieval
4. Provide System Command, Control and Locomotion
4.1. Provide Air Traffic Control Interface
4.2. Provide Airfield Navigation
4.3. Provide Mobile Unit Locomotion
4.4. Provide Obstacle Detection and Avoidance
5. Facilitate Inclement Weather Operation

5.1. Provide Operation During Freezing Conditions
5.2. Provide Operation During Hot Conditions
5.3. Provide Operation In Wet Conditions
5.4. Provide Operation In Windy Conditions
5.5. Provide Operation in Sandy Conditions
5.6. Provide Operation in Corrosive Environments
5.7. Provide Operation in Humid Conditions
6.
Provide a High Level of Reliability, Availability and Maintainability

6.1. Facilitate System Reliability
6.2. Facilitate System Availability
6.3. Facilitate Ease of Maintenance
6.3.1. Provide Built in Tests (BIT)
6.3.2. Provide Component Modularity
7.
Provide FOD Trend Analysis

7.1. Provide FOD Location
7.2. Provide FOD Image
7.3. Provide a method of FOD Report Transmission
After all operational objectives had been defined and decomposed, functional
analysis was performed to derive preliminary system functions; these functions were
uploaded into CORE.
A feasibility study was performed to establish feasibility criteria for the AFDIRTS concept.
Once feasibility criteria had been applied to eligible system concepts, a feasible system
concept was defined and effectiveness analysis was performed based upon the ability;
and feasibility of the preliminary system concept to meet the need within cost, time,
technological, operational, safety and regulatory constraints. From this, a preliminary
physical architecture was developed. After a multiple feasible system concepts were
defined the needs validation step was performed. During this phase Measures of
Effectiveness (MOE) were developed based upon interviews and discussions with
potential customers as well as research into the FAAs current FOD detection system
2
guidance published in Advisory Circular 150/5220-24 and FOD Management guidance

published in Advisory Circular 150/5210-24. The top five MOEs are listed below:
Measures of Effectiveness
1. Provide redundancy for components or subsystems deemed High Risk during Failure
Mode, Effects and Criticality Analysis (FMECA) (Binary MOE expressed as a metric of
operational objective 1.1 Provide system redundancy)
2. Detect an unpainted metal cylinder, measuring x inch high and x inches wide; and a
white, grey, or black sphere with the radius of x inches) any time day or night in clear
weather and inclement weather conditions*. (Measurement MOE expressed as a
measurement of operational objective 2.0 Provide automate FOD detection) This MOE
was based in part on current FAA FOD detection system guidance listed in AC
150/5220-24.
3. Capable of retrieving FOD from anywhere on the AOA in under 5 minutes after
detection night and day and in clear and inclement weather conditions* (Binary MOE
expressed as a metric of operational objective 3.0 provide automated FOD retrieval).
4. Capable of autonomous movement on AOAs at a speed of x MPH, during clear and
inclement weather conditions*. (Measurement MOE expressed as a metric of
operational objective 4.3 provide mobile unit locomotion)
5. Detect obstacles at a distance of x feet from mobile units, day and night during clear
and inclement weather conditions *. (Measurement MOE expressed as a metric of
operational objective 4.4 Provide obstacle detection and avoidance)
* Inclement weather conditions is defined as adverse weather that can still sustain flight operations.
Different operational scenarios were evaluated which helped translate operational

objectives into preliminary operational requirements
Once operational scenarios were evaluated preliminary operational objectives were
translated into preliminary operational requirements which were subsequently
uploaded into CORE, and were refined even further with inputs from stakeholders.
At the end of the Needs Analysis phase enough information was available to develop
and submit the SM4 Project Proposal. Additionally, Operational Requirements that were
developed were then utilized as input to the Concept Exploration Phase. In order to
apply the Concept Exploration phase effectively, a system context and multiple
potential system concepts had to be clearly defined. It was necessary to consult with
potential users and subject matter experts so that initial functional and performance
requirements could be accurately formulated. This was accomplished by polling 28
subject matter experts with a questionnaire that was designed and implemented on
the SurveyMonkey web platform.
The analysis of Subject Matter Experts and Users revealed many factors that were
considered during Concept Development. After Operational Requirements Analysis
was performed Performance Requirements Formulation, Implementation Concept
Exploration, and Performance Requirements Validation were applied to the SM4 Project
and an initial set of performance requirements were developed and documented in
CORE. This step was utilized to develop the Requirements Analysis Report.
Finally, the Concept Definition phase of the systems engineering method was
performed by completing Performance Requirements Analysis, Functional Analysis and
Formulation, Concept Selection, and Concept Validation. During this process, three
competing concepts that could potentially solve the need for a FOD Detection and
Retrieval system were explored. The three options were; the Roomba Option, which
made use of roaming mobile units that would continuously search the airfield for FOD
(much like the vacuum Roomba). A ground retrieval option, which made use of existing
FOD detection systems that would continuously sweep the airfield for FOD and then
when found, location would be transmitted to the mobile units for retrieval. And finally,
the Airborne Option which operated much like the ground retrieval option except the
retrieval units were airborne.
Informal trade studies revealed many advantages to the Airborne Option. Some of
which were; mobile unit speed, ability to navigate above obstacles, ability to cross
unpaved surfaces and ease of FOD disposal. Additionally, it is believed that future
versions, could incorporate bird deterrent functionality. The Airborne Option was
selected and Functional and Physical architecture were developed. A System
4
Specification (A-Spec) captured component and interface specifications and these

documents were submitted as project deliverables.
AFDIRTS Description
FOD damage to aircraft occurring at critical moments in flight has led to loss of life and
complete destruction of aircraft. An example of this was Air Frances flight 4590, a
Concorde, on a scheduled international flight from Paris to New York City that crashed
killing all 109 people onboard after a titanium alloy strip, 17.1 inches long and about 1.3
inches wide ruptured a tire and sent a piece of it through the wing during takeoff.
The AFDIRTS was designed to provide a safe autonomous method of detecting,
identifying, removing and tracking FOD from Airport Operation Areas (AOAs) 24 hours
a day 7 days a week while not interfering with normal airport operations. The AFDIRTS is
capable of centralized command and control from the Air Traffic Control Tower and is
capable of operation in inclement weather. The AFDIRTS was designed to be reliable,
affordable and maintainable. AFDIRTS Key Performance Parameters have been listed
below.
Key Performance Parameters

R.3.1 ATC Emergency Control
Performance Requirement Statement:
Air Traffic Control shall be capable of initiating an emergency mode of
operation that removes all Air Retrieval Vehicles from airfield operating
areas within 30 seconds.
R.2.1 Power Failure
In the event of a power failure, the AFDIRTS system must have the
capability to automatically power-up and operate in the condition and
settings that were available just prior to the power failure.
R.5.4.3 FOD Max Weight

The AFDIRTS system shall be capable of retrieving FOD weighing up to 1
pound (.453 kilograms)
R.5.4.5 FOD Dimensions
Air Retrieval Vehicles shall be capable of retrieving FOD with dimensions
of up to 12 inches in length 12 Inches in width and 12 inches in height.
R.5.2.2 Mobile Unit Movement Clearance
The AFDIRTS system shall be capable of detecting, anticipating movement
and avoiding all airport traffic without input from air traffic control.
System Segments
The AFDIRTS consists of six major segments; The Command and Control Segment,
System Health and Monitoring Segment, FOD Detection Segment, Air Retrieval Vehicle
(ARV) Segment, Power and Housing Segment and the FOD Analysis Segment.
COMP.1 Command and Control Segment

The Command and Control Segment is made up of 7 Hardware Configuration Items
(HWCI) and 1 Software Configuration Item (SWCI) integrated to perform the F.1
Command and Control the System function. In addition to command and control the
segment allows users to interface with the AFDIRTS.
COMP.2 System Health and Monitoring Segment

The System Health and Monitoring Segment is comprised of 4 HWCI and 1 SWCI which
come together to perform the F.2 Operate Safely Function. During this stage of system
development there was not enough information to determine critical subsystems to
satisfy requirement R.3.5 The system shall be capable of continuously monitoring
7
system health of critical subsystems therefore, COMP.2.3 Components Defined as

"Critical" During Advanced Development was reserved for the Engineering
Development Stage.
COMP.3 FOD Detection Segment

The FOD Detection Segment will be comprised of a Commercial off the Shelf (COTS)
FOD Detection system designed to perform the F.3 Detect FOD function. There were a
few different commercially available systems to choose from and the selection of the
FOD Detection system utilized in the AFDIRTS concept was a result of an informal trade
study that compared four different FOD Detection technologies. These have been listed
below:
Tarsier Radar Currently being tested at T.F. Green Airport (PVD) in Providence, RI
(PVD). Developed by QinetiQ Corporation, Tarsier utilizes millimeter wave radars that
are mounted on rigid towers to sweep runways. Once FOD is detected, the integrated
day/night camera zooms in to identify it and ultimately have airport personnel retrieve it
(QinetiQ, 2015).
IFerret Is currently being evaluated at Chicago OHare (ORD) International Airport.
Developed by Stratech Group Inc., IFerret consists of a high resolution camera mounted
on rigid towers that scan for and detect FOD on Runways, Taxiways and Aircraft Aprons.
Once the FOD is detected, personnel are notified to retrieve it (Stratech, 2015).
FODetect - Is currently being tested at Boston Logan (BOS) international Airport.
Developed by XSight Systems, FODetect utilized a high resolution camera combined
with millimeter wave radar mounted on airport lighting fixtures (XSight, 2015).
FOD Finder Is currently being tested at Chicago OHare (ORD) International Airport.
Developed by Trex Enterprises Corporation, FOD Finder utilizes a Millimeter Wave Radar
and Infrared Cameras that are mounted on top of Airport Vehicles that scout AOAs for
FOD.
The IFerret was selected and the Stratech Group will be contracted to develop an
Interface Unit that can transfer FOD information to the AFDIRTS. This will be done during
the Engineering Development Stage and will facilitate automated FOD retrieval.
8
Figure 1. IFerret CONOPS
COMP.4 Air Retrieval Vehicle (ARV)

The Air Retrieval Vehicle (ARV) (shown below in figure 2) performs the F.4 Retrieve FOD
function and is designed to transport the Retrieval Subsystem System to the FODs
location on the airfield, and grasp it with a COTS gripper, performing the F.4.3 Grasp
FOD function. The ARV consists of four Subsystems; the Movement and Control
Subsystem, the Navigation Subsystem, ARV Power Subsystem, and the Retrieval
Subsystem.
Figure 2. COMP.4 Air Retrieval Vehicle (ARV) Conceptual Image
COMP 4.1 Movement and Control Subsystem

The ARV Movement and Control Subsystem has been designed to facilitate movement
and stability of the ARV while maneuvering to waypoints. It performs the F.4.1 Move and
Control Function and consists of an Attitude and Heading Reference System (AHARS),
Barometric Altimeter, GPS Unit, Movement and Control Computer, 8 Propellers, 8
Electric Motors and 8 Electronic Speed Controllers.
COMP 4.2 ARV Navigation Subsystem

The ARV Navigation Subsystem was designed to receive ARV navigation instructions
from the Command and Control Subsystem. It performs the F.5 Navigate Airfield
function, and will enable the ARV to navigate the airfield avoiding obstacles and
airport traffic while executing movement commands.
COMP 4.3 ARV Power Subsystem

The ARV Power Subsystem supplies stored power to ARV Components, it performs the
F.6.1 Facilitate Power function. It consists of a Lithium-Ion Battery, a Power Distribution
Board, and a Voltage Regulator.
* The lithium-ion battery was selected as a result of a formal trade study shown on page 208.
10
COMP 4.4 Retrieval Subsystem

The Retrieval Subsystem consists of 3 HWCI and 1 Subsystem. It is designed to allow the
ARV to perform the F.4.3 Grasp FOD and F.4.3.6 Release FOD functions. It utilizes the
COTS VERSABALL Gripper manufactured by Empire Robotics as shown below in figure 3.
The VERSABALL Gripper was selected after an informal trade study compared many
different types of articulating grasping systems.
Figure 3. Versaball Gripper
COMP.5 Power and Housing Segment

The Power and Housing Segment is designed to house and power the ARV when not in
use. The figure below (Figure 4) is a conceptual image and not intended to be a
representation of the actual structural design. The structural design will be developed in
the Advanced Development Phase and it will result from prototypes that can withstand
the elements and are easily integrated with the IFerret Detection System. It may even
be attached to the IFerret Structure.
11
Figure 4. COMP.5 Power and Housing Segment Conceptual Image
COMP.6 FOD analysis segment

The FOD analysis segment is designed to provide airport management with data that
can help them identify trends in Airfield Debris, so that corrective measures can be
implemented to minimize FOD on the airfield. It consists of a telemetry radio that will
receive FOD Data and a computer and software to process this data.
12
Figure 5. AFDIRTS Context Diagram
Air Traffic
Control
Environment
Heat (E)
Sound (E)
Rain (M)
Resistance (E)
Wind (F)
Snow (M)
GPS Signals (D)
Gravity (F)
Inertia (F)
Barometric
Pressure
System Health (D)

System Status (D)
Unsuitable FOD Data (D)
Reports (D)
Aircraft Location (D)
Obstacle Illumination (E)
Obstacles
Obstacle Location (E)

Obstacle Identification (E)
Airport
Managers
ATC Command (D)

Aircraft Radar Data
(D)
AFDIRTS
Aircraft
Operators
Aircraft Illumination (E)
Electrical Energy (E)

FOD Illumination (E)
Forces (F)
Energy (E)
Data (D)
Signals (S)
FOD Location (E)

FOD Identification (D)
Materials (M)
Parts (M)
Materials (M)
Fault Codes (D)
System Health (D)
Power
Parts (M)
Materials (M)
SW Update (S)
Maintenance Commands (D)
FOD
Maintainer
13
Command
and Control
Maintenance
FOD
Detection
Obstacle
Detection and
Avoidance
FOD
Disposal
FOD Retrieval
14
Originating Requirements
R Need Statement
Requirement Statement:
The Airfield FOD Detection, Identification, Removal and Tracking System (AFDIRTS)
is to provide a safe autonomous method of detecting, identifying, removing and
analyzing FOD trends from airports while not interfering with normal airport
operations. The AFDIRTS will provide a method of centralized command and
control (KPP R.2.1) and be capable of operation in inclement weather. The
AFDIRTS shall be reliable, maintainable and affordable.
Refined By Subordinate Requirements:
R.1 Safe Operation
R.2 System Command and Control
R.3 FOD Scanning and Detection
R.4 FOD Reporting
R.5 FOD Retrieval
R.6 Mobile Unit Locomotion
R.7 Provide FOD Trend Analysis
R.8 System Communication
R.9 Technical Support
R.10 Installation and Acceptance Standards
R.11 Reliability, Availability and Maintainability
R.12 Operate in Adverse Weather Conditions
15
R.1 Safe Operation

Figure 7. Safe Operation Requirements Hierarchy Diagram
hier Safe Operation
R.1
Safe Operation
Requirement
R.1.1
R.1.1.1
refined by
verified by
Emergency
Demonstration
Requirement
VerificationRequ...
refined by
verified by
Execution Speed
Test
Requirement
VerificationRequ...
University Edition - For Academic Use Only
Date:
November 7, 2015
The system shall not cause damage to airport personal or property; nor shall it
become a distraction to operations or support personnel.
Refines Higher-Level Requirement:
R Need Statement
R.1.1 Emergency
Based Upon Operational Objective:
OO-1 Provide safe operation
16

Figure 8. System Command and Control Requirements Hierarchy Diagram
hier System Command and Control
R.2
System Command
and Control
Requirement
basis of
R.2.1
refined by
refined by
R.2.2
R.2.3
refined by
R.2.4
refined by
verified by
Command and
Control System
System Command
Location of
Aircraft
Unsuitable FOD
Power Failure
Test
Function
Requirement
Requirement
Requirement
Requirement
VerificationRequ...
verified by
verified by
verified by
verified by
Test
Test
Test
Test
VerificationRequ...
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
The system shall be capable of centralized command and control of all system
elements.
R Need Statement
R.2.1 System Command
R.2.2 Location of Aircraft
R.2.3 Unsuitable FOD
R.2.4 Power Failure
OO-2 Provide efficient and effective system command and control.
17

Figure 9. FOD Scanning and Detection Requirements Hierarchy Diagram
hier FOD Scanning and Detection
R.3
FOD Scanning
and Detection
Requirement
R.3.1
refined by
Airfield Scanning
verified by
Demonstration
FOD Detection
Requirement
R.3.1.1
refined by
R.3.2
VerificationRequ...
Requirement
verified by
refined by
Detection Time
Demonstration
Requirement
VerificationRequ...
verified by
basis of
R.3.2.1
refined by
Detect FOD
Group Object
Detection
Function
Requirement
Demonstration
R.3.2.2
R.3.2.4
refined by
Metal Cylinder
Detection
Requirement
verified by
R.3.2.3
refined by
Sphere Detection
Requirement
Test
R.3.2.5
refined by
verified by
Automated
Retrieval Suitabil...
Test
Requirement
Requirement
VerificationRequ...
verified by
verified by
verified by
verified by
Test
Test
VerificationRequ...
VerificationRequ...
VerificationRequ...
refined by
Lighting
Conditions
Test
Test
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
The system shall be capable of scanning the airfield and detecting single and
multiple FOD items.
Requirement Rationale:
This functional requirement originated from FAA AC 150/5220-24 Airport Foreign
Object Debris (FOD) Detection Equipment.
R Need Statement
R.3.1 Airfield Scanning
R.3.2 FOD Detection
Based upon Operational Objective:
OO-3 Provide a method of airfield scanning and FOD detection.
18
R.4 FOD Reporting
Figure 10. FOD Reporting Requirements Hierarchy Diagram
hier FOD Reporting
R.4
FOD Reporting
Requirement
R.4.1
R.4.1.1
refined by
R.4.1.2
refined by
verified by
FOD Location
Reporting
Demonstration
Requirement
VerificationRequ...
refined by
R.4.1.3
refined by
verified by
Active Reporting
Passive Reporting
Suitability
Reporting
Test
Requirement
Requirement
Requirement
VerificationRequ...
Date:
November 7, 2015
The system shall be capable of reporting FOD location data and FOD
characteristics to the retrieval subsystem.
This performance requirement originated from FAA AC 150/5220-24 Airport Foreign
R Need Statement
R.4.1 FOD Location Reporting
OO-4 Provide a method of FOD Reporting.
19
R.5 FOD Retrieval

Figure 11. FOD Retrieval Requirements Hierarchy Diagram
hier FOD Retrieval
R.5
FOD Retrieval
Requirement
R.5.1
refined by
refined by
R.5.2
R.5.3
refined by
R.5.4
refined by
verified by
FOD Weight
Determination
FOD Weight
FOD location
FOD Dimensions
Demonstration
Requirement
Requirement
Requirement
Requirement
VerificationRequ...
verified by
verified by
verified by
verified by
Test
Test
Test
Test
VerificationRequ...
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
The system shall be capable autonomously retrieving FOD from both paved and
grass surfaces.
R Need Statement
R.5.1 FOD Weight Determination
R.5.2 FOD Weight
R.5.3 FOD location
R.5.4 FOD Dimensions
OO-05 Provide a method of FOD retrieval.
20

Figure 12. Mobile Unit Locomotion Requirements Hierarchy Diagram
hier Mobile Unit Locomotion
R.6
Mobile Unit
Locomotion
Requirement
R.6.1
refined by
R.6.2
refined by
R.6.3
refined by
refined by
R.6.4
R.6.5
refined by
R.6.6
refined by
R.6.7
refined by
verified by
Mobile Unit Speed
Mobile Unit
Navigation
Mobile Unit
Movement Clea...
Separation from
Obstacles
Separation from
Aircraft
Separation from
Personnel
Separation from
Vehicles
Test
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
VerificationRequ...
verified by
R.6.2.1
refined by
R.6.2.2
refined by
R.6.2.3
refined by
verified by
verified by
verified by
verified by
verified by
verified by
Demonstration
FOD Location
Emergency
Posture
Standby Location
Demonstration
Demonstration
Test
Test
Test
Test
VerificationRequ...
Requirement
Requirement
Requirement
VerificationRequ...
VerificationRequ...
VerificationRequ...
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
The system shall provide a method of locomotion for mobile system elements.
R Need Statement
R.6.1 Mobile Unit Speed
R.6.2 Mobile Unit Navigation
R.6.3 Mobile Unit Movement Clearance
R.6.4 Separation from Obstacles
R.6.5 Separation from Aircraft
R.6.6 Separation from Personnel
R.6.7 Separation from Vehicles
OO-06 Facilitate mobile element locomotion.
21

Figure 13. Provide FOD Trend Analysis Requirements Hierarchy Diagram
hier Provide FOD Trend Analysis
R.7
Provide FOD
Trend Analysis
Requirement
basis of
refined by
R.7.1
verified by
Analyze FOD
Trends
Types of Data
Demonstration
Function
Requirement
VerificationRequ...
R.7.1.1
refined by
verified by
Storage of Data
Test
Requirement
VerificationRequ...
refined by
R.7.1.1.1
verified by
Data Retention
Test
Requirement
VerificationRequ...
verified by
Demonstration
VerificationRequ...
Date:
November 7, 2015
The system shall provide a method of trend analysis.
R Need Statement
R.7.1 Types of Data
OO-07 Provide FOD trend analysis.
22

Figure 14. System Communication Requirements Hierarchy Diagram
hier System Communication
R.8
System
Communication
Requirement
R.8.1
refined by
R.8.2
refined by
R.8.3
refined by
verified by
ATC
Communication
Airport
Management C...
Maintainer
Communication
Demonstration
Requirement
Requirement
Requirement
VerificationRequ...
verified by
verified by
verified by
Demonstration
Demonstration
Demonstration
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
The system shall provide a method of communicating with air traffic control,
airport management, and system maintainers.
R Need Statement
R.8.1 ATC Communication
R.8.2 Airport Management Communication
R.8.3 Maintainer Communication
OO-09 Provide a method of communicating with external system elements.
23

Figure 15. Technical Support Requirements Hierarchy Diagram
hier Technical Support
R.9
Technical Support
Requirement
R.9.1
R.9.1.1
refined by
R.9.1.2
refined by
refined by
R.9.2
refined by
verified by
Maintenance
Procedures
Call Center
Analysis
Requirement
Requirement
VerificationRequ...
R.9.1.3
refined by
R.9.1.4
refined by
verified by
verified by
Cleaning
Procedures
Preventative
Maintenance Pr...
Recalibration Plan
Scheduled
Component Re...
Analysis
Demonstration
Requirement
Requirement
Requirement
Requirement
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
System users shall be provided with technical support.
R Need Statement
R.9.1 Maintenance Procedures
R.9.2 Call Center
OO-08 Provide technical support.
24
Figure 16. Installation and Acceptance Standards Requirements Hierarchy Diagram

hier Installation and Acceptance Standards
R.10
Installation and
Acceptance Sta...
Requirement
R.10.1
R.10.1.1
refined by
R.10.1.2
refined by
refined by
verified by
Elements Located
Near The Runway
Inspection
Requirement
VerificationRequ...
R.10.1.3
refined by
R.10.1.4
refined by
verified by
Breakaway
Connector
Element Height
Frangible Coupling
Wind Loading
Inspection
Requirement
Requirement
Requirement
Requirement
VerificationRequ...
Date:
November 7, 2015
The system shall conform to applicable airport obstruction criteria, marking and
lighting, and equipment design and installation standards.
R Need Statement
R.10.1 Elements Located Near the Runway
OO-10 Comply with installation and acceptance standards.
25
Figure 17. Reliability, Availability and Maintainability Requirements Hierarchy Diagram

hier Reliability, Availability and Maintainability
R.11
Reliability,
Availability and...
Requirement
R.11.1
refined by
R.11.2
refined by
verified by
System
Availability
System
Maintainability
Analysis
Requirement
Requirement
VerificationRequ...
verified by
R.11.2.1
refined by
R.11.2.2
refined by
verified by
Analysis
System Health
and Fault Notific...
Equipment
Located Outside...
Analysis
VerificationRequ...
Requirement
Requirement
VerificationRequ...
Date:
November 7, 2015
The system shall provide a high level of reliability, availability and maintainability.
R Need Statement
R.11.1 System Availability
R.11.2 System Maintainability
OO-11 Provide a reliable, maintainable, and available system.
26

Figure 18. Operate in Adverse Weather Conditions Requirements Hierarchy Diagram
hier Operate in Adverse Weather Conditions
R.12
Operate in
Adverse Weathe...
Requirement
R.12.1
refined by
R.12.2
refined by
R.12.3
refined by
verified by
Performance in
Rain
Performance in
Snow
Performance in
Wind
Test
Requirement
Requirement
Requirement
VerificationRequ...
verified by
verified by
verified by
Test
Test
Test
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
The system shall be capable of operating in rain, wind and snow.
R Need Statement
R.12.1 Performance in Rain
R.12.2 Performance in Snow
R.12.3 Performance in Wind
OO-12 Facilitate adverse weather operation.
27
Functional Requirements
R.1.1 Emergency
Figure 19. Emergency Requirements Hierarchy Diagram

hier Emergency
R.1.1
Emergency
Requirement
R.1.1.1
refined by
verified by
Execution Speed
Test
Requirement
VerificationRequ...
verified by
Demonstration
VerificationRequ...
University Edition - For Academic...
Date:
November 7, 2...
Functional Requirement Statement:

The system shall be capable of entering an emergency mode of operation that
removes mobile units from Airport Operating Areas.
R.1 Safe Operation
Refined By Lower-Level Requirements:
R.1.1.1 Execution Speed
Air Traffic Control shall be capable of initiating system modes.
28

The system shall be capable of determining the location and trajectory of inbound
aircraft.
The system shall be capable of notifying airport personnel when FOD is
determined to be unsuitable for automated retrieval.
Figure 20. Airfield Scanning Requirements Hierarchy Diagram

hier Airfield Scanning
R.3.1
Airfield Scanning
Requirement
R.3.1.1
refined by
verified by
Detection Time
Demonstration
Requirement
VerificationRequ...
verified by
Demonstration
VerificationRequ...
Date:
November 7, 2...
29
The system shall be capable of scanning the runways, taxiways, aircraft ramps
and adjoining grass areas for FOD.
R.3.1.1 Detection Time
Figure 21. FOD Location Reporting Requirements Hierarchy Diagram
hier FOD Location Reporting
R.4.1
FOD Location
Reporting
Requirement
R.4.1.1
refined by
R.4.1.2
refined by
R.4.1.3
refined by
verified by
Active Reporting
Passive Reporting
Suitability
Reporting
Test
Requirement
Requirement
Requirement
VerificationRequ...
verified by
verified by
verified by
Demonstration
Demonstration
Demonstration
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015

The system shall provide a method of transmitting FOD location data to the
retrieval subsystem.
R.4 FOD Reporting
30
R.4.1.1 Active Reporting
R.4.1.2 Passive Reporting
R.4.1.3 Suitability Reporting
The system shall be capable of determining when objects are too heavy for
retrieval.
R.5 FOD Retrieval
Figure 22. Mobile Unit Navigation Requirements Hierarchy Diagram

hier Mobile Unit Navigation
R.6.2
Mobile Unit
Navigation
Requirement
R.6.2.1
refined by
R.6.2.2
refined by
R.6.2.3
refined by
verified by
FOD Location
Emergency
Posture
Standby Location
Demonstration
Requirement
Requirement
Requirement
VerificationRequ...
verified by
verified by
verified by
Demonstration
Demonstration
Demonstration
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015

Mobile system elements shall be capable of navigating the airfield autonomously.
31
R.6.2.1 FOD Location
R.6.2.2 Emergency Posture
R.6.2.3 Standby Location
Mobile system elements shall be capable of navigating to FOD locations.
Mobile system elements shall be capable of navigating to predefined emergency
locations defined by airport managers.
Mobile system elements shall be capable of navigating to standby locations that
will be determined by concept selection.
32
R.7.1 Types of Data
Figure 23. Types of Data Requirements Hierarchy Diagram

hier Types of Data
R.7.1
Types of Data
Requirement
R.7.1.1
refined by
verified by
Storage of Data
Test
Requirement
VerificationRequ...
refined by
R.7.1.1.1
verified by
Data Retention
Test
Requirement
VerificationRequ...
Date:
November 7, 2015

The system shall be capable of receiving and storing FOD alert time and date,
location coordinates and FOD image data.
R.7.1.1 Storage of Data
33

Figure 24. Storage of Data Requirements Hierarchy Diagram
hier Storage of Data
R.7.1.1
Storage of Data
Requirement
refined by
R.7.1.1.1
verified by
Data Retention
Test
Requirement
VerificationRequ...
verified by
Demonstration
VerificationRequ...
Date:
November 7, 2...

Data collected in the FOD detection process shall be recorded and stored.
R.7.1 Types of Data
R.7.1.1.1 Data Retention
34

Figure 25. System Maintainability Requirements Hierarchy Diagram
hier System Maintainability
R.11.2
System
Maintainability
Requirement
R.11.2.1
refined by
R.11.2.1.1
refined by
R.11.2.2
refined by
verified by
System Health
Equipment
Located Outside...
Analysis
Requirement
Requirement
VerificationRequ...
refined by
R.11.2.1.2
verified by
verified by
System Health
Self Test & Fault

Notification
Test
Demonstration
Requirement
Requirement
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015

The system should be designed to ease maintenance functions.
R.11.2.1 System Health and Fault Notification
R.11.2.2 Equipment Located Outside of Paved Surfaces
35
R.11.2.1.1 System Health

Figure 26. System Health Requirements Hierarchy Diagram
hier System Health
R.11.2.1.1
System Health
Requirement
refined by
R.11.2.1.1.1
refined by
R.11.2.1.1.2
verified by
Mobile Element
System Health
Stationary
Element System...
Demonstration
Requirement
Requirement
VerificationRequ...
verified by
verified by
Demonstration
Demonstration
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015

The system shall be capable of continuously monitoring system health of critical
subsystems.
R.11.2.1.1.1 Mobile Element System Health
R.11.2.1.1.2 Stationary Element System Health
36
R.11.2.1.2 Self-Test & Fault Notification
Figure 27. Self-Test & Fault Notification Requirements Hierarchy Diagram

hier Self Test & Fault Notification
R.11.2.1.2
Self Test & Fault
Notification
Requirement
refined by
R.11.2.1.2.1
refined by
R.11.2.1.2.2
verified by
Mobile Element
Self-Test
Stationary
Element Self-Test
Demonstration
Requirement
Requirement
VerificationRequ...
refined by
R.11.2.1.2.1.1
verified by
refined by
R.11.2.1.2.2.1
verified by
Mobile Element
Self-Test Duration
Demonstration
Stationary
Element Self-Tes...
Demonstration
Requirement
VerificationRequ...
Requirement
VerificationRequ...
Date:
November 7, 2015

The system shall be capable self-testing non-critical subsystems.
R.11.2.1.2.1 Mobile Element Self-Test
R.11.2.1.2.2 Stationary Element Self-Test
37

Figure 28. Mobile Element Self-Test Requirements Hierarchy Diagram
hier Mobile Element Self-Test
R.11.2.1.2.1
Mobile Element
Self-Test
Requirement
refined by
R.11.2.1.2.1.1
verified by
Mobile Element
Self-Test Duration
Demonstration
Requirement
VerificationRequ...
verified by
Test
VerificationRequ...
Date:
November 7, 2...

Mobile elements shall perform a self-test upon initialization and upon request from
maintenance personnel.
R.11.2.1.2.1.1 Mobile Element Self-Test Duration
38

Figure 29. Stationary Element Self-Test Requirements Hierarchy Diagram
hier Stationary Element Self-Test
R.11.2.1.2.2
Stationary
Element Self-Test
Requirement
refined by
R.11.2.1.2.2.1
verified by
Stationary
Element Self-Tes...
Demonstration
Requirement
VerificationRequ...
verified by
verified by
Analysis
Demonstration
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015

Stationary system elements shall perform a self-test of non-critical subsystems
when requested by the user.
R.11.2.1.2.2.1 Stationary Element Self-Test Performance
39
Performance Requirements

Air Traffic Control shall be capable of initiating an emergency mode of operation
that removes all mobile units from airfield operating areas within 30 seconds.
R.1.1 Emergency
R.2.4 Power Failure
In the event of a power failure, the system must have the capability to
automatically power-up and operate in the condition and settings that were
available just prior to the power failure.
The system shall be capable of detecting FOD within 4 minutes of a FOD
occurrence.
40
R.3.2 FOD Detection

Figure 30. FOD Detection Requirements Hierarchy Diagram
hier FOD Detection
R.3.2
FOD Detection
Requirement
basis of
R.3.2.1
refined by
R.3.2.2
refined by
R.3.2.3
refined by
R.3.2.4
Detect FOD
Group Object
Detection
Metal Cylinder
Detection
Sphere Detection
Function
Requirement
Requirement
Requirement
verified by
verified by
verified by
refined by
R.3.2.5
refined by
Lighting
Conditions
Automated
Test
Requirement
Requirement
VerificationRequ...
verified by
verified by
Test
Test
Test
Test
Test
VerificationRequ...
VerificationRequ...
VerificationRequ...
VerificationRequ...
VerificationRequ...
verified by
Date:
November 7, 2015

The system shall be capable of detecting and reporting the location of single and
multiple FOD items on the AOA to the retrieval subsystem as well as airport
personal when FOD (such as animal carcasses) are unsuitable for retrieval.
R.3.2.1 Group Object Detection
R.3.2.2 Metal Cylinder Detection
R.3.2.3 Sphere Detection
R.3.2.4 Lighting Conditions
R.3.2.5 Automated Retrieval Suitability
41

The system shall have the ability to detect 90 percent of the following group of
objects when placed within a 100 ft. by 100 ft. (30 m by 30 m) square in the
desired coverage area. One item from each category must be included in the
group and each item must measure no larger than 4 in (10 cm) in any dimension
unless otherwise specified: A chunk of asphalt or concrete, Any portion of a
runway light fixture (in-pavement or edge light), An adjustable crescent wrench
up to 8 in. (20 cm) in length), A deep socket (at least 2 in. (5 cm) in length), A
piece of rubber from an aircraft tire, A distorted metal strip (up to 8 in. (20 cm) in
length), Fuel cap (aircraft or automotive), Lug nut, Hydraulic line (from aircraft or
GSE, up to 8 in. (20 cm) in length).
R.3.2 FOD Detection
The system shall have the ability to detect an unpainted, metal cylinder,
measuring 1.2 in (3.1 cm) high and 1.5 in (3.8 cm) in diameter.
R.3.2 FOD Detection
42

The system shall have the ability to detect a white, grey, or black sphere,
measuring 1.7 in (4.3 cm) in diameter.
R.3.2 FOD Detection
The system shall demonstrate detection performance during daylight, nighttime,
and dawn/dusk operations.
R.3.2 FOD Detection
Location reporting methods that utilize an active method of reporting location
(such as a light beam) shall not interfere with or cause a distraction to normal
airport operations.
43

Location reporting methods that utilize a passive method of reporting, such as GPS
coordinates shall be accurate to within 16 ft. (5.0 m) of the actual FOD object
location.
Performance requirement derived from FAA AC 150/5220-24 Airport Foreign
The system shall be capable of notifying airport personnel of FOD unsuitable for
automated retrieval (such as animal carcasses) with GPS coordinates accurate to
within 16 ft. (5.0 m) of the actual FOD location.
R.5.2 FOD Weight
The system shall be capable of retrieving FOD weighing up to 1 pound or
.45359237 kilograms
R.5 FOD Retrieval
44
The FOD retrieval subsystem shall be capable of retrieving FOD with dimensions of
up to 12 inches in length 12 Inches in width and 12 inches in height.
R.5 FOD Retrieval
The system shall be capable of detecting, anticipating movement and avoiding
all airport traffic without input from air traffic control.
Mobile system elements shall maintain a minimum of ten feet (3.05 meters)
separation from all obstacles.
Mobile system elements shall maintain a minimum of fifty feet (15.24 meter)
separation from all aircraft.
45
separation from all personnel.
Mobile system elements shall maintain a minimum 25 feet (7.6 meter) separation
from all support vehicles.
The system shall be capable of receiving and transmitting data to air traffic control
without causing any interference to existing systems.
The system shall be capable of receiving and transmitting data to airport
managers without causing any interference to existing systems.
46
The system shall be capable of receiving and transmitting data to maintenance
personnel without causing any interference to existing systems.
The system should have an Operational Availability (AO) of 99.9%
Figure 31. System Health and Fault Notification Requirements Hierarchy Diagram
hier System Health and Fault Notification
R.11.2.1
System Health
Requirement
refined by
R.11.2.1.1
refined by
R.11.2.1.1.1
refined by
R.11.2.1.2
verified by
System Health
Self Test & Fault

Notification
Test
Requirement
Requirement
VerificationRequ...
refined by
R.11.2.1.1.2
verified by
refined by
R.11.2.1.2.1
refined by
R.11.2.1.2.2
verified by
Mobile Element
System Health
Stationary
Element System...
Demonstration
Mobile Element
Self-Test
Stationary
Element Self-Test
Demonstration
Requirement
Requirement
VerificationRequ...
Requirement
Requirement
VerificationRequ...
Date:
November 7, 2015
47
The system shall be capable of automatically detecting faults in critical
subsystems and providing users with data regarding faults in non-critical
subsystems.
Mobile subsystems shall be capable of continuously monitoring the health of
critical subsystems and compensating for faults in critical subsystems until they
can exit the airport operating area.
Stationary elements shall employ a method of monitoring system health of critical
subsystems and employ a method of notifying users when faults are detected.
The self-test duration on mobile system elements should not exceed 30 seconds.
48
When stationary elements are asked to perform a self-test, the self-test shall not
interfere with the systems ability to operate safely; if the self-test takes a FOD
detection element off line it shall be capable of recovering in no longer than 60
seconds.
49
The system shall be capable of detecting objects under rainfall conditions having
a specific intensity, duration, and frequency for a two-year category of storm in
the local region (as specified in CLIM 20, Climatology of the United States No. 20).
The system shall be capable of detecting objects under snow conditions having a
specific intensity, duration, and frequency for a two-year category of storm in the
local region (as specified in CLIM 20, Climatology of the United States No. 20).
The system shall be capable of operating in wind conditions up to 50 MPH with
gusts up to 70MPH.
50
Programmatic Requirements
R.9.1.1 Maintenance Procedures
Figure 32. Maintenance Procedures Requirements Hierarchy Diagram

hier Maintenance Procedures
R.9.1
Maintenance
Procedures
Requirement
R.9.1.1
refined by
R.9.1.2
refined by
R.9.1.3
refined by
R.9.1.4
refined by
verified by
Cleaning
Procedures
Preventative
Maintenance Pr...
Recalibration Plan
Scheduled
Component Re...
Analysis
Requirement
Requirement
Requirement
Requirement
VerificationRequ...
verified by
verified by
verified by
verified by
Analysis
Analysis
Analysis
Analysis
VerificationRequ...
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
Programmatic Requirement Statement:

An operators handbook, illustrated parts breakdown and preventive
maintenance schedule shall be developed and included with the system.
R.9.1.1 Cleaning Procedures
R.9.1.2 Preventative Maintenance Procedures
R.9.1.3 Recalibration Plan
R.9.1.4 Scheduled Component Removals
51

Written documentation on recommended cleaning procedures, including solvent
types and tools shall be developed.
Written documentation on recommended preventive maintenance actions shall
be developed.
Written calibration and recalibration procedures shall be developed so that FOD
detection and retrieval programmatic specifications can be maintained for the life
of system.
Written documentation on scheduled component removal timelines shall be
developed.
52
R.9.2 Call Center

A call center shall provide 24/7 technical support.
Equipment located outside of paved surfaces shall be designed and built so
maintenance personnel can have access.
53
Design Constraints
Design Constraint Statement:
Mobile system elements shall be capable of operating on the AOA at a speed of
no less than 20 mph (30 km/h).
This constraint originated from FAA AC 150/5220-24 Airport Foreign Object Debris
(FOD) Detection Equipment.
Data systems shall have the capability to retain the data for at least two years
after the detection event.
54
Design Constraints

Figure 33. Elements Located Near the Runway Requirements Hierarchy Diagram
hier Elements Located Near The Runway
R.10.1
Elements Located
Near The Runway
Requirement
R.10.1.1
refined by
R.10.1.2
refined by
R.10.1.3
refined by
R.10.1.4
refined by
verified by
Breakaway
Connector
Element Height
Frangible Coupling
Wind Loading
Inspection
Requirement
Requirement
Requirement
Requirement
VerificationRequ...
verified by
verified by
verified by
verified by
Inspection
Inspection
Inspection
Inspection
VerificationRequ...
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015

Sensors located near the runway shall comply with applicable FAA regulations.
R.10.1.1 Breakaway Connector
R.10.1.2 Element Height
R.10.1.3 Frangible Coupling
R.10.1.4 Wind Loading
55
Design Constraints

Elements located near the runway and within the runway safety area shall be
connected through a connector that will disconnect upon sensor impact.
AC 150/5345-46, Specification for Runway and Taxiway Light Fixtures
The height of the sensors located near the runway and within the runway safety
area shall be no more than 30 in (0.76 m).
AC 150/5340-30, Design and Installation Details for Airport Visual Aids
mounted on a frangible coupling.
56
Design Constraints

Elements located near the runway shall withstand a wind loading of 300 mph. (483
km/h)
57
AFDIRTS Functional Architecture

Table 1. Functional Traceability Matrix
Function
Based on
F. Perform AFDIRTS Functions
R Need Statement
F.1 Command and Control System
F.1.1 Interface with ATC

F.1.2 Initiate System Modes
F.1.3 Transmit Normal Operation
R.2.5 Navigation Modes
Command
F.1.4 Transmit Emergency Command
F.1.5 Determine Location, Trajectory and
Speed of Inbound Aircraft.

F.1.6 Transmit Inbound Aircraft Data to
R.2.4 Navigation Data
System Elements
F.1.7 Interface with Airport Managers

R.9.2 Airport Management
Communication
F.1.8 Interface with Maintenance
Personnel
F.1.8.1 Initiate Self-Test
R.13.2.3 Maintainer Self-Test
F.1.8.2 Display Maintenance Data
F.1.9 Restore System
R.2.3 Power Failure
F.2 Operate Safely
R.1 Safe Operation
58

Function
Based on
F.2.1 Perform Self-Test Upon Initialization
R.1.2 System Health Requirement

R.13.2.1 Self-Test
R.13.2.1.1 Self-Test Duration
F.2.2 Monitor the Health of Stationary
R.1.2 System Health
Element Critical Subsystems

F.2.3 Monitor the Health of Mobile
R.1.2 System Health

F.2.4 Compensate for Failures in Mobile
R.1.2.1 Failure Compensation
Unit Critical Subsystems

F.2.5 Provide Airport Managers with
R.1.2 System Health
System Health Data

F.2.6 Provide ATC with System Health
R.1.2 System Health
Data
F.2.7 Provide Maintenance Personnel
R.1.2 System Health
with System Health Data

F.3 Scan Airfield for FOD
R.3 FOD Search
F.3.1 Detect FOD
R.3.1 Detection Time

R.3.2 FOD Detection
F.3.2 Determine FOD Suitability from a
Distance

R.5.3 FOD location
F.3.3 Determine Location of FOD

59

Function
Based on
F.3.4 Process Suitability and Location of
R.4 FOD Reporting Requirement
FOD
F.4 Retrieve FOD
R.5 FOD Retrieval Requirement

R.5.2 FOD Weight
F.4.1 Determine FOD Dimensions
F.4.2 Notify Personnel of Object too
R.5.3 FOD location
Large for Retrieval

F.4.3 Grasp FOD
R.5.5 FOD Grasping
F.4.4 Determine FOD weight
F.4.5 Notify Personnel of Overweight
Objects
R.5.3 FOD location
F.4.6 Transport FOD to Disposal Area
R.5 FOD Retrieval
F.4.7 Release FOD
R.5.5 FOD Grasping
F.5 Navigate Airfield
R.7 Mobile Unit Navigation
F.5.1 Process Navigation Commands
R.7.4 Navigation Commands
F.5.2 Navigate to Emergency Standby
R.1.1 Emergency
Location

R.7.2 Emergency Posture
F.5.3 Navigate to FOD Location
R.7.3 FOD Location
F.5.4 Navigate to Disposal Area
R.7.5 Disposal Area
F.5.5 Detect Obstacles
F.5.6 Receive Aircraft Trajectory Data
R.7.1.2 Separation from Aircraft

60

Function
Based on
F.5.7 Anticipate Obstacle Movement
F.5.8 Avoid Obstacles

R.7.1.1 Separation from Obstacles
R.7.1.3 Separation from Personnel
R.7.1.4 Separation from Vehicles
F.5.9 Determine Location
F.5.10 Control Motion
F.6 Locomote System Elements
F.6.1 Facilitate Power
F.6.2 Facilitate Movement
F.6.2.1 Facilitate Directional Control
F.6.2.2 Facilitate Motion
F.6.2.3 Facilitate Braking
F.7 Maintain System
F.7.1 Accept Parts
F.7.2 Accept Materials
F.7.3 Accept SW Updates
F.7.4 Eject Materials
F.7.5 Eject Parts
F.8 Provide Power
R.12 System Power
F.8.1 Accept External Power
R.12 System Power
F.8.2 Detect External Power Failure
R.12.1 Loss of External Power
F.8.3 Generate Emergency Power
R.12.2 Back-Up Power
F.8.4 Transfer Power
R.12 System Power
F.9 Analyze FOD Trends
61

Function
Based on
F.9.1 Accept FOD alert time and date,
R.8.1 Types of Data
location coordinates and FOD image

data
F.9.2 Perform Trend Analysis
F.9.3 Retain Data

F.9.4 Export FOD Reports
62
F. AFDIRTS System
Figure 34. F. AFDIRTS N2 Diagram
n2 Perform AFDIRTS Functions
(Ext) Aircraft
Radar Data ...
(Ext) ATC ...
(Ext) Maint...
(Ext) FOD
Identification
from FOD
(Ext) FOD L...
(Ext) FOD
Identificatio...
(Ext) FOD L...
At FOD Loca...
(Ext) Aircraf...
(Ext) Obsta...
(Ext) Obsta...
Location Da...
(Ext)
Materials fr...
(Ext) Parts ...
(Ext) SW U...
(Ext)
Electrical
Energy from
Power
At FOD
Location
Signal (S)
F.1
System Context
System
Health (D)
Emergency...
Fault Codes...
System Hea...
System Hea...
Inbound
Aircraft Data
from Comm...
Navigation ...
Command and
Control System
F.2
Operate Safely
System Context
Unsuitable
FOD Location
Data
F.3
Scan Airfield for
FOD
System Context
Unsuitable
FOD (D)
Unsuitable
FOD Locatio...
FOD Location
Data to
Mobile Units
FOD
Characteristic
s (D)
Suitablity D...
FOD Charac...
Fod Illumina...
Suitablity D...
Unsuitable ...
Navigation
Modes (D)
FOD too
Large (S)
FOD too
Large (S)
Unsuitable
FOD Locatio...
FOD
Coordinates
Aircraft
Illumination ...
FOD Coordi...
Obstacle Ill...
F.4
Retrieve FOD
System Context
F.5
Navigate Airfield
System Context
Movement
Command to
Locomote
System Ele...
F.6
Heat to
Environment
Resistance t...
Sound to En...
Locomote System
Elements
System Context
F.7
Materials to
Maintainer
Parts to
Maintainer
Maintain System
System Context
Power Failure
Signal from
Power (S)
transferred...
transferred
Power (E)
transferred
Power (E)
transferred
Power (E)
transferred
Power (E)
transferred
Power (E)
transferred
Power (E)
F.8
transferred
Power (E)
Provide Power
System Context
F.9
Analyze FOD
Trends
Reports to
Airport
Managers (E)
System Context
Date:
November 18, 2015
63

Based On:
Figure 35. F.1 Command and Control (N2 Diagram)
n2 Command and Control System
(Ext) ATC
Command
from ATC
System Hea...
Emergency
Operation
Command (S)
System
Health (D)
Unsuitable
FOD Locatio...
(Ext) Aircraft
Radar Data
from ATC
(Ext)
Maintenance
Commands ...
System Hea...
Power Failure
Signal from
Power (S)
F.1.1
Interface with
ATC
System Context
System
Health to
ATC (E)
Command
Signal (S)
F.1.2
Initiate System
Modes
System Context
Normal
Operation
Command (S)
Emergency
Operation
Command (S)
F.1.3
Transmit Normal
Operation
Command
System Context
Navigation
Modes (D)
F.1.4
Transmit
Emergency
Command
System Context
Navigation
Modes (D)
F.1.5
Determine
Location,
Trajectory and
Speed of Inbou...
System Context
Aircraft
Location (D)
F.1.6
Inbound
Aircraft Data
from
Command a...
Transmit Inbound
Aircraft Data to
System Elements
System Context
F.1.7
System
Health to
Airport Man...
Unsuitable ...
Interface with
Airport Managers
System Context
F.1.8
System
Health Data
to Maintainer
(E)
Interface with
Maintenance
Personnel
System Context
System
Resume
Signal (S)
System
Resume
Signal (S)
System
Resume
Signal (S)
System
Resume
Signal (S)
System
Resume
Signal (S)
F.1.9
Restore System
System Context
Date:
November 17, 2015
64

Figure 36. F.1 Command and Control (Enhanced FFBD)
effbd Command and Control System
F.1.3
Normal Operation
Command (S)
System Health to ATC (E)
Transmit Normal
Operation Command
(Ext) ATC
Command from
ATC
F.1.1
Command
Signal (S)
Interface with ATC
Navigation Modes (D)
F.1.2
System Context
Initiate System Modes
OR
OR
F.1.4
(Ext) Aircraft
Radar Data from
ATC
Transmit Emergency Command

Emergency
Operation
Command (S)
Aircraft Location
(D)
F.1.5
System Health (D)
Inbound Aircraft Data from

Command and Control (D)
System Context
System Context
System Context
Unsuitable FOD Data to

Airport Managers
F.1.6
Determine Location,
Trajectory and Speed of
Inbound Aircraft.
Transmit Inbound Aircraft Data

to System Elements
System Context
System Context
System Health to Airport

Managers (E)
AND
AND
Unsuitable FOD
Location Data
F.1.7
System Health Data to
Maintainer (E)
Interface with Airport

Managers
(Ext) Maintenance
Commands from
Maintainer
System Context
F.1.8
Interface with
Maintenance Personnel
System Context
Ref.
OR
OR
Ref.
F.1.9
Restore System
System Context
Power Failure Signal
from Power (S)
System Resume
Signal (S)
Date:
November 17, 2015
65

Based On:
Table 2. F.1.1 Interface with ATC Interfacing Items
Interfacing Items
(Ext) ATC Command from ATC
Source / Destination
Input To:
F Perform AFDIRTS Functions
Output From:
(External) ATC IOs
Command Signal
Input To:
Output From:
System Health
Input To:
Personnel
Output From:
F.2 Operate Safely
System Health Data
Data
System Health to ATC
Output From:
66

Based On:
Table 3. F.1.2 Initiate System Modes Interfacing Items
Interfacing Items
Command Signal
Input To:
Output From:
Emergency Operation Command
Input To:
Output From:
Normal Operation Command
Input To:
Command
Output From:
System Resume Signal
Input To:
System Elements
Personnel
Output From:
67
F.1.3 Transmit Normal Operation Command

Based On:
Table 4. F.1.3 Transmit Normal Operation Command Interfacing Items
Interfacing Items
Input To:
Output From:
Command
F.4 Retrieve FOD
Normal Operation Command (S)
Input To:
Command
Output From:
68

Based On:
Table 5. F.1.4 Transmit Emergency Command Interfacing Items
Interfacing Items
Emergency Operation Command (S)
Input To:
Output From:
Input To:
Output From:
Command
F.4 Retrieve FOD
F.1.5 Determine Location, Trajectory and Speed of Inbound Aircraft.

Based On:
Table 6. F.1.5 Determine Location, Trajectory and Speed of Inbound Aircraft
Interfacing Items
Interfacing Items
(Ext) Aircraft Radar Data from ATC
Input To:
69

Output From:
(External) Aircraft Operators IOs
Input To:
System Elements
Output From:
System Resume Signal (S)
Input To:
System Elements
Personnel
Output From:
F.1.6 Transmit Inbound Aircraft Data to System Elements

Based On:
Table 7. F.1.6 Transmit Inbound Aircraft Data to System Elements Interfacing Items
Interfacing Items
Input To:
System Elements
Output From:
Inbound Aircraft Data from Command

and Control (D)
Input To:
70

Interfacing Items
Output From:
System Elements
Input To:
System Elements
Personnel
Output From:

Based On:
Table 8. F.1.7 Interface with Airport Managers Interfacing Items
Interfacing Items
System Health (D)
Input To:
Personnel
Output From:
F.2 Operate Safely
System Health Data
71

Interfacing Items
Data
System Health to Airport Managers (E)
Output From:
Input To:
System Elements
Personnel
Output From:
Unsuitable FOD Data to Airport Managers
Output From:
Unsuitable FOD Location Data
Input To:
Output From:
FOD
F.4 Retrieve FOD
Large for Retrieval
Objects
72

F.1.8 Interface with Maintenance Personnel
Based On:
Table 9. F.1.8 Interface with Maintenance Personnel Interfacing Items
Interfacing Items
(Ext) Maintenance Commands from
Maintainer
Input To:
Personnel
Output From:
(External) Maintainer IOs
System Health (D)
Input To:
Personnel
Output From:
F.2 Operate Safely
System Health Data
Data
System Health Data to Maintainer (E)
Output From:
Personnel
Input To:
73

Interfacing Items
System Elements
Personnel
Output From:
Figure 37. F.1.8 Interface with Maintenance Personnel (Enhanced FFBD)

effbd Interface with Maintenance Personnel
(Ext)
Maintenance
Commands
from Maintainer
Ref.
System Health
Data to Maintainer
(E)
System
Health (D)
F.1.8.1
F.1.8.2
Display Maintenance
Data
Initiate Self-Test
System Context
System Context
Fault Codes to Maintainer
Fault Codes (D)
Ref.
Date:
November 17, 2015
74

Figure 38. F.1.8 Interface with Maintenance Personnel (N2 Diagram)
n2 Interface with Maintenance Personnel
(Ext)
Maintenance
Commands
from Mainta...
System
Health (D)
F.1.8.1
Initiate Self-Test
System Context
Fault Codes
(D)
F.1.8.2
Display
Maintenance Data
System Context
Fault Codes
to Maintainer
System
Health Data...
Date:
November 17, 2015

Based On:
Table 10. F.1.8.1 Initiate Self-Test Interfacing Items
Interfacing Items
Maintainer
Input To:
Personnel
Output From:
Fault Codes (D)
Input To:
Output From:
75

Based On:
Table 11. F.1.8.2 Display Maintenance Data Interfacing Items
Interfacing Items
Fault Codes (D)
Input To:
Output From:
Output From:
System Health (D)
Input To:
Personnel
Output From:
F.2 Operate Safely
System Health Data
Data
Output From:
Personnel
76

Based On:
R.2.3 Power Failure
Table 12. F.1.9 Restore System Interfacing Items
Interfacing Items
Power Failure Signal from Power (S)
Input To:
Output From:
F.8 Provide Power
Input To:
System Elements
Personnel
Output From:
77
F.2 Operate Safely

Based On:
R.1 Safe Operation
Table 13. F.2 Operate Safely Interfacing Items
Interfacing Items
System Health (D)
Input To:
Personnel
Output From:
F.2 Operate Safely
System Health Data
Data
Transferred Power (E)
Input To:
F.2 Operate Safely
F.4 Retrieve FOD
F.7 Maintain System
Output From:
F.8 Provide Power
78
Figure 39. F.2 Operate Safely (Enhanced FFBD)

effbd Operate Safely
Critical Subsystem
Telemetry Data from
Stationary Elements
F.2.5
Fault Data (D)
F.2.2
System
Initialization
Monitor the Health of

Stationary Element
Critical Subsystems
F.2.1
Ref.
Perform Self Test

Upon Initialization
System Context
AND
System Health (D)
Provide Airport Managers

System Context
F.2.6
Critical
Subsystem
Degraded Signal
F.2.3
AND
Provide ATC with System

Health Data
OR
F.2.4
OR
Ref.
System Context
System Context
Mobile Element
Critical Subsystems
Compensate for
Failures in Mobile Unit
Critical Subsystems
System Context
System Context
F.2.7
Provide Maintenance
Personnel with System
Health Data
System Context
Critical Subsystem
Telemetry Data From
Mobile Elements
Self-Test Results
(D)
Date:
November 17, 2015
79

Figure 40. F.2 Operate Safely (N2 Diagram)
n2 Operate Safely
System
Initialization
Critical
Subsystem
Telemetry
Data from S...
Critical
Subsystem
Telemetry
Data From ...
F.2.1
Perform Self Test
Upon Initialization
System Context
F.2.2
Monitor the
Health of
Stationary
Element Critical ...
System Context
F.2.3
Monitor the
Health of Mobile
Element Critical
Subsystems
System Context
Self-Test
Results (D)
Self-Test
Results (D)
Self-Test
Results (D)
Fault Data (D)
Fault Data (D)
Fault Data (D)
Fault Data (D)
Fault Data (D)
Fault Data (D)
Critical
Subsystem
Degraded
Signal
F.2.4
Compensate for
Failures in Mobile
Unit Critical
Subsystems
System Context
F.2.5
Provide Airport
Managers with
System Health
Data
System Context
System
Health (D)
F.2.6
Provide ATC with
System Health
Data
System Context
Date:
System
Health (D)
F.2.7
Provide
Maintenance
Personnel with
System Health ...
System Context
System
Health (D)
November 17, 2015
80

Based On:
R.1.2 System Health
R.13.2.1 Self-Test
Table 14. F.2.1 Perform Self-Test Upon Initialization Interfacing Items
Interfacing Items
Self-Test Results (D)
Input To:
System Health Data
Data
Output From:
System Initialization
Input To:
F.2.2 Monitor the Health of Stationary Element Critical Subsystems

Based On:
R.1.2 System Health
Table 15. F.2.2 Monitor the Health of Stationary Element Critical Subsystems Interfacing
Items
Interfacing Items
Critical Subsystem Telemetry Data from

Stationary Elements
Input To:
Fault Data (D)
Input To:
System Health Data
Data
81

Table 15. F.2.2 Monitor the Health of Stationary Element Critical Subsystems Interfacing
Items
Interfacing Items
Output From:
F.2.3 Monitor the Health of Mobile Element Critical Subsystems

Based On:
R.1.2 System Health
Table 16. F.2.3 Monitor the Health of Mobile Element Critical Subsystems Interfacing
Items
Interfacing Items
Critical Subsystem Degraded Signal
Input To:
Output From:
Critical Subsystem Telemetry Data From

Mobile Elements
Input To:
82

F.2.4 Compensate for Failures in Mobile Unit Critical Subsystems
Based On:
Table 17. F.2.4 Compensate for Failures in Mobile Unit Critical Subsystems Interfacing
Items
Interfacing Items
Input To:
Output From:
Fault Data (D)
Input To:
System Health Data
Data
Output From:
F.2.5 Provide Airport Managers with System Health Data

Based On:
R.1.2 System Health
Table 18. F.2.5 Provide Airport Managers with System Health Data Interfacing Items
Interfacing Items
Fault Data (D)
Input To:
System Health Data
83

Interfacing Items
Data
Output From:
Input To:
System Health Data
Data
Output From:
System Health (D)
Input To:
Personnel
Output From:
F.2 Operate Safely
System Health Data
Data
84
F.2.6 Provide ATC with System Health Data

Based On:
R.1.2 System Health
Table 19. F.2.6 Provide ATC with System Health Data Interfacing Items
Interfacing Items
Fault Data (D)
Input To:
System Health Data
Data
Output From:
Input To:
System Health Data
Data
Output From:
System Health (D)
Input To:
Personnel
Output From:
F.2 Operate Safely
85

Interfacing Items
System Health Data
Data
F.2.7 Provide Maintenance Personnel with System Health Data

Based On:
R.1.2 System Health
Table 20. F.2.7 Provide Maintenance Personnel with System Health Data Interfacing
Items
Interfacing Items
Fault Data (D)
Input To:
System Health Data
Data
Output From:
Input To:
System Health Data
Data
Output From:
86

Table 20. F.2.7 Provide Maintenance Personnel with System Health Data Interfacing
Items
Interfacing Items
System Health (D)
Input To:
Personnel
Output From:
F.2 Operate Safely
System Health Data
Data
87

Based On:
R.3 FOD Search
Table 21. F.3 Scan Airfield for FOD Interfacing Items
Interfacing Items
(Ext) FOD Identification from FOD
Input To:
F.3.1 Detect FOD
F.4 Retrieve FOD
Output From:
(External) FOD IOs
(Ext) FOD Location from FOD
Input To:
F.4 Retrieve FOD
Large for Retrieval
F.4.3 Grasp FOD
Output From:
(External) FOD IOs
FOD Characteristics (D)
Input To:
Distance
data
Output From:
F.3.1 Detect FOD
FOD Illumination to FOD
Input To:
(External) FOD IOs
88

Interfacing Items
Output From:
FOD Location Data to Mobile Units
Input To:
Output From:
FOD
Suitability Data (D)
Input To:
FOD
data
Output From:
Distance
transferred Power (E)
Input To:
F.2 Operate Safely
F.4 Retrieve FOD
F.7 Maintain System
Output From:
F.8 Provide Power
Input To:
89

Interfacing Items
Output From:
FOD
F.4 Retrieve FOD
Large for Retrieval
Objects
90
Figure 41. F.3 Scan Airfield for FOD (Enhanced FFBD)
effbd Scan Airfield for FOD
FOD
Characteristics (D)
(Ext) FOD
Identification
from FOD
Suitablity Data (D)
F.3.1
Determine FOD
Suitability from a
Distance
Detect FOD
System Context
Ref.
Unsuitable FOD
Location Data
F.3.2
F.3.4
System Context
AND
AND
F.3.3
Process Suitability
and Location of FOD
Ref.
System Context
Determine Location of
FOD
System Context
FOD Location (D)
(Ext) FOD Location

from FOD
FOD Location Data to

Mobile Units
Fod Illumination to
FOD
Date:
November 18, 2015
91
Figure 42. F.3 Scan Airfield for FOD (N2 Diagram)

n2 Scan Airfield for FOD
(Ext) FOD
Identification
from FOD
FOD
Characteristic
s (D)
(Ext) FOD
Location from
FOD
Suitablity
Data (D)
F.3.1
Detect FOD
System Context
FOD
Characteristic
s (D)
FOD
Characteristic
s (D)
F.3.2
Determine FOD
Suitability from a
Distance
System Context
Suitablity
Data (D)
Suitablity
Data (D)
FOD Location
(D)
Fod
Illumination
to FOD
F.3.3
Determine
Location of FOD
System Context
F.3.4
Process
Suitability and
Location of FOD
System Context
Date:
FOD Location
Data to
Mobile Units
Unsuitable ...
November 18, 2015
F.3.1 Detect FOD

Based On:
R.3.2 FOD Detection
Table 22. F.3.1 Detect FOD Interfacing Items
Interfacing Items
Input To:
F.3.1 Detect FOD
92

Interfacing Items
F.4 Retrieve FOD
Output From:
(External) FOD IOs
Input To:
Distance
data
Output From:
F.3.1 Detect FOD
F.3.2 Determine FOD Suitability from a Distance

Based On:
Table 23. F.3.2 Determine FOD Suitability from a Distance Interfacing Items
Interfacing Items
Input To:
Distance
data
Output From:
F.3.1 Detect FOD
Input To:
FOD
93

Interfacing Items
data
Output From:
Distance

Based On:
Table 24. F.3.3 Determine Location of FOD Interfacing Items
Interfacing Items
Input To:
F.4 Retrieve FOD
Large for Retrieval
F.4.3 Grasp FOD
Output From:
(External) FOD IOs
Input To:
(External) FOD IOs
Output From:
FOD Location (D)
Input To:
FOD
Output From:
94

Interfacing Items
F.3.4 Process Suitability and Location of FOD

Based On:
R.4 FOD Reporting
Table 25. F.3.4 Process Suitability and Location of FOD Interfacing Items
Interfacing Items
FOD Location (D)
Input To:
FOD
Output From:
Input To:
Output From:
FOD
Input To:
FOD
data
Output From:
Distance
Input To:
95

Interfacing Items
Output From:
FOD
F.4 Retrieve FOD
Large for Retrieval
Objects
96
F.4 Retrieve FOD

Based On:
R.5 FOD Retrieval
R.5.2 FOD Weight
Table 26. F.4 Retrieve FOD Interfacing Items
Interfacing Items
Input To:
F.3.1 Detect FOD
F.4 Retrieve FOD
Output From:
(External) FOD IOs
Input To:
F.4 Retrieve FOD
Large for Retrieval
F.4.3 Grasp FOD
Output From:
(External) FOD IOs
At FOD Location Signal (S)
Input To:
F.4 Retrieve FOD
data
Output From:
FOD too Large (S)
Input To:
97

Interfacing Items
Large for Retrieval
data
Output From:
F.4 Retrieve FOD
Input To:
Output From:
Command
F.4 Retrieve FOD
Input To:
F.2 Operate Safely
F.4 Retrieve FOD
F.7 Maintain System
Output From:
F.8 Provide Power
Unsuitable FOD (D)
Input To:
Output From:
F.4 Retrieve FOD
Input To:
98

Interfacing Items
Output From:
FOD
F.4 Retrieve FOD
Large for Retrieval
Objects
99
Figure 43. F.4 Retrieve FOD (Enhanced FFBD)

effbd Retrieve FOD
F.4.2
FOD too Large (S)
Unsuitable FOD
Location Data
At FOD Location
Signal (S)
Notify Personnel of Object

too Large for Retrieval
F.4.1
Ref.
Determine FOD
Dimensions
System Context
System Context
OR
OR
(Ext) FOD Location
from FOD
Notify Personnel of
Overweight Objects
F.4.4
F.4.3
(Ext) FOD
Identification from
FOD
Grasp FOD
Determine FOD
weight
System Context
System Context
FOD (M)
Grasped
FOD (F)
Ref.
F.4.5
Overweight
Signal
Navigation Modes
(D)
System Context
OR
OR
F.4.6
F.4.7
Transport FOD to
Disposal Area
Suitable for
Transport Signal
Release FOD
System Context
System Context
At Disposal Area Signal
Date:
November 18, 2015
100

Figure 44. F.4 Retrieve FOD (N2 Diagram)
n2 Retrieve FOD
(Ext) FOD
Identificatio...
At FOD Loca...
FOD (M)
(Ext) FOD
Location from
FOD
FOD too La...
(Ext) FOD
Location from
FOD
FOD too
Large (S)
FOD (M)
At Disposal
Area Signal
F.4.1
Determine FOD
Dimensions
System Context
F.4.2
Notify Personnel
of Object too
Large for
Retrieval
System Context
FOD (M)
FOD too
Large (S)
Unsuitable
FOD Location
Data
F.4.3
Grasp FOD
System Context
Grasped FOD
(F)
F.4.4
Determine FOD
weight
System Context
Overweight
Signal
Suitable for
Transport
Signal
F.4.5
Notify Personnel
of Overweight
Objects
System Context
Unsuitable
FOD Location
Data
F.4.6
Transport FOD to
Disposal Area
System Context
Navigation
Modes (D)
F.4.7
Release FOD
System Context
Date:
November 18, 2015

Based On:
101

Table 27. F.4.1 Determine FOD Dimensions Interfacing Items
Interfacing Items
Input To:
F.3.1 Detect FOD
F.4 Retrieve FOD
Output From:
(External) FOD IOs
Input To:
F.4 Retrieve FOD
data
Output From:
FOD (M)
Input To:
F.4.3 Grasp FOD
Output From:
FOD too Large (S)
Input To:
Large for Retrieval
data
Output From:
F.4 Retrieve FOD
102
F.4.2 Notify Personnel of Object too Large for Retrieval

Based On:
R.5.3 FOD location
Table 28. F.4.2 Notify Personnel of Object too Large for Retrieval Interfacing Items
Interfacing Items
Input To:
F.4 Retrieve FOD
Large for Retrieval
F.4.3 Grasp FOD
Output From:
(External) FOD IOs
FOD too Large (S)
Input To:
Large for Retrieval
data
Output From:
F.4 Retrieve FOD
Input To:
Output From:
FOD
F.4 Retrieve FOD
Large for Retrieval
103

Interfacing Items
Objects
F.4.3 Grasp FOD

Based On:
R.5.5 FOD Grasping
Table 29. F.4.3 Grasp FOD Interfacing Items
Interfacing Items
Input To:
F.4 Retrieve FOD
Large for Retrieval
F.4.3 Grasp FOD
Output From:
(External) FOD IOs
FOD (M)
Input To:
F.4.3 Grasp FOD
Output From:
Grasped FOD (F)
Input To:
Output From:
F.4.3 Grasp FOD
104

Based On:
Table 30. F.4.4 Determine FOD weight Interfacing Items
Interfacing Items
Grasped FOD (F)
Input To:
Output From:
F.4.3 Grasp FOD
Overweight Signal
Input To:
Objects
Output From:
Suitable for Transport Signal
Input To:
Output From:
Figure 45. F4.4 Determine FOD weight (Enhanced FFBD)

effbd Determine FOD weight
F.4.5
Notify Personnel
of Overweight ...
System Context
OR
F.4.3
F.4.6
Grasped
FOD (F)
Grasp FOD
Transport FOD to
Disposal Area
F.4.4
System Context
OR
Determine FOD
weight
System Context
OR
System Context
Ref.
Suitable for
Transport ...
Ref.
Overweight
Signal
Date:
November 18, 2015
105

Figure 46. F4.4 Determine FOD weight (N2 Diagram)
n2 Determine FOD weight
Grasped FOD
(F)
F.4.4
Determine FOD
weight
System Context
Overweight
Signal
Suitable for
Transport S...
University Edition - For Aca...
Date:
November ...
F.4.5 Notify Personnel of Overweight Objects

Based On:
R.5 FOD Retrieval
R.5.3 FOD location
Table 31. F.4.5 Notify Personnel of Overweight Objects Interfacing Items
Interfacing Items
Overweight Signal
Input To:
Objects
Output From:
Input To:
Output From:
FOD
F.4 Retrieve FOD
Large for Retrieval
Objects
106

Based On:
R.5 FOD Retrieval
Table 32. F.4.6 Transport FOD to Disposal Area Interfacing Items
Interfacing Items
Input To:
Output From:
Command
F.4 Retrieve FOD
Input To:
Output From:
F.4.7 Release FOD

Based On:
R.5.5 FOD Grasping
Table 33. F.4.7 Release FOD Interfacing Items
Interfacing Items
Input To:
F.4.7 Release FOD
Output From:
107

Based On:
Table 34. F.5 Navigate Airfield Interfacing Items
Interfacing Items
(Ext) Aircraft Location from Aircraft (E)
Input To:
(Ext) Obstacle Identification from

Obstacle
Input To:
Output From:
(External) Obstacles IOs
(Ext) Obstacle Location from Obstacle
Input To:
Output From:
Aircraft Illumination to Aircraft
Output From:
FOD Coordinates
Input To:
data
Output From:
Input To:
108

Interfacing Items
Output From:
FOD

and Control (D)
Input To:
Output From:
System Elements
Location Data from Environment
Input To:
Movement Command to Locomote

System Elements
Input To:
Output From:
Input To:
Output From:
Command
F.4 Retrieve FOD
109

Interfacing Items
Obstacle Illumination to Obstacle
Input To:
Output From:
Input To:
F.2 Operate Safely
F.4 Retrieve FOD
F.7 Maintain System
Output From:
F.8 Provide Power
110

Figure 47. F.5 Navigate Airfield (Enhanced FFBD)
effbd Navigate Airfield
F.5.2
Navigate to Emergency
Standby Location

Mobile Units
Standby
Emergency
Location
Coordinates
At Emergency
Location Signal
At Disposal Area
Signal
System Context
F.5.1
At FOD Location
Signal (S)
Obstacle Illumination
to Obstacle
F.5.3
FOD Coordinates
Process Navigation
Commands
(Ext) Obstacle
Location from
Obstacle
OR
Navigate to FOD Location
OR
System Context
System Context
Movement Command
to Locomote System
Elements
F.5.4
Navigation
Commands
(Ext) Obstacle
Identification from
Obstacle
Navigate to Disposal Area
Disposal Area
Coordinates
System Context
Obstacle Path
F.5.5
F.5.7
Detect Obstacles
System Context
Ref.
AND
AND
AND
F.5.6
(Ext) Aircraft
Location from
Aircraft (E)
Inbound Aircraft
Data from
Command and
Control (D)
Anticipate Obstacle
Movement
Avoid Obstacles
Obstacle
Characteristics
Ref.
System Context
Obstacle
Trajectory
System Context
F.5.9
Determine Location
Location Data from

Environment
Control Motion
AND
System Context
System Context
Receive Aircraft
Trajectory Data
F.5.10
F.5.8
Aircraft Illumination to
Aircraft
Coordinates (D)
System Context
Date:
November 18, 2015
111
Figure 48. F.5 Navigate Airfield (N2 Diagram)

n2 Navigate Airfield
(Ext)
Obstacle
Identificatio...
(Ext) Obsta...
FOD Location
Data to
Mobile Units
Navigation
Modes (D)
(Ext) Aircraft
Location from
Aircraft (E)
Inbound Air...
Location
Data from
Environment
FOD
Coordinates
F.5.1
Process
Navigation
Commands
System Context
Navigation
Commands
Navigation
Commands
Navigation
Commands
F.5.2
At
Emergency
Location Si...
Standby Em...
Navigate to
Emergency
Standby Location
System Context
F.5.3
Navigate to FOD
Location
System Context
System Context
At Disposal
Area Signal
Disposal Area
Coordinates
At Disposal
Area Signal
F.5.5
Detect Obstacles
System Context
Obstacle
Characteristic
s
Obstacle
Illumination
to Obstacle
Obstacle
Characteristic
s
Aircraft
Illumination
to Aircraft
F.5.6
Receive Aircraft
Trajectory Data
System Context
F.5.7
Anticipate
Obstacle
Movement
System Context
Obstacle
Trajectory
F.5.8
Avoid Obstacles
System Context
Coordinates
(D)
At FOD
Location
Signal (S)
FOD Coordi...
F.5.4
Navigate to
Disposal Area
Coordinates
(D)
At FOD
Location
Signal (S)
FOD Coordi...
Coordinates
(D)
Coordinates
(D)
Obstacle Path
F.5.9
Determine
Location
Coordinates
(D)
System Context
F.5.10
Control Motion
System Context
Date:
Movement
Command to
Locomote
System Ele...
November 18, 2015

Based On:
Table 35. F.5.1 Process Navigation Commands Interfacing Items
Interfacing Items
Navigation Commands
Input To:
112

Interfacing Items
Location
Output From:
Input To:
Output From:
Command
F.4 Retrieve FOD
F.5.2 Navigate to Emergency Standby Location

Based On:
R.1.1 Emergency
Table 36. F.5.2 Navigate to Emergency Standby Location Interfacing Items
Interfacing Items
At Emergency Location Signal
Input To:
Output From:
Location
Coordinates (D)
Input To:
Location
113

Interfacing Items
Output From:
Navigation Commands
Input To:
Location
Output From:
Standby Emergency Location

Coordinates
Input To:
Output From:
Location

Based On:
R.7.3 FOD Location
Table 37. F.5.3 Navigate to FOD Location Interfacing Items
Interfacing Items
Input To:
F.4 Retrieve FOD
data
Output From:
Coordinates (D)
Input To:
114

Interfacing Items
Location
Output From:
FOD Coordinates
Input To:
data
Output From:
Input To:
Output From:
FOD
Navigation Commands
Input To:
Location
Output From:
115

Based On:
R.7.5 Disposal Area
Table 38. F.5.4 Navigate to Disposal Area Interfacing Items
Interfacing Items
Input To:
F.4.7 Release FOD
Output From:
Coordinates (D)
Input To:
Location
Output From:
Disposal Area Coordinates
Input To:
Output From:
Navigation Commands
Input To:
Location
Output From:
116

Based On:
Table 39. F.5.5 Detect Obstacles Interfacing Items
Interfacing Items
Obstacle
Input To:
Output From:
Input To:
Output From:
Obstacle Characteristics
Input To:
Output From:
Input To:
Output From:
117

Based On:
Table 40. F.5.6 Receive Aircraft Trajectory Data Interfacing Items
Interfacing Items
Input To:
Output From:

and Control (D)
Input To:
Output From:
System Elements
Input To:
Output From:

Based On:
Table 41. F.5.7 Anticipate Obstacle Movement Interfacing Items
Interfacing Items
Input To:
118

Interfacing Items
Output From:
Obstacle Trajectory
Input To:
Output From:

Based On:
Table 42. F.5.8 Avoid Obstacles Interfacing Items
Interfacing Items
Coordinates (D)
Input To:
Location
Output From:
Obstacle Path
Input To:
Output From:
Obstacle Trajectory
Input To:
119

Interfacing Items
Output From:

Based On:
Table 43. F.5.9 Determine Location Interfacing Items
Interfacing Items
Coordinates (D)
Input To:
Location
Output From:
Input To:

Based On:
Table 44. F.5.10 Control Motion Interfacing Items
Interfacing Items
Input To:
F.4.7 Release FOD
120

Interfacing Items
Output From:
Input To:
Output From:
Location
Input To:
F.4 Retrieve FOD
data
Output From:
Coordinates (D)
Input To:
Location
Output From:
Input To:
Output From:
FOD Coordinates
Input To:
data
121

Interfacing Items
Output From:

System Elements
Input To:
Output From:
Obstacle Path
Input To:
Output From:

Coordinates
Input To:
Output From:
Location
122

Based On:
Table 45. F.6 Locomote System Elements Interfacing Items
Interfacing Items
Heat to Environment
Input To:
(External) Environment IOs
Output From:

System Elements
Input To:
Output From:
Resistance to Environment
Input To:
Output From:
Sound to Environment
Input To:
Output From:
123

Interfacing Items
Input To:
F.2 Operate Safely
F.4 Retrieve FOD
F.7 Maintain System
Output From:
F.8 Provide Power
Figure 49. F.6 Locomote System Elements (Enhanced FFBD)

effbd Locomote System Elements
Mobile Unit
Energy Source
Mobile Unit
Power
F.6.1
Facilitate Power
System Context
Ref.
AND
Ref.
AND
F.6.2
Facilitate
Movement
System Context
Movement
Command to
Locomote System
Elements
Heat to
Environment
Date:
November 18, 2015
124

Figure 50. Locomote System Elements (N2 Diagram)
n2 Locomote System Elements
Mobile Unit
Energy
Source
Movement
Command to
Locomote
System Ele...
F.6.1
Facilitate Power
System Context
Mobile Unit
Power
F.6.2
Facilitate
Movement
System Context
Heat to
Environment
Resistance t...
Sound to En...
Date:
November 18, 2015

Based On:
Table 46. F.6.1 Facilitate Power Interfacing Items
Interfacing Items
Mobile Unit Energy Source
Input To:
Mobile Unit Power
Input To:
Output From:
125

Based On:
Table 47. F.6.2 Facilitate Movement Interfacing Items
Interfacing Items
Heat to Environment
Input To:
Output From:
Mobile Unit Power
Input To:
Output From:

System Elements
Input To:
Output From:
Input To:
Output From:
126

Interfacing Items
Input To:
Output From:
Figure 51. F.6.2 Facilitate Movement (Enhanced FFBD)

effbd Facilitate Movement
Movement Command
to Locomote System
Elements
Resistance to
Environment
F.6.2.1
Facilitate Directional
Control
F.6.2.3
System Context
Ref.
AND
Facilitate Braking
AND
Ref.
F.6.2.2
System Context
Facilitate Motion
Mobile Unit
Power
Heat to
Environment
System Context
Mobile Unit
Kinetic Energy
Sound to
Environment
Date:
November 18, 2015
127

Figure 52. Facilitate Movement (N2 Diagram)
n2 Facilitate Movement
Mobile Unit
Power
Movement
Command to...
Mobile Unit
Power
Movement
Command to...
Movement
Command to
Locomote
System Ele...
F.6.2.1
Facilitate
Directional Control
System Context
Mobile Unit
Kinetic Energy
Resistance to
Environment
Mobile Unit
Kinetic Energy
Sound to
Environment
F.6.2.2
Facilitate Motion
System Context
F.6.2.3
Facilitate Braking
Heat to
Environment
System Context
Date:
November 18, 2015

Based On:
Table 48. F.6.2.1 Facilitate Directional Control Interfacing Items
Interfacing Items
Mobile Unit Kinetic Energy
Input To:
Output From:
Mobile Unit Power
Input To:
Output From:
Input To:
128

Interfacing Items
System Elements
Output From:
Input To:
Output From:

Based On:
Table 49. F.6.2.2 Facilitate Motion Interfacing Items
Interfacing Items
Input To:
Output From:
Mobile Unit Power
Input To:
Output From:
129

Interfacing Items
System Elements
Input To:
Output From:
Input To:
Output From:

Based On:
Table 50. F.6.2.3 Facilitate Braking Interfacing Items
Interfacing Items
Heat to Environment
Input To:
Output From:
Input To:
Output From:
130

Interfacing Items

System Elements
Input To:
Output From:
131
F.7 Maintain System

Based On:
Table 51. F.7 Maintain System Interfacing Items
Interfacing Items
(Ext) Materials from Maintainer
Input To:
F.7 Maintain System
Output From:
(Ext) Parts from Maintainer
Input To:
F.7 Maintain System
F.7.1 Accept Parts
Output From:
(Ext) SW Update from Maintainer
Input To:
F.7 Maintain System
Output From:
Materials to Maintainer
Input To:
Output From:
F.7 Maintain System
Parts to Maintainer
Input To:
Output From:
F.7 Maintain System
F.7.5 Eject Parts
132

Interfacing Items
Input To:
F.2 Operate Safely
F.4 Retrieve FOD
F.7 Maintain System
Output From:
F.8 Provide Power
Figure 53. F.7 Maintain System (Enhanced FFBD)

effbd Maintain System
(Ext) Parts from
Maintainer
F.7.1
Accept Parts
System Context
(Ext) Materials
from Maintainer
F.7.2
Accept Materials
System Context
F.7.3
Ref.
AND
Accept SW
Updates
AND
Ref.
System Context
Materials to
Maintainer
F.7.4
(Ext) SW Update
from Maintainer
Eject Materials
System Context
Parts to Maintainer
F.7.5
Eject Parts
System Context
Date:
November 18, 2015
133

Figure 54. Maintain System (N2 Diagram)
n2 Maintain System
(Ext)
Materials
from
Maintainer
(Ext) Parts
from
Maintainer
(Ext) SW
Update from
Maintainer
F.7.1
Accept Parts
System Context
F.7.2
Accept Materials
System Context
F.7.3
Accept SW
Updates
System Context
F.7.4
Materials to
Maintainer
Eject Materials
System Context
F.7.5
Eject Parts
Parts to
Maintainer
System Context
Date:
November 18, 2015
F.7.1 Accept Parts

Based On:
Table 52. F.7.1 Accept Parts Interfacing Items
Interfacing Items
Input To:
F.7 Maintain System
F.7.1 Accept Parts
Output From:
134

Based On:
Table 53. F.7.2 Accept Materials Interfacing Items
Interfacing Items
Input To:
F.7 Maintain System
Output From:

Based On:
Table 54. F.7.3 Accept SW Updates Interfacing Items
Interfacing Items
Input To:
F.7 Maintain System
Output From:

Based On:
135

Table 55. F.7.4 Eject Materials Interfacing Items
Interfacing Items
Input To:
Output From:
F.7 Maintain System
F.7.5 Eject Parts

Based On:
Table 56. F.7.5 Eject Parts Interfacing Items
Interfacing Items
Parts to Maintainer
Input To:
Output From:
F.7 Maintain System
F.7.5 Eject Parts
136
F.8 Provide Power

Based On:
R.12 System Power
Table 57. F.8 Provide Power Interfacing Items
Interfacing Items
(Ext) Electrical Energy from Power
Input To:
F.8 Provide Power
Output From:
(External) Power IOs
Input To:
Output From:
F.8 Provide Power
Input To:
F.2 Operate Safely
F.4 Retrieve FOD
F.7 Maintain System
Output From:
F.8 Provide Power
137

Figure 55 F.8 Provide Power (Enhanced FFBD)
effbd Provide Power
Power (E)
F.8.1
(Ext) Electrical
Energy from
Power
Power Failure
Signal from
Power (S)
Accept External
Power
System Context
AND
AND
F.8.2
Detect External
Power Failure
F.8.4
System Context
Ref.
OR
OR
F.8.3
Transfer Power
Ref.
System Context
Generate
Emergency Power
transferred
Power (E)
System Context
Generator Power
Date:
November 18, 2015
Figure 56. Provide Power (N2 Diagram)

n2 Provide Power
(Ext)
Electrical
Energy from
Power
(Ext)
Electrical
Energy from
Power
F.8.1
Accept External
Power
System Context
Power (E)
F.8.2
Power Failure
Signal from
Power (S)
Detect External
Power Failure
System Context
F.8.3
Generate
Emergency Power
System Context
Generator
Power
F.8.4
Transfer Power
transferred
Power (E)
System Context
Date:
November 18, 2015
138

Based On:
R.12 System Power
Table 58. F.8.1 Accept External Power Interfacing Items
Interfacing Items
Input To:
F.8 Provide Power
Output From:
Power (E)
Input To:
Output From:

Based On:
Table 59. F.8.2 Detect External Power Failure Interfacing Items
Interfacing Items
Input To:
F.8 Provide Power
Output From:
Input To:
Output From:
139

Interfacing Items
F.8 Provide Power

Based On:
Table 60. F.8.3 Generate Emergency Power Interfacing Items
Interfacing Items
Generator Power
Input To:
Output From:

Based On:
R.12 System Power
Table 61. F.8.4 Transfer Power Interfacing Items
Interfacing Items
Generator Power
Input To:
Output From:
Power (E)
Input To:
Output From:
Input To:
140

Interfacing Items
F.2
F.3
F.4
F.5
F.6
F.7
F.9
Operate Safely
Scan Airfield for FOD
Retrieve FOD
Navigate Airfield
Locomote System Elements
Maintain System
Analyze FOD Trends
Output From:
F.8 Provide Power
141

Based On:
Table 62. F.9 Analyze FOD Trends Interfacing Items
Interfacing Items
Input To:
F.4 Retrieve FOD
data
Output From:
Input To:
Distance
data
Output From:
F.3.1 Detect FOD
FOD Coordinates
Input To:
data
Output From:
FOD too Large (S)
Input To:
142

Interfacing Items
Large for Retrieval
data
Output From:
F.4 Retrieve FOD
Reports to Airport Managers (E)
Input To:
(External) Airport Managers IOs
Output From:
Input To:
FOD
data
Output From:
Distance
Input To:
F.2 Operate Safely
F.4 Retrieve FOD
F.7 Maintain System
Output From:
F.8 Provide Power
143

Interfacing Items
144

Figure 57. F.9 Analyze FOD Trends (Enhanced FFBD)
effbd Analyze FOD Trends
At FOD Location
Signal (S)
FOD Trend Data

(D)
FOD Coordinates
F.9.1
Ref.
F.9.2
Accept FOD alert time and

date, location coordinates
and FOD image data
System Context
F.9.4
F.9.3
Perform Trend Analysis
Retain Data
System Context
System Context
Export FOD Reports
System Context
Suitablity Data (D)
FOD
Characteristics
(D)
Ref.
Reports to
Airport Managers
(E)
Raw FOD
Data
FOD too Large (S)
Date:
November 18, 2015
145

Figure 58. Analyze FOD Trends (N2 Diagram)
n2 Analyze FOD Trends
At FOD Loca...
FOD Charac...
FOD Coordi...
FOD too La...
F.9.1
Accept FOD alert
time and date,
location
coordinates and...
System Context
Raw FOD
Data
F.9.2
Perform Trend
Analysis
System Context
FOD Trend
Data (D)
FOD Trend
Data (D)
F.9.3
Retain Data
System Context
F.9.4
Reports to
Airport
Managers (E)
Export FOD
Reports
System Context
Date:
November 18, 2015
F.9.1 Accept FOD alert time and date, location coordinates and FOD image data
Based On:
R.8.1 Types of Data
Table 63. F.9.1 Accept FOD alert time and date, location coordinates and FOD image
data Interfacing Items
Interfacing Items
Input To:
F.4 Retrieve FOD
146

Interfacing Items
data
Output From:
Input To:
Distance
data
Output From:
F.3.1 Detect FOD
FOD Coordinates
Input To:
data
Output From:
FOD too Large (S)
Input To:
Large for Retrieval
data
Output From:
F.4 Retrieve FOD
Raw FOD Data
Input To:
Output From:
147

Interfacing Items
data
Input To:
FOD
data
Output From:
Distance

Based On:
Table 64. F.9.2 Perform Trend Analysis Interfacing Items
Interfacing Items
FOD Trend Data (D)
Input To:
F.9.3 Retain Data
Output From:
Raw FOD Data
Input To:
Output From:
data
148

F.9.3 Retain Data
Based On:
Table 65. F.9.3 Retain Data Interfacing Items
Interfacing Items
FOD Trend Data (D)
Input To:
F.9.3 Retain Data
Output From:

Based On:
Table 66. F.9.4 Export FOD Reports Interfacing Items
Interfacing Items
FOD Trend Data (D)
Input To:
F.9.3 Retain Data
Output From:
Input To:
Output From:
149
AFDIRTS Physical Architecture

Figure 59. COMP.1 Command and Control Segment Physical Tree
150

The Command and Control Segment of the AFDIRTS is made up of 7 Hardware
Configuration Items (HWCI) and 1 Software Configuration Item (SWCI) integrated to
perform function F.1 Command and Control the System. In addition to command and
control the Segment allows users to interface with the AFDIRTS.
151

Figure 61. COMP.1 Command and Control Segment Physical Block Diagram
ATC -> ARIU
pbd Command and Control Segment
COMP.3.1
IFerret TM &
AFDIRTS Interface
Unit
Maintenance IUser
Interface (MUI)
Airport Management
Display Unit (AMDU)
Subsystem
Subsystem
Subsystem
CPU <-> MUI
CPU <-> AMDU
ATC User Interface

(AUI)
HWCI
HWCI
COMP.1.5
ATC Radar Interface
Unit (ARIU)
Subsystem
COMP.1.6
(CCR) Command and
Control Radio
COMP.1.3
HWCI
Command and
Control Computer
(CCC)
CPU <-> CCR
HWCI
BACKUP CPU <-> CPU
Analysis Computer -> AMDU
NAV Radio
HWCI
CPU <-> AUI
COMP.6.1
COMP.4.2.5
Retrieval Telemetry
Radio
ARIU-> CPU
Command and Control Computer (CCC) -> IFerret TM & AFDIRTS Interface U...
COMP.1.1
COMP.1.7
COMP.4.4.1
Command and
Control Interface Unit
(CCIU)
Retrieval Telemetry Radio -> CCR
COMP.1.2
COMP.2.4
CCR -> NAV Radio
External System
CCIU -> COMMAND AND CONTROLl CPU
External System
AMDU -> AIRPORT MANAGERS
ATC -> AUI
AUI -> ATC
Airport Managers
MUI -> MAINTAINER
External System
Subsystem
ENV.3
Maintainer
CCR-> Airport Management Display Unit
ENV.6
Air Traffic Control
Iferret -> AMDU
ENV.1
COMP.1.4
Backup CPU
Analysis Computer
Subsystem
HWCI
Date:
December 4, 2015
Table 67. COMP.1 Command and Control Segment Functional Traceability Matrix
Number
Name
Type
Performs
COMP.1
Command and Control

Segment
Segment
Function F.1 Command

and Control System
COMP.1.1
Airport Management
Display Unit (AMDU)
Subsystem
Function F.1.7 Interface

with Airport Managers
COMP.1.2
ATC User Interface (AUI)
Subsystem

with ATC
152

Number
Name
Type
Performs
COMP.1.3
Command and Control

Computer (CCC)
HWCI
Function F.1.2 Initiate

System Modes
COMP.1.3.1
Command and Control OS
SWCI
COMP.1.4
Backup CPU
Subsystem
COMP.1.5
ATC Radar Interface Unit

(ARIU)
Subsystem
COMP.1.6
(CCR) Command and

Control Radio
HWCI
COMP.1.7
Maintenance User
Interface (MUI)
Subsystem
Function F.1.5 Determine

Location, Trajectory and
Function F.1.9 Restore
System
Function F.1.10 Receive
Location Trajectory and
Speed of Inbound Aircraft
Function F.1.3 Transmit
Normal Operation
Command
Emergency Command
Inbound Aircraft Data to
System Elements
Function Receive
Unsuitable FOD Data From
ARV
with Maintenance
Personnel
Function F.1.8.1 Initiate
Self-Test
Function F.1.8.2 Display
Maintenance Data
Table 68. COMP.1 Command and Control Segment Interface Description

Number
Name
Transfers
Connects to
L.1.1
AUI -> ATC
Item System
Health to ATC
Component
COMP.1.2 ATC User
Interface (AUI)
Component
ENV.1 Air Traffic
Control
153

Number
Name
Transfers
Connects to
L.1.2
ATC -> AUI
Item (Ext) ATC

Command from
ATC
Component
COMP.1.2 ATC User
Interface (AUI)
L.1.3
L.1.4
L.1.5
L.1.6
MUI -> MAINTAINER
AMDU -> AIRPORT

MANAGERS
Iferret -> AMDU
Command and
Control Computer
(CCC) -> IFerret TM
& AFDIRTS Interface
Unit
Item (Ext)
Maintenance
Commands from
Maintainer
Item System
Health Data to
Maintainer
Item System
Health to Airport
Managers
Item Unsuitable
FOD Data to Airport
Managers
Item FOD
Location
Item Unsuitable
FOD Location Data
Item Navigation
Modes
Component
ENV.1 Air Traffic
Control
Component
COMP.1.7
Maintenance User
Interface (MUI)
Component
ENV.6 Maintainer
Component
COMP.1.1 Airport
Management
Display Unit (AMDU)
Component
ENV.3 Airport
Managers
Component
COMP.1.1 Airport
Management
Display Unit (AMDU)
Component
COMP.3.1 IFerret
TM & AFDIRTS
Interface Unit
Component
COMP.1.3
Command and
Control Computer
(CCC)
Component
COMP.3.1 IFerret
TM & AFDIRTS
Interface Unit
154

Number
Name
Transfers
Connects to
L.1.7
ATC -> ARIU
Item (Ext)
Aircraft Radar Data
from ATC
Component
COMP.1.5 ATC
Radar Interface
Unit (ARIU)
L.1.8
L.1.9
L.1.10
CCIU ->
COMMAND AND
CONTROL CPU
ARIU-> CPU
CPU <-> MUI
Item Self-Test
Results
Item System
Health
Item Aircraft
Trajectory Data
Item
Maintenance
Commands
Item Self-Test
Results
Item System
Health Data to
Maintainer
Component
ENV.1 Air Traffic
Control
Component
COMP.1.3
Command and
Control Computer
(CCC)
Component
COMP.2.4
Command and
Control Interface
Unit (CCIU)
Component
COMP.1.3
Command and
Control Computer
(CCC)
Component
COMP.1.5 ATC
Radar Interface
Unit (ARIU)
Component
COMP.1.3
Command and
Control Computer
(CCC)
Component
COMP.1.7
Maintenance User
Interface (MUI)
155

Number
Name
Transfers
Connects to
L.1.11
CPU <-> AMDU
Item Self-Test
Results
Item System
Health to Airport
Managers
L.1.12
CPU <-> AUI
Item Command
Signal
Item Self-Test
Results
Item System
Health to ATC
Component
COMP.1.1 Airport
Management
Display Unit (AMDU)
Component
COMP.1.3
Command and
Control Computer
(CCC)
Component
COMP.1.2 ATC User
Interface (AUI)
L.1.13
L.1.14
Analysis Computer > AMDU
BACKUP CPU <->

CPU
Item Reports to
Airport Managers
Item CPU Data
Component
COMP.1.3
Command and
Control Computer
(CCC)
Component
COMP.1.1 Airport
Management
Display Unit (AMDU)
Component
COMP.6.1 Analysis
Computer
Component
COMP.1.3
Command and
Control Computer
(CCC)
Component
COMP.1.4 Backup
CPU
156

Number
Name
Transfers
Connects to
L.1.15
CPU <-> CCR
Item Aircraft
Trajectory Data
Item Emergency
Operation
Command
Item
Maintenance
Commands
Item Normal
Operation
Command
Item Unsuitable
FOD Location Data
Item Unsuitable
FOD Location Data
From ARV
Component
COMP.1.3
Command and
Control Computer
(CCC)
L.1.16
L.1.17
L.1.18
CCR-> Airport
Management
Display Unit
Retrieval Telemetry
Radio -> CCR
CCR -> NAV Radio
Item Unsuitable
FOD Location Data
Item Inbound
Aircraft Data to
ARV
Item Navigation
Modes
Component
COMP.1.6 (CCR)
Command and
Control Radio
Component
COMP.1.1 Airport
Management
Display Unit (AMDU)
Component
COMP.1.6 (CCR)
Command and
Control Radio
Component
COMP.1.6 (CCR)
Command and
Control Radio
Component
COMP.4.4.1
Retrieval Telemetry
Radio
Component
COMP.1.6 (CCR)
Command and
Control Radio
Component
COMP.4.2.5 NAV
Radio
157

come together to perform the Operate Safely Function. During this stage of system
satisfy requirement R.11.2.1.1 The system shall be capable of continuously monitoring
system health of critical subsystems therefore, COMP.2.3 and the identification of
critical components was reserved for the Engineering Development Stage.
Figure 62. COMP.2 System Health and Monitoring Segment Physical Tree
158

Figure 63. COMP.2 System Health and Monitoring Segment Physical Block Diagram
pbd System Health Monitoring Segment
COMP.1.3
Command and
Control Computer
(CCC)
HWCI
COMP.2.1
COMP.2.4
System Heath Radio

(SHR)
Command and Control

Interface Unit (CCIU)
HWCI
HWCI
SHR -> SHC
Critical Components -> SHR
SHC -> CCIU

COMP.2.2
System Health
Computer (SHC)
HWCI
SHC-> Critical Components

COMP.2.3
Components Defined
as "Critical" During
Advanced
Development
HWCI
Date:
December 4, 2015
159

Table 69. COMP.2 System Health and Monitoring Segment Functional Traceability
Matrix
Number
Name
Type
Performs
COMP.2
System Health
Monitoring
Segment
Segment
Function F.2
Operate Safely
COMP.2.1
System Heath
Radio (SHR)
HWCI
COMP.2.2
System Health
Computer (SHC)
HWCI
COMP.2.2.1
System Health
Software
SWCI
COMP.2.3
Components
Defined as "Critical"
During Advanced
Development
HWCI
COMP.2.4
Command and
Control Interface
Unit (CCIU)
HWCI
Function F.2.1
Receive Telemetry
Signal From
Stationary Elements
Function F.2.3
Receive Telemetry
Data from Mobile
Elements
Function F.2.2
Monitor the Health
of Stationary
Element Critical
Subsystems
Function F.2.4
Monitor the Health
of Mobile Element
Critical
Components
Function F.2.4.1
Direct SHC
operation
Function F.2.5
Compensate for
Failures in Mobile
Unit Critical
Components
Function F.2.6
Provide Airport
Managers with
System Health Data
Function F.2.7
Provide ATC with
System Health Data
Function F.2.8
Provide
Maintenance
160

Personnel with
System Health Data
Table 70. COMP.2 System Health and Monitoring Segment Interface Descriptions
Number
Name
L.2.1
Critical
Item Critical
Components -> SHR Subsystem
Telemetry Signal
From Mobile
Elements
Item Critical
Subsystem
Telemetry Signal
from Stationary
Elements
SHR -> SHC
Item Critical
Subsystem
Telemetry Data
From Mobile
Elements
Item Critical
Subsystem
Telemetry Data
from Stationary
Elements
SHC -> CCIU
Item Fault Data
L.2.2
L.2.3
Transfers
Connects to
Component
COMP.2.1 System
Heath Radio (SHR)
Component
COMP.2.3
Components
During Advanced
Development
Component
COMP.2.1 System
Heath Radio (SHR)
Component
COMP.2.2 System
Health Computer
(SHC)
Component
COMP.2.2 System
Health Computer
(SHC)
Component
COMP.2.4
161
L.2.4
SHC-> Critical
Components
Item Critical
Component
Degraded Signal
Command and
Control Interface
Unit (CCIU)
Component
COMP.2.2 System
Health Computer
(SHC)
Component
COMP.2.3
Components
During Advanced
Development
162

FOD Detection system. The Stratech Group, whom developed the IFerret will be
contracted to develop an Interface Unit that can transfer FOD information to the
AFDIRTS. This will be done during the Engineering Development Stage and will enable
automated FOD retrieval.
Figure 64. IFerretTM Detection System
163

Figure 65. COMP.3 FOD Detection Segment Physical Tree
Figure 66. COMP.3 FOD Detection Segment Physical Block Diagram

pbd Detection Segment
COMP.4
Air Retrieval Vehicle
(ARV) Segment
Segment
COMP.1.1
Airport Management
Display Unit (AMDU)
Subsystem
IFerret -> ARU

COMP.6.2
Iferret -> AMDU
Analysis Radio
HWCI
IFerret TM & AFDIRTS Interface Unit - > Analysis Radio

COMP.1.3
COMP.3.1
IFerret TM &
AFDIRTS Interface
Unit
Command and Control Computer (CCC) -> IFerret TM & AFDIRTS Interface Unit
Command and
Control Computer
(CCC)
HWCI
Subsystem
Date:
December 4, 2015
164

Table 71. COMP.3 FOD Detection Segment Functional Traceability Matrix
Number
Name
Type
Performs
COMP.3
Detection Segment
Segment
Function F.3 Scan

Airfield for FOD
COMP.3.1
IFerret TM & AFDIRTS

Interface Unit
Subsystem
Function F.3.1
Detect FOD
Function F.3.2
Determine FOD
Suitability from a
Distance
Function F.3.3
Determine Location
of FOD
Function F.3.4
Process Suitability
and Location of
FOD
Table 72. COMP.3 FOD Detection Segment Interface Descriptions

Number Name
Transfers
Connects to
L.3.1
Item FOD
Location Data to
Mobile Units
Component
COMP.3.1 IFerret
TM & AFDIRTS
Interface Unit
L.3.2
IFerret -> ARU
IFerret TM & AFDIRTS Interface

Unit - > Analysis Radio
Item FOD
Characteristics
Item Suitability
Data
Component
COMP.4 Air
Retrieval Vehicle
(ARV) Segment
Component
COMP.3.1 IFerret
TM & AFDIRTS
Interface Unit
Component
COMP.6.2 Analysis
Radio
165

Number Name
Transfers
Connects to
L.1.6
Item Navigation
Modes
Component
COMP.1.3
Command and
Control Computer
(CCC)
L.1.5
Command and Control

Computer (CCC) -> IFerret TM
& AFDIRTS Interface Unit
Iferret -> AMDU
Item FOD
Location
Item Unsuitable
FOD Location Data
Component
COMP.3.1 IFerret
TM & AFDIRTS
Interface Unit
Component
COMP.1.1 Airport
Management
Display Unit (AMDU)
Component
COMP.3.1 IFerret
TM & AFDIRTS
Interface Unit
166

The Air Retrieval Vehicle (ARV) is designed to transport the Retrieval Subsystem System
to the FODs location on the airfield and grasp it with a COTS gripper, the VERSABALL
developed by Empire Robotics. The ARV consists of four Subsystems; the Movement and
Control Subsystem, the Navigation Subsystem, ARV Power Subsystem, and the Retrieval
Subsystem. These subsystems will be discussed in detail below.
Figure 68. COMP.4 Air Retrieval Vehicle Physical Tree
167

The Movement and Control Subsystem has been designed to facilitate movement and stability of the ARV while
maneuvering to waypoints. It consists of an Attitude and Heading Reference System (AHARS), Barometric Altimeter, GPS
Unit, Movement and Control Computer, 8 Propellers, 8 Electric Motors and 8 Electronic Speed Controllers.
Figure 69. COMP.4.1 Movement and Control Subsystem Physical Tree
168

Figure 70. COMP.4.1 Movement and Control Physical Block Diagram
pbd Movement and Control Subsystem
#8 Propeller <-> Environment
ENV.4
Environment

External System
Electric Motor
(EM)_4
HWCI
HWCI
HWCI
HWCI
ESC4 -> EM4
ESC3 -> EM3
ESC2 -> EM2
COMP.4.1.13
COMP.4.1.20
Movement and Control
GPS Unit (MCGPS)
COMP.4.1.14
Electronic Speed
Controller (ESC)_2
Electronic Speed
Controller (ESC)_3
Electronic Speed
Controller (ESC)_4
HWCI
HWCI
HWCI
HWCI
MMCPU - > ESC_3
MCGPS - > MCCPU
EM_#8 -> Prop_#8
COMP.4.1.10
COMP.4.1.9
Electric Motor
(EM)_6
Electric Motor
(EM)_7
Electric Motor
(EM)_8
HWCI
HWCI
HWCI
HWCI
COMP.4.1.1
Attitude and Heading
Reference Systems
(AHRS)
COMP.4.1.8
Electric Motor
(EM)_5
COMP.4.1.15
COMP.4.1.16
COMP.4.1.17
COMP.4.1.18
Electronic Speed
Controller (ESC)_5
Electronic Speed
Controller (ESC)_6
Electronic Speed
Controller (ESC)_7
Electronic Speed
Controller (ESC)_8
HWCI
HWCI
HWCI
HWCI
HWCI
AHARS -> MCCPU
MMCPU - > ESC_2
HWCI
MMCPU - > ESC_4
Electronic Speed
Controller (ESC)_1
MMCPU -> ESC_1
BARALT - > MCCPU
COMP.4.1.12
HWCI
ESC8 -> EM8
Electric Motor
(EM)_3
ESC1 -> EM1
Electric Motor
(EM)_2
COMP.4.1.11
COMP.4.1.7
Barometric Altimeter
Electric Motor
(EM)_1
Part
EM_#7 -> Prop_#7
COMP.4.1.2
COMP.4.1.6
Part
MMCPU - > ESC_8
COMP.4.1.5
Propeller_8
Part
ESC7 -> EM7
COMP.4.1.4
EM_#4 -> Prop_#4
EM_#1 -> Prop_#1
COMP.4.1.3
Part
COMP.4.1.28
Propeller_7
MMCPU - > ESC_7
Part
COMP.4.1.27
Propeller_6
EM_#6 -> Prop_#6
Part
COMP.4.1.26
ESC6 -> EM6
Part
Propeller_5
MMCPU - > ESC_6
Part
COMP.4.1.25
ESC5 -> EM5
Propeller_4
EM_#3 -> Prop_#3
Propeller_3
EM_#2 -> Prop_#2
Propeller_2
EM_#5 -> Prop_#5
COMP.4.1.24
COMP.4.1.23
Propeller_1
MMCPU - > ESC_5
COMP.4.1.22
Barometric Altimeter / Environment
COMP.4.1.21
COMP.4.1.19
PDB -> ESC_5
COMP.4.3.1
PDB -> ESC_6
Power Distribution
Board (PDB)
PDB -> ESC_8
HWCI
PDB -> ESC_7
PDB -> ESC_4
HWCI
NAV Computer -> MCCPU
PDB-> ESC_3
PDB -> ESC_2
PDB -> ESC_1

Computer (MCCOMP)
COMP.4.2.1
NAV Computer
HWCI
Date:
December 4, 2015
169

Table 73. COMP.4.1 Movement and Control Subsystem Functional Traceability Matrix
Number
Name
Type
Performs
COMP.4.1
Movement and
Control Subsystem
Subsystem
COMP.4.1.1
Attitude and
Heading Reference
Systems (AHRS)
HWCI
Function F.4.1
Move and Control
ARV
Function F.4.1.27
Determine Position
in Space
COMP.4.1.2
Barometric
Altimeter
HWCI
COMP.4.1.3
Electric Motor
(EM)_1
HWCI
COMP.4.1.4
Electric Motor
(EM)_2
HWCI
Function F.4.1.6
Spin #2 Propeller
COMP.4.1.5
Electric Motor
(EM)_3
HWCI
Function F.4.1.9
Spin #3 Propeller
COMP.4.1.6
Electric Motor
(EM)_4
HWCI
Function F.4.1.12
Spin #4 Propeller
COMP.4.1.7
Electric Motor
(EM)_5
HWCI
Function F.4.1.15
Spin #5 Propeller
COMP.4.1.8
Electric Motor
(EM)_6
HWCI
Function F.4.1.18
Spin #6 Propeller
COMP.4.1.9
Electric Motor
(EM)_7
HWCI
Function F.4.1.21
Spin #7 Propeller
COMP.4.1.10
Electric Motor
(EM)_8
HWCI
Function F.4.1.24
Spin #8 Propeller
COMP.4.1.11
Electronic Speed
Controller (ESC)_1
HWCI
COMP.4.1.12
Electronic Speed
Controller (ESC)_2
HWCI
COMP.4.1.13
Electronic Speed
Controller (ESC)_3
HWCI
COMP.4.1.14
Electronic Speed
Controller (ESC)_4
HWCI
Function F.4.1.2
Control #1 Motor
Speed
Function F.4.1.5
Control #2 Motor
Speed
Function F.4.1.8
Control #3 Motor
Speed
Function F.4.1.11
Control #4 Motor
Speed
Function F.4.1.28
Determine
Barometric Pressure
Function F.4.1.3
Spin #1 Propeller
170

Number
Name
Type
Performs
COMP.4.1.15
Electronic Speed
Controller (ESC)_5
HWCI
COMP.4.1.16
Electronic Speed
Controller (ESC)_6
HWCI
COMP.4.1.17
Electronic Speed
Controller (ESC)_7
HWCI
COMP.4.1.18
Electronic Speed
Controller (ESC)_8
HWCI
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
HWCI
COMP.4.1.19.1
MCCOPM Software
SWCI
COMP.4.1.20
Movement and
Control GPS Unit
(MCGPS)
HWCI
Function F.4.1.14
Control #5 Motor
Speed
Function F.4.1.17
Control #6 Motor
Speed
Function F.4.1.20
Control #7 Motor
Speed
Function F.4.1.23
Control #8 Motor
Speed
Function F.4.1.1
Carry out
Movement and
Control Instructions
Function F.4.1.1.1
Supply MCCOMP
Instructions
Function F.4.1.26
Determine GPS
Location
COMP.4.1.21
Propeller_1
Part
COMP.4.1.22
Propeller_2
Part
COMP.4.1.23
Propeller_3
Part
COMP.4.1.24
Propeller_4
Part
COMP.4.1.25
Propeller_5
Part
COMP.4.1.26
Propeller_6
Part
Function F.4.1.4
Generate #1 Motor
Thrust
Function F.4.1.7
Generate #2 Motor
Thrust
Function F.4.1.10
Generate #3 Motor
Thrust
Function F.4.1.13
Generate #4 Motor
Thrust
Function F.4.1.16
Generate #5 Motor
Thrust
Function F.4.1.19
Generate #6 Motor
Thrust
171

Number
Name
Type
Performs
COMP.4.1.27
Propeller_7
Part
COMP.4.1.28
Propeller_8
Part
Function F.4.1.22
Generate #7 Motor
Thrust
Function F.4.1.25
Generate #8 Motor
Thrust
Table 74. COMP.4.1 Movement and Control Subsystem Interface Descriptions

Number Name
L.4.1.1
#1 Propeller <->
Environment
L.4.1.2
L.4.1.3
L.4.1.4
L.4.1.5
#2 Propeller <->
Environment
#3 Propeller <->
Environment
#4 Propeller <->
Environment
Barometric Altimeter /
Environment
Transfers
Item #1 Motor Thrust
Connects to
Component
COMP.4.1.21
Propeller_1
Component
ENV.4 Environment
Component
COMP.4.1.22
Propeller_2
Component
ENV.4 Environment
Component
COMP.4.1.23
Propeller_3
Component
ENV.4 Environment
Component
COMP.4.1.24
Propeller_4
Item Barometric
Pressure
Component
ENV.4 Environment
Component
COMP.4.1.2
Barometric
Altimeter
Component
ENV.4 Environment
172

Number Name
L.4.1.6
#5 Propeller <->
Environment
L.4.1.7
L.4.1.8
L.4.1.9
L.4.1.10
L.4.1.11
L.4.1.12
#6 Propeller <->
Environment
#7 Propeller <->
Environment
#8 Propeller <->
Environment
EM_#1 -> Prop_#1
EM_#2 -> Prop_#2
EM_#3 -> Prop_#3
Transfers
Connects to
Component
COMP.4.1.25
Propeller_5
Component
ENV.4 Environment
Component
COMP.4.1.26
Propeller_6
Component
ENV.4 Environment
Component
COMP.4.1.27
Propeller_7
Component
ENV.4 Environment
Component
COMP.4.1.28
Propeller_8
Item #1 Propeller
Rotation
Item #2 Propeller
Rotation
Item #3 Propeller
Rotation
Component
ENV.4 Environment
Component
COMP.4.1.3 Electric
Motor (EM)_1
Component
COMP.4.1.21
Propeller_1
Component
COMP.4.1.4 Electric
Motor (EM)_2
Component
COMP.4.1.22
Propeller_2
Component
COMP.4.1.5 Electric
Motor (EM)_3
173

Number Name
Transfers
L.4.1.13
Item #4 Propeller
Rotation
L.4.1.14
L.4.1.15
L.4.1.16
L.4.1.17
L.4.1.18
EM_#4 -> Prop_#4
EM_#5 -> Prop_#5
EM_#6 -> Prop_#6
EM_#7 -> Prop_#7
EM_#8 -> Prop_#8
ESC1 -> EM1
Item #5 Propeller
Rotation
Item #6 Propeller
Rotation
Item #7 Propeller
Rotation
Item #8 Propeller
Rotation
Item #1 Motor Voltage
Connects to
Component
COMP.4.1.23
Propeller_3
Component
COMP.4.1.6 Electric
Motor (EM)_4
Component
COMP.4.1.24
Propeller_4
Component
COMP.4.1.7 Electric
Motor (EM)_5
Component
COMP.4.1.25
Propeller_5
Component
COMP.4.1.8 Electric
Motor (EM)_6
Component
COMP.4.1.26
Propeller_6
Component
COMP.4.1.9 Electric
Motor (EM)_7
Component
COMP.4.1.27
Propeller_7
Component
COMP.4.1.10
Electric Motor
(EM)_8
Component
COMP.4.1.28
Propeller_8
Component
COMP.4.1.3 Electric
Motor (EM)_1
174

Number Name
Transfers
L.4.1.19
L.4.1.20
L.4.1.21
L.4.1.22
L.4.1.23
ESC2 -> EM2
ESC3 -> EM3
ESC4 -> EM4
ESC5 -> EM5
ESC6 -> EM6
Connects to
Component
COMP.4.1.11
Electronic Speed
Controller (ESC)_1
Component
COMP.4.1.4 Electric
Motor (EM)_2
Component
COMP.4.1.12
Electronic Speed
Controller (ESC)_2
Component
COMP.4.1.5 Electric
Motor (EM)_3
Component
COMP.4.1.13
Electronic Speed
Controller (ESC)_3
Component
COMP.4.1.6 Electric
Motor (EM)_4
Component
COMP.4.1.14
Electronic Speed
Controller (ESC)_4
Component
COMP.4.1.7 Electric
Motor (EM)_5
Component
COMP.4.1.15
Electronic Speed
Controller (ESC)_5
Component
COMP.4.1.8 Electric
Motor (EM)_6
Component
COMP.4.1.16
175

Number Name
Transfers
L.4.1.24
L.4.1.25
L.4.1.26
L.4.1.27
L.4.1.28
ESC7 -> EM7
ESC8 -> EM8
MMCPU -> ESC_1
MMCPU - > ESC_2
MMCPU - > ESC_3
Item #1 Motor Speed
Item #2 Motor Speed
Item #3 Motor Speed
Connects to
Electronic Speed
Controller (ESC)_6
Component
COMP.4.1.9 Electric
Motor (EM)_7
Component
COMP.4.1.17
Electronic Speed
Controller (ESC)_7
Component
COMP.4.1.10
Electric Motor
(EM)_8
Component
COMP.4.1.18
Electronic Speed
Controller (ESC)_8
Component
COMP.4.1.11
Electronic Speed
Controller (ESC)_1
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.12
Electronic Speed
Controller (ESC)_2
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.13
Electronic Speed
Controller (ESC)_3
176

Number Name
L.4.1.29
L.4.1.30
L.4.1.31
L.4.1.32
MMCPU - > ESC_4
MMCPU - > ESC_5
MMCPU - > ESC_6
MMCPU - > ESC_7
Transfers
Item #4 Motor Speed
Item #5 Motor Speed
Item #6 Motor Speed
Item #7 Motor Speed
Connects to
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.14
Electronic Speed
Controller (ESC)_4
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.15
Electronic Speed
Controller (ESC)_5
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.16
Electronic Speed
Controller (ESC)_6
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.17
Electronic Speed
Controller (ESC)_7
Component
COMP.4.1.19
177

Number Name
Transfers
L.4.1.33
Item #8 Motor Speed
L.4.1.34
L.4.1.35
L.4.1.36
MMCPU - > ESC_8
AHARS -> MCCPU
BARALT - > MCCPU
MCGPS - > MCCPU
Item AHRS
Coordinates
Item Digitized
Barometric Pressure
Item MCGPS Data
Connects to
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.18
Electronic Speed
Controller (ESC)_8
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.1
Attitude and
Heading Reference
Systems (AHRS)
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.2
Barometric
Altimeter
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.20
Movement and
178

Number Name
Transfers
L.4.1.37
Item XX Volts DC to
ESC_1
L.4.1.38
L.4.1.39
L.4.1.40
L.4.1.41
PDB -> ESC_1
PDB -> ESC_2
PDB-> ESC_3
PDB -> ESC_4
PDB -> ESC_5
Item XX Volts DC to
ESC_2
Item XX Volts DC to
ESC_3
Item XX Volts DC to
ESC_4
Item XX Volts DC to
ESC_5
Connects to
Control GPS Unit
(MCGPS)
Component
COMP.4.1.11
Electronic Speed
Controller (ESC)_1
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.12
Electronic Speed
Controller (ESC)_2
Component
COMP.4.3.1
Power Distribution
Board (PDB)
Component
COMP.4.1.13
Electronic Speed
Controller (ESC)_3
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.14
Electronic Speed
Controller (ESC)_4
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.15
Electronic Speed
Controller (ESC)_5
179

Number Name
Transfers
L.4.1.42
Item XX Volts DC to
ESC_6
L.4.1.43
L.4.1.44
L.4.1.45
L.4.1.46
PDB -> ESC_6
PDB -> ESC_7
PDB -> ESC_8
NAV Computer ->

MCCPU
VR -> MCCPU
Item XX Volts DC to
ESC_7
Item XX Volts DC to
ESC_8
Item Navigation
Instructions
Item Obstacle Path
Connects to
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.16
Electronic Speed
Controller (ESC)_6
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.17
Electronic Speed
Controller (ESC)_7
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.18
Electronic Speed
Controller (ESC)_8
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.2.1 NAV
Computer
Component
COMP.4.1.20
Movement and
180

Number Name
L.4.1.47
VR -> BARALT
Transfers
Connects to
Control GPS Unit
(MCGPS)
Component
COMP.4.3.3
Voltage Regulator
Component
COMP.4.1.2
Barometric
Altimeter
Component
COMP.4.3.3
Voltage Regulator
181

The ARV Navigation Subsystem is designed to receive ARV navigation instructions from
the Command and Control Subsystem. It will enable the ARV to navigate the airfield
avoiding obstacles and airport traffic while executing movement commands.
Figure 71. COMP4.2 ARV Navigation Subsystem Physical Tree
182

Figure 72. COMP.4.2 ARV Navigation Subsystem Physical Block Diagram
pbd ARV Navigation Subsystem
ENV.7
GPS Satellites
External System
HWCI
nil
(EXT) GPS Satellites -> NAV GPS
NAV GPS - > Analysis Computer
Obstacles <-> NAV RADAR UNIT
(EXT) Obstacle -> NCIPU
Analysis Computer
COMP.4.2.3
NAV RADAR Unit
HWCI
NCIPU -> NAV Computer
HWCI
(CCR) Command and

Control Radio
HWCI
HWCI
COMP.4.2.1
NAV Computer
Weight Sensor
HWCI
COMP.4.2.4
NAV GPS
NAV GPS -> FOD Camera Unit
HWCI
NAV GPS -> NAV Computer
COMP.1.6
Analysis Radio
COMP.4.4.4
Weight Sensor -> NAV Computer
NAV Camera & Image

Processing Unit
(NCIPU)
NAV RADAR UNIT<-> NAV Computer
COMP.4.2.2
COMP.6.2
ENV.9
COMP.6.1
Obstacles
COMP.4.4.3
FOD Camera Unit
HWCI
NAV Radio - > NAV Computer
CCR -> NAV Radio
NAV Radio - > Analysis Radio
HWCI
COMP.4.1.19
HWCI
COMP.4.2.5
NAV Radio

Computer (MCCOMP)
COMP.4.4.2
NAV Computer -> VERSABALL System
HWCI
VERSABALL System
HWCI
Date:
December 4, 2015
183

Table 75. COMP.4.2 ARV Navigation Subsystem Functional Traceability Matrix
Number
Name
Type
Performs
COMP.4.2
ARV Navigation Subsystem
Subsystem
Function F.4.2
Navigate Airfield
COMP.4.2.1
NAV Computer
HWCI
COMP.4.2.2
NAV Camera & Image

Processing Unit (NCIPU)
HWCI
Function F.4.2.2
Process Navigation
Commands
Function F.4.2.6
Anticipate
Obstacle
Movement
Function F.4.2.7
Determine Path
Around Obstacles
Function F.4.2.3
Detect Obstacles
COMP.4.2.3
NAV RADAR Unit
HWCI
COMP.4.2.4
NAV GPS
HWCI
COMP.4.2.5
NAV Radio
HWCI
Function F.4.2.4
Determine
Obstacle Location
Function F.4.2.8
Determine Location
Function F.4.2
Navigate Airfield
Function F.4.2.1
Receive Navigation
Commands
Function F.4.2.5
Receive Aircraft
Trajectory Data
from ATC
184

Table 76. COMP.4.2 ARV Navigation Subsystem Interface Descriptions
Number Name
L.4.2.1
L.4.2.2
L.4.2.3
L.4.2.4
L.4.2.5
L.4.2.6
Transfers
Item (Ext)
Obstacle
Identification from
Obstacle
Item (Ext)
Aircraft Location
from Aircraft
Item (Ext)
Obstacle Location
from Obstacle
Item Obstacle
Illumination to
Obstacle
Item Location
Data from GPS
Satellites
Item At FOD
Location Signal
Item At FOD
Location Signal
Item
Coordinates
Connects to
Component
COMP.4.2.2 NAV
Camera & Image
Processing Unit
(NCIPU)
Component
ENV.7 Obstacles
Component
COMP.4.2.3 NAV
RADAR Unit
Component
ENV.7 Obstacles
Component
COMP.4.2.4 NAV
GPS
Component
ENV.9 GPS Satellites
Component
COMP.4.2.4 NAV
GPS
Component
COMP.6.1 Analysis
Computer
Component
COMP.4.2.4 NAV
GPS
Component
COMP.4.4.3 FOD
Camera Unit
Component
COMP.4.2.1 NAV
Computer
185

Number Name
Transfers
L.4.2.7
NAV RADAR UNIT<-> NAV

Computer
Item **NAV
RADAR UNIT<->
NAV Computer**
L.4.2.8
Item Obstacle
Characteristics
L.4.2.9
L.4.2.10
L.4.2.11
Weight Sensor -> NAV

Computer
NAV Computer -> VERSABALL

System
Item Transport to
Disposal Location
Signal
Item At Disposal
Location Signal
Item Navigation
Instructions
Item Obstacle
Path
Connects to
Component
COMP.4.2.4 NAV
GPS
Component
COMP.4.2.1 NAV
Computer
Component
COMP.4.2.3 NAV
RADAR Unit
Component
COMP.4.2.1 NAV
Computer
Component
COMP.4.2.2 NAV
Camera & Image
Processing Unit
(NCIPU)
Component
COMP.4.2.1 NAV
Computer
Component
COMP.4.4.4 Weight
Sensor
Component
COMP.4.2.1 NAV
Computer
Component
COMP.4.4.2
VERSABALL System
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.2.1 NAV
Computer
186

Number Name
L.4.2.12 NAV Radio - > NAV Computer
L.4.2.13
L.1.18
CCR -> NAV Radio
Transfers
Item Inbound
Aircraft Trajectory
Item Navigation
Command
Item Inbound
Aircraft Data to
ARV
Item Navigation
Modes
Connects to
Component
COMP.4.2.1 NAV
Computer
Component
COMP.4.2.5 NAV
Radio
Component
COMP.4.2.5 NAV
Radio
Component
COMP.6.2 Analysis
Radio
Component
COMP.1.6 (CCR)
Command and
Control Radio
Component
COMP.4.2.5 NAV
Radio
187

The ARV Power Subsystem supplies stored power to ARV Components. It consists of a
Lithium-ion Battery, a Power Distribution Board, and a Voltage Regulator.
**The decision to utilize a, Lithium-Ion (Li-Ion) battery was determined in a formal trade
study and submitted as a SM4 deliverable**
Figure 73. COMP.4.3 ARV Power Subsystem Physical Tree
188

Figure 74. COMP.4.3 ARV Power Subsystem Physical Block Diagram
pbd Power Subsystem
COMP.4.2
ARV Navigation
Subsystem
Subsystem
COMP.4.4
VR ->ARV Command and NAV Subsystem
COMP.4.1
Subsystem
Retrieval Subsystem
Subsystem
VR -> Retrieval Subsys...
Movement and
Control Subsystem
VR - > AHRS
COMP.5.5
COMP.4.3.3
Battery Charger
HWCI
Battery Charger -> Battery
Voltage Regulator
BATT -> VR
HWCI
COMP.4.3.2
Battery
COMP.4.1.11
PDB -> ESC_1
BATT -> PDB
COMP.4.1.13
Electronic Speed
Controller (ESC)_3
Electronic Speed
Controller (ESC)_4
HWCI
PDB -> ESC_6
HWCI
Electronic Speed
Controller (ESC)_7
HWCI
COMP.4.1.16
Electronic Speed
Controller (ESC)_6
HWCI
PDB -> ESC_8
COMP.4.1.14
PDB -> ESC_7
PDB -> ESC_4
HWCI
Power Distribution
Board (PDB)
PDB-> ESC_3
HWCI
PDB -> ESC_2
Electronic Speed
Controller (ESC)_5
COMP.4.1.17
COMP.4.3.1
COMP.4.1.12
Electronic Speed
Controller (ESC)_2
PDB -> ESC_5
HWCI
Electronic Speed
Controller (ESC)_1
HWCI
COMP.4.1.15
COMP.4.1.18
Electronic Speed
Controller (ESC)_8
HWCI
HWCI
Date:
December 4, 2015
189

Table 77. COMP.4.3 ARV Power Subsystem Functional Traceability Matrix
Number
Name
Type
Performs
COMP.4.3
Power Subsystem
Subsystem
COMP.4.3.1
Power Distribution Board

(PDB)
HWCI
COMP.4.3.2
Battery
HWCI
COMP.4.3.3
Voltage Regulator
HWCI
Function F.4.3
Provide ARV
Electrical Power
Function F.4.3.9
Provide Power to
ESC_1
Function F.4.3.10
Provide Power to
ESC_2
Function F.4.3.11
Provide Power to
ESC_3
Function F.4.3.12
Provide Power to
ESC_4
Function F.4.3.13
Provide Power to
ESC_5
Function F.4.3.14
Provide Power to
ESC_6
Function F.4.3.15
Provide Power to
ESC_7
Function F.4.3.16
Provide Power to
ESC_8
Function F.4.3.1
Provide Stored
Electricity to ARV
Function F.4.3.2
Regulate NAV
Subsystem Voltage
Function F.4.3.3
Regulate
Movement and
Control Subsystem
Voltage
Function F.4.3.4
Regulate Retrieval
Subsystem Voltage
190

Table 78. COMP.4.3 ARV Power Subsystem Interface Descriptions
Number Name
Transfers
Connects to
L.4.3.1
Item XX Volts DC
Regulated
Movement and
Control Subsystem
Component
COMP.4.1
Movement and
Control Subsystem
L.4.3.2
L.4.3.3
L.4.3.4
L.4.3.5
L.4.3.6
VR - > AHRS
VR ->ARV Command and NAV

Subsystem
VR -> Retrieval Subsystem
BATT -> VR
BATT -> PDB
PDB -> ESC_1
Item XX Volts DC
Regulated NAV
Subsystem Voltage
Component
COMP.4.3.3
Voltage Regulator
Component
COMP.4.2 ARV
Navigation
Subsystem
Item XX Volts DC
Regulated Retrieval
Subsystem Voltage
Component
COMP.4.3.3
Voltage Regulator
Component
COMP.4.3.3
Voltage Regulator
Item Electrical
Energy from Battery
Component
COMP.4.4 Retrieval
Subsystem
Component
COMP.4.3.2 Battery
Item Electrical
Energy from Battery
Item XX Volts DC
to ESC_1
Component
COMP.4.3.3
Voltage Regulator
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.3.2 Battery
Component
COMP.4.1.11
Electronic Speed
Controller (ESC)_1
191

Number Name
L.4.3.7
L.4.3.8
L.4.3.9
L.4.3.10
L.4.3.11
PDB -> ESC_2
PDB-> ESC_3
PDB -> ESC_4
PDB -> ESC_8
PDB -> ESC_6
Transfers
Item XX Volts DC
to ESC_2
Item XX Volts DC
to ESC_3
Item XX Volts DC
to ESC_4
Item XX Volts DC
to ESC_8
Item XX Volts DC
to ESC_6
Connects to
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.12
Electronic Speed
Controller (ESC)_2
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.13
Electronic Speed
Controller (ESC)_3
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.14
Electronic Speed
Controller (ESC)_4
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.18
Electronic Speed
Controller (ESC)_8
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.16
192

Number Name
Transfers
Connects to
Electronic Speed
Controller (ESC)_6
L.4.3.12
L.4.3.13
L.5.5.1
PDB -> ESC_7
PDB -> ESC_5
Item XX Volts DC
to ESC_7
Item XX Volts DC
to ESC_5
Item Electrical
Energy from
Charger
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.17
Electronic Speed
Controller (ESC)_7
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.15
Electronic Speed
Controller (ESC)_5
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.3.2 Battery
Component
COMP.5.5 Battery
Charger
193

ARV to perform the Grasp FOD and Release FOD Functions. In order to perform
these functions, the camera unit will allow the ARV to maneuver to the precise location
of the FOD, while the Weight Sensor and Telemetry Radio will weigh and notify
personnel of FOD that cannot be retrieved due to its weight.
**The Versaball Gripper is a COTS component that was selected to perform the as the result of
an informal trade study**
Figure 76. COMP.4.4 ARV Retrieval Subsystem Physical Tree
194

Figure 77. COMP.4.4 ARV Retrieval Subsystem Physical Block Diagram
pbd Retrieval Subsystem
COMP.1.6
(CCR) Command and

Control Radio
HWCI
COMP.4.4.4
Weight Sensor
Weight Sensor -> Retrieval Telemetry Radio
COMP.4.2.4
NAV GPS
ENV.5
HWCI
FOD
FOD Camera Unit <-> FOD
VERSABALL System <->

FOD
External System
Weight Sensor <-> VERSABALL System
HWCI
COMP.4.4.1
COMP.4.2.1
HWCI
HWCI
NAV Computer
HWCI
COMP.4.4.2
VERSABALL System
Retrieval Telemetry
Radio
COMP.4.4.3
FOD Camera Unit
FOD Camera Unit -> Retrieval Telemetry Radio
NAV Computer -> VERSABALL Sys...
HWCI
Date:
December 4, 2015
195

Table 79. COMP.4.4 Retrieval Subsystem Functional Traceability Matrix
Number
Name
Type
Performs
COMP.4.4
Retrieval Subsystem
Subsystem
COMP.4.4.1
Retrieval Telemetry Radio
HWCI
COMP.4.4.2
VERSABALL System
HWCI
COMP.4.4.3
FOD Camera Unit
HWCI
COMP.4.4.4
Weight Sensor
HWCI
Function F.4.4
Retrieve FOD
Function F.4.4.3
Notify Personnel of
Object too Large
for Retrieval
Function F.4.4.6
Notify Personnel of
Overweight
Objects
Function F.4.4.4
Grasp FOD
Function F.4.4.7
Release FOD
Function F.4.4.1
Determine FOD
Characteristics
Function F.4.4.5
Determine FOD
weight
Table 80. COMP.4.4 Retrieval Subsystem Interface Descriptions

Number
Name
Transfers
Connects to
L.4.4.1

Computer
Item Transport to
Disposal Location
Signal
Component
COMP.4.2.1 NAV
Computer
L.4.4.2
Weight Sensor -> Retrieval

Telemetry Radio
Item Overweight
Signal
Component
COMP.4.4.4 Weight
Sensor
Component
COMP.4.4.1
Retrieval Telemetry
Radio
Component
COMP.4.4.4 Weight
Sensor
196

Number
Name
Transfers
Connects to
L.4.4.3
Weight Sensor <-> VERSABALL

System
Item Grasped
FOD's Weight
Component
COMP.4.4.2
VERSABALL System
L.4.4.4
L.4.4.5
L.4.4.6
L.4.4.7
L.4.2.5
VERSABALL System <-> FOD
FOD Camera Unit -> Retrieval

Telemetry Radio
Retrieval Telemetry Radio ->

CCR
Item FOD
Item FOD
Identification from
FOD
Item FOD too

Large Signal
Item Unsuitable
FOD Location Data
Item At FOD
Location Signal
Component
COMP.4.4.4 Weight
Sensor
Component
COMP.4.4.2
VERSABALL System
Component
ENV.5 FOD
Component
COMP.4.4.3 FOD
Camera Unit
Component
ENV.5 FOD
Component
COMP.4.4.1
Retrieval Telemetry
Radio
Component
COMP.4.4.3 FOD
Camera Unit
Component
COMP.1.6 (CCR)
Command and
Control Radio
Component
COMP.4.4.1
Retrieval Telemetry
Radio
Component
COMP.4.2.4 NAV
GPS
Component
COMP.4.4.3 FOD
Camera Unit
197

Number
Name
Transfers
Connects to
L.4.2.10

System
Item At Disposal
Location Signal
Component
COMP.4.2.1 NAV
Computer
Component
COMP.4.4.2
VERSABALL System
198

use. The figure below (Figure 21) is a conceptual image and not intended to be the
actual structural design. The structural design will be developed in the Advanced
Development Phase and it will result from prototypes that can withstand the elements
and are easily integrated with the IFerret Detection System. It may even be attached to
the IFerret Structure.
199
Figure 79. COMP.5 Power and Housing Segment Physical Tree
Figure 80. COMP.5 Power and Housing Physical Block Diagram

pbd Power and AV Housing Segment
ENV.8
Power
External System
COMP.6
(EXT) Power -> Transfer Switch
FOD Analysis Segment

COMP.1
HWCI
Command and
Control Segment
Segment
Power - > FOD Analysis Segment
COMP.3
Detection Segment
(EXT) Environment - > AV Housing Unit
Power -> Command and Control Segment
External System
COMP.5.1
Power Transfer Panel
HWCI
HWCI
COMP.5.3
HWCI
Power Transfer Panel - > AV Housing Unit
Generator
Generator -> Power Transfer Panel
HWCI
COMP.5.6
COMP.5.4
AV Housing Unit
Transfer Switch
Transfer Switch - > Generator
Environment
COMP.5.2
Transfer Switch - > Power Transfer Panel
ENV.4
Power -> Detection Segment
Segment
AV Housing Unit -> Charging Receptacle
Charging Receptacle
HWCI
COMP.4.3.2
COMP.5.5
Charging Receptacle -> Battery Char...
Battery Charger
HWCI
Date:
Battery
HWCI
December 4, 2015
200
Table 81. COMP.5 Power and Housing Segment Functional Traceability Matrix
Number
Name
Type
Performs
COMP.5
Power and AV
Housing Segment
Subsystem
COMP.5.1
HWCI
COMP.5.2
Power Transfer
Panel
Transfer Switch
COMP.5.3
Generator
HWCI
COMP.5.4
AV Housing Unit
HWCI
COMP.5.5
Battery Charger
HWCI
COMP.5.6
Charging
Receptacle
HWCI
Function F.5
Provide AV Housing
and System Power
Function F.5.4
Transfer Power
Function F.5.1
Accept External
Power
Function F.5.2
Detect External
Power Failure
Function F.5.3
Generate
Emergency Power
Function F.5.5
Provide Air Vehicle
Housing
Function F.5.6
Secure AV
Function F.5.8
Recharge Air
Vehicle
Function F.5.7
Make Charging
Connection
HWCI
Table 82. COMP.5 Power and Housing Segment Interface Descriptions

Number
Name
Transfers
Connects to
L.5.1
(EXT) Environment - > AV

Housing Unit
Item (Ext) Rain

Item (Ext) Snow
Item (Ext) Wind
Component
COMP.5.4 AV
Housing Unit
Item Electricity
Component
ENV.4 Environment
Component
COMP.5.1 Power
Transfer Panel
L.5.2
Power Transfer Panel - > AV

Housing Unit
201

Number
L.5.3
L.5.4
L.5.5
L.5.6
L.5.7
L.5.8
Name
Power -> Command and

Control Segment
Power - > FOD Analysis

Segment
Transfer Switch - > Power

Transfer Panel
Generator -> Power Transfer

Panel
Charging Receptacle ->

Battery Charger
Transfers
Item Electricity
Item Electricity
Item Electricity
Item Electricity
Item Generator
Power
Item Electricity
Connects to
Component
COMP.5.4 AV
Housing Unit
Component
COMP.3 Detection
Segment
Component
COMP.5.1 Power
Transfer Panel
Component
COMP.1 Command
and Control
Segment
Component
COMP.5.1 Power
Transfer Panel
Component
COMP.5.1 Power
Transfer Panel
Component
COMP.6 FOD
Analysis Segment
Component
COMP.5.1 Power
Transfer Panel
Component
COMP.5.2 Transfer
Switch
Component
COMP.5.1 Power
Transfer Panel
Component
COMP.5.3
Generator
Component
COMP.5.5 Battery
Charger
202

Number
L.5.9
L.5.10
L.5.11
L.5.12
Name
AV Housing Unit -> Charging

Receptacle
Transfers
Connects to
Item (Ext)
Electrical Energy
from Power
Component
COMP.5.6
Charging
Receptacle
Component
COMP.5.2 Transfer
Switch
Item Power
Failure Signal from
Power
Component
ENV.8 Power
Component
COMP.5.2 Transfer
Switch
Item Electrical
Energy from
Charger
Item Electrical
Energy from
Charger
Component
COMP.5.3
Generator
Component
COMP.4.3.2 Battery
Component
COMP.5.5 Battery
Charger
Component
COMP.5.4 AV
Housing Unit
Component
COMP.5.6
Charging
Receptacle
203

can help them identify trends in Airfield Debris, so that they can formulate and
implement corrective measures to minimize FOD on the airfield. It consists of a telemetry
radio that will receive FOD Data and a computer and software to process this data.
Figure 81. COMP.6 FOD Analysis Segment Physical Tree
204

Figure 82. COMP.6 Power and Housing Segment Physical Block Diagram
pbd FOD Analysis Segment
IFerret TM &
AFDIRTS Interface
Unit
COMP.4.2.5
COMP.4.2.4
NAV Radio
HWCI
Subsystem
COMP.1.1
NAV GPS
Airport Management
Display Unit (AMDU)
HWCI
Subsystem
COMP.6.2
COMP.6.1
COMP.3.1
Analysis Radio
Analysis Computer
HWCI
HWCI
Analysis Radio -> Analysis Computer

Date:
December 4, 2015
Table 83. COMP.6 FOD Analysis Segment Functional Traceability Matrix

Number
Name
Type
Performs
COMP.6
HWCI
COMP.6.1
Analysis Computer
HWCI
Function F.6
Analyze FOD Trends
Function F.6.2
Perform Trend
Analysis
Function F.6.3
Retain Data
Function F.6.4
Export FOD Reports
205

Number
Name
Type
Performs
COMP.6.1.1
Analysis Software
SWCI
COMP.6.2
Analysis Radio
HWCI
Function Carry
Out Operating
Instructions
Function F.6.1
Accept FOD alert
time and date,
location
coordinates and
FOD image data
Table 84. COMP.6 Analysis Segment Interface Descriptions

Number Name
Transfers
Connects to
L.1.13
Item Reports to
Airport Managers
Component
COMP.1.1 Airport
Management
Display Unit (AMDU)
L.3.2
L.4.2.4
L.4.2.13

Item FOD
Characteristics
Item Suitability
Data
Item At FOD
Location Signal
Item FOD Data
Component
COMP.6.1 Analysis
Computer
Component
COMP.3.1 IFerret
TM & AFDIRTS
Interface Unit
Component
COMP.6.2 Analysis
Radio
Component
COMP.4.2.4 NAV
GPS
Component
COMP.6.1 Analysis
Computer
Component
COMP.4.2.5 NAV
Radio
206
L.6.1
Analysis Radio -> Analysis

Computer
Item Raw FOD

Data
Component
COMP.6.2 Analysis
Radio
Component
COMP.6.1 Analysis
Computer
Component
COMP.6.2 Analysis
Radio
207
AFDIRTS Battery Trade Study
This trade study was performed to make certain that the best type of battery was
selected for the Air Retrieval Vehicle (ARV) Subsystem. The battery criteria selected for
this study was based upon the characteristics ability to help best meet AFDIRTS
requirements. The selection criteria were battery gravimetric energy density (Wh/kg),
Fast Charge Time, Maintenance Requirements, and Operating Temperature Range.
While cost was not calculated into operational utility functions, cost was a factor for
selection and taken into consideration upon ARV battery type selection.
208
Battery Alternatives
Nickel Cadmium (NiCd)
The NiCd battery was the preferred choice for industrial electronics for many years.
Then in the late 1980s the ultra-high-capacity NiCd was released that gave industry a
battery that was able to hold a 60 percent higher charge than the standard NiCd
battery (Battery University, 2015). The tradeoff for this higher capacity was higher
internal resistance and a reduced cycle count (Battery University, 2015). The standard
NiCd is one of the most rugged and forgiving batteries to this day; however, it needs
appropriate maintenance to achieve a long life (Battery University, 2015). NiCd
batteries have a memory effect that causes a capacity reduction over time if the
battery is not given a full discharge cycle periodically (Battery University, 2015).
Table 85. Nickel Cadmium (NiCd) battery specifications.
Nickel Cadmium (NiCd) Battery Specifications
Gravimetric Energy Density (Wh/kg)

Internal Resistance
Cycle Life (to 80% of initial capacity)
Fast Charge Time
Overcharge Tolerance
Self-discharge / Month (room temperature)
Cell Voltage(nominal)
Load Current Peak
Load Current (best result)
Operating Temperature(discharge only)
Maintenance Requirement
Typical Battery Cost
(US$, reference only)
Cost per Cycle(US$)
Commercial use since
Data retrieved from (Battery University, 2015)
45-80
100 to 200 (6V pack)
1500
1h typical
moderate
20%
1.25V6
20C
1C
-40 to 60C
30 to 60 days
$50
(7.2V)
$0.04
1950
209
Nickel-Metal Hydride (NiMH)
The Nickel-Metal Hydride (NiMH) battery was improved in the 1980s when new hydride
alloys improved past stability issues (Battery University, 2015). Today the NiMH battery
provides 40 percent higher specific energy than the standard NiCd with the absence of
toxic metals. The NiMH battery does have its disadvantages (Battery University, 2015). It
is more delicate and complicated to charge than NiCd batteries; additionally the
battery self-discharges 20 percent or more in the first 24 hours after charge (Battery
University, 2015). The NiMH battery is one of the lowest costing and most readily
available and batteries for portable devices (Battery University, 2015).
Table 86. Nickel-Metal Hydride (NiMH) battery specifications.
Nickel-Metal Hydride (NiMH) Battery Specifications

Internal Resistance
Fast Charge Time
Load Current Peak
Cost per Cycle(US$)
60-120
200 to 300 (6V pack)
300 to 500
2-4h
low
30%
1.25V6
5C
0.5C or lower
-20 to 60C
60 to 90 days
$60
(7.2V)
$0.12
1990
210
Lead Acid
Lead acid batteries are heavy and is less durable than nickel- and lithium-based
systems when deep-cycled (Battery University, 2015). When the battery is fully
discharged, it causes strain on the battery and subsequently robs the battery of a small
amount of storage capacity (Battery University, 2015). While this loss is small, the weardown characteristic eventually effects the battery that its performance drops to half
the nominal capacity. Depending this depth of discharge, lead acid for deep-cycle
applications provides 200 to 300 discharge/charge cycles (Battery University, 2015).
Lead acid batteries do not charge fast. Most types can take, a full charge can take 8
to16 hours to receive a full charge. Additionally, Lead Acid batteries must always be
stored at full state-of-charge.
Table 87. Lead Acid battery specification
Lead Acid Battery Specifications

Internal Resistance
Fast Charge Time
Load Current Peak
Cost per Cycle(US$)
30-50
<100 (12V pack)
200 to 300
8-16h
high
5%
2V
5C
0.2C
-20 to 60C
3 to 6 months
$25
(6V)
$0.10
1970
211
Lithium-ion (Li-ion)
Lithium is the lightest of all metals and as such it provides the greatest electrochemical
potential providing the greatest specific energy per weight (Battery University, 2015).
However, it was discovered that cycling had the potential to causing thermal runaway
in the battery released flaming gases potentially causing fires or inflicting burns (Battery
University, 2015). This inherent instability, especially while charging, forced researchers to
search for a non-metallic solution (Battery University, 2015). This solution came by utilizing
lithium ions and while lower in specific energy than lithium-metal, Li ion proved to be a
safer alternative (Battery University, 2015). Today the Lithium-ion battery is the most
promising and fastest growing battery on the market (Battery University, 2015). In
addition, Li-ion is a low-maintenance battery, has no memory and does not need to be
fully discharged to maintain good health (Battery University, 2015).
Table 88. Lithium-ion (Li-ion) Battery Specifications
Lithium-ion (Li-ion) Battery Specifications
Internal Resistance
Fast Charge Time
Load Current Peak
Cost per Cycle(US$)
110-160
150 to 250 (7.2V pack)
500 to 1000
2-4h
very low
10%
3.6V
>2C
1C or lower
-20 to 60C
not req.
$100
(7.2V)
$0.14
1991
212
Lithium-Polymer (LiPo)
Lithium polymer batteries are similar to lithium-ion batteries (Battery University, 2015).
Both use the same cathode and anode material and consist of a similar amount of
electrolyte (Battery University, 2015). Lithium polymer is distinctive from lithium-ion in that
a micro porous electrolyte replaces the traditional porous separator (Battery University,
2015). Lithium polymer batteries have a higher specific energy (only slightly) but can be
made thinner than conventional lithium-ion cells (Battery University, 2015). Lithium
polymer cells and can be made into a flexible foil-type case, while lithium-ion batteries
need a rigid case to press their electrodes together (Battery University, 2015). This type
of rigid case can increase battery weight by 25% (Battery University, 2015). In addition to
being lighter Lithium-Polymer batteries can be made into any shape including
extremely slim designs resembling a credit card (Battery University, 2015).
Table 89. Lithium-Polymer (LiPo) Battery Specifications
Lithium-Polymer (LiPo) Battery Specifications
Internal Resistance
Fast Charge Time
Load Current Peak
Cost per Cycle(US$)
Data retrieved from (Battery University, 2015
100-130
200 to 300 (7.2V pack)
300 to 500
2-4h
low
~10%
3.6V
>2C
1C or lower
0 to 60C
not req.
$100
(7.2V)
$0.29
1999
213
Selection Criteria
Selection criteria for the Air Retrieval Vehicle battery type was based upon the
characteristics ability to better meet AFDIRTS system performance requirements. The
selection criteria, and their relation to system requirements have been discussed in
further detail below.
Table 90. Battery Alternatives Selection Criteria Values
Nickel
Cadmium
(NiCd)
Nickel-Metal
Hydride
(NiMH)
Lead Acid
Lithium-ion
LiPo
(LithiumPolymer)
62.5
90
40
135
115
Maintenance
Requirement
1h
3h
12H
3H
2.5h
45 days
75 days
135 Days
Operating
Temperature
Range
100 C
80 C
80 C
80 C
60 C
Gravimetric Energy
Density(Wh/kg)
Fast Charge Time

Also known as Specific Energy, defines the batteries capacity in terms of Watt Hour per
Kilogram. A lower weight battery per watt hour is advantageous to the Air Retrieval
Vehicle in many ways. A higher What Hour to Kilogram battery capacity ratio could
help attain many performance requirements. First, and foremost high specific energy
would allow the vehicle to utilize this extra lifting capacity to help achieve requirement
R.5.2 The system shall be capable of retrieving FOD weighing up to 1 pound or
.45359237 kilograms However, the higher specific energy could also be utilized to
enable the ARV to carry more robust and heavier subsystem components.
214
Selection Criteria
Fast Charge Time

The longer it takes the ARV to charge the more time Air Retrieval Vehicles are
unavailable for FOD retrieval and disposal. This can have an adverse impact on
requirement R.11 The system should have an Operational Availability (AO) of 99.9%
Not only does more maintenance increase Operations & Maintenance (O&M) Costs;
but it decreases the amount of time the system is available again adversely affecting
R.11 Operational Availability.
Operating Temperature Range

While the system is only required to meet weather conditions for airfields local region as
specified in CLIM 20, Climatology of the United States No. 20 (as per requirement R.12
Operate in Adverse Weather Conditions) it is advantageous for the batteries to have a
large temperature range so that they may operate in a broad range of locations.
215
Weightings
The Analytical Hierarchy Process was utilized to develop weightings for selection criteria.
A pairwise comparison was performed on the battery criteria listed above and has
been listed in the chart below.
Table 91. Numerical criteria importance values
1 Means that criteria A and B are equally Important

3 means that A is thought to be moderately more important than B
5 means that A is thought to be strongly More important than B
7 means that A is thought to be, or has been demonstrated to be, much more
important than B
9 means A has been demonstrated to have much more importance than B
Table 92. Pairwise Comparison Chart
Gravimetric
Energy Density
(Wh/kg)
Operating
Temperature
Range
Fast Charge
Time
Maintenance
Requirement
Criteria Comparison Matrix
0.33333
0.2
0.33333
0.11111
0.2
0.33333
Sum
1.64444
4.53333
9.33333
18
Gravimetric Energy Density(Wh/kg)

Fast Charge Time
216
Weightings
Table 93. Normalized Criteria Comparison Matrix
Gravimetric
Energy Density
(Wh/kg)
Operating
Temperature
Range
Fast Charge
Time
Maintenance
Requirement
Normalized Criteria Comparison Matrix
0.60811
0.66176
0.53571
0.5
0.2027
0.22059
0.32143
0.27778
Fast Charge Time
0.12162
0.07353
0.10714
0.16667
0.06757
0.04412
0.03571
0.05556
Sum
Table 94. Normalized Criteria Comparison Matrix with Weights
Operating
Temperature
Range
Fast Charge
Time
0.60811
0.66176
0.53571
0.5
0.5763968
0.2027
0.22059
0.32143
0.27778
0.2556238
Fast Charge Time
0.12162
0.07353
0.10714
0.16667
0.11724
0.06757
0.04412
0.03571
0.05556
0.0507385
Gravimetric Energy
Density(Wh/kg)
Operating Temperature
Range
Sum
Maintenance
Requirement
Gravimetric
Energy Density
(Wh/kg)
Normalized Criteria Comparison Matrix with Weights
Criteria Weights
(W)
217
Utility Functions
Table 95. Gravimetric Energy Density Utility Function Curve
Table 96. Gravimetric Energy Density Utility Values
Gravimetric Energy Density Utility Values

Nickel
Nickel-Metal Lead Acid
LithiumCadmium
Hydride
ion
(NiCd)
(NiMH)
LiPo
(LithiumPolymer)
Gravimetric Energy
Density(Wh/kg)
62.5
90
40
135
115
Utility Value
0.462
0.666
0.296
0.851
218
Utility Functions
Table 97. Operating Temperature Range Utility Function Curve
Table 98. Operating Temperature Range Utility Values
Operating Temperature Range Utility Values

Nickel
Cadmium
(NiCd)
Nickel-Metal
Hydride
(NiMH)
Lead Acid
Lithiumion
LiPo
(LithiumPolymer)
Operating
Temperature
Range C
100 C
80 C
80 C
80 C
60 C
Utility Value
.8
.8
.8
.6
219
Utility Functions
Table 99. Fast Charge Time Utility Function Curve
Table 100. Fast Charge Time Utility Values
Fast Charge Time Utility Values

Nickel
Cadmium
(NiCd)
Fast Charge Time
Utility Value
Nickel-Metal
Hydride
(NiMH)
Lead Acid
Lithiumion
LiPo
(LithiumPolymer)
1 Hour
3 Hour
12 Hour
3 Hour
2.5 Hour
.833
.0833
.833
.875
220
Utility Functions
Table 101. Maintenance Requirement Utility Function Curve
Table 102. Maintenance Requirement Utility Values
Maintenance Requirement Utility Values

Nickel
Cadmium
(NiCd)
Nickel-Metal
Hydride (NiMH)
Lead Acid
Lithiumion
LiPo
(LithiumPolymer)
Maintenance
Requirement
(in Days)
45
75
135
Utility Value
.3
.5
.9
221
Rankings
Nickel-Metal Hydride
(NiMH)
Lead Acid
LiPo (Lithium-Polymer)
Table 103. Weighted Utility Score Matrix
0.576
0.266112
0.3836
0.1705
0.576
0.49
0.255
0.255
0.204
0.204
0.204
0.153
0.117
0.117
0.0975
0.00975
0.097
0.102
0.0507
0.01521
0.0254
0.04563
0.051
0.051
Weighted SUM
0.653322
0.7105
0.42988
0.928
0.796
Cost Per Cycle
$0.04
$0.12
$0.10
$0.14
$0.29
Weighted Utility
Scores
Weight
Gravimetric Energy
Density(Wh/kg)
Operating
Temperature Range
Fast Charge Time
Maintenance
Requirement

Lead Acid
$0.04
$0.12
$0.1
$0.14
$0.29
function/Cost Per Cycle)
0.65332
0.71043
0.42987
0.92816
0.79625
Cost Effectiveness
Function (Operational Utility
Cost Per Cycle
Effectiveness Matrix
Operational Utility
Function
Table 104. Effectiveness Scores
16.3331
5.92023
4.29872
6.62972
2.74569
222
Rankings
Table 105. Effectiveness Rankings
Effectiveness Rankings
1 Lithium-ion (Li-ion)
2
3
4
5
Cost Effectiveness Rankings

0.9282
0.7963
0.7104
0.6533
Lead Acid
0.4299
1
2
3
5
4
Nickel Cadmium
(NiCd)
16.3331
6.62972
(NiMH)
5.92023
Lead Acid
4.29872
LiPo (LithiumPolymer)
2.74569
223
Sensitivity Analysis
Gravimetric Energy
Density(Wh/kg)
Operating
Temperature Range
Fast Charge Time
Maintenance
Requirement
Lead Acid
(NiMH)
Utility Scores
Varied by 10%
Table 106. Utility Scores varied by 10 percent for sensitivity check
0.508
0.733
0.325
1.1
0.936
1.1
0.88
0.88
0.88
0.66
0.833
0.0833
0.833
0.875
0.3
0.5
0.9
Maintenance
Requirement
Varied Weighted SUM
Original Weighted Sum
Lead Acid
Fast Charge Time
(NiMH)
0.576
0.292608
0.422208
0.1872
0.6336
0.53914
0.255
0.2805
0.2244
0.2244
0.2244
0.1683
0.117
0.117
0.097461
0.0097461
0.097461
0.10238
0.0507
0.01521
0.02535
0.04563
0.0507
0.0507
0.705318
0.769419
0.4669761
1.006161
0.86051
0.653322
0.710427
0.4298721
0.928161
0.79625
Weighted Utility Scores

Sensitivity Check
Gravimetric Energy
Density(Wh/kg)
Operating
Temperature Range
Weight
224
Selection
The Lithium-ion (Li-ion) battery ranked the highest in effectiveness and second in cost
effectiveness. The lithium-ion battery has the highest power output per kilogram, the
second greatest in operational temperature Range -20 to 60C (-4 to 140F) and
requires zero maintenance. In addition, the Lithium-ion (Li-ion) battery ranked second in
cost effectiveness with an operating cost of 0.14 cents per cycle and has a cycle life
between 500 and1000 cycles.
A sensitivity analysis was performed by varying Gravimetric Energy Density (Wh/kg) and
Operating Temperature Range; the results did not change. The Lithium-ion (Li-ion)
battery is recommended as the battery to provide power to the ARV.
225
Risk Management
At the beginning of the SM4 Project, 5 risks were identified and subsequently tracked
throughout AFDIRTS development. Initial risks have been listed below:
1. If stakeholder interviews do not uncover all potential problems; or gather
enough information about the operating environment then these issues will
become more expensive to solve in the latter stages of AFDIRTS development;
because the design will be more complex and difficult to change.
2. If care is not taken to ensure traceability throughout system development,
then system architectural questions may go unanswered during the SM4
presentation; because a traceability matrix was unavailable.
3. If the triumvirate of conceptual design; as described by Kossiakoff et al. (2011,
p.175) is not applied to requirements analysis, then system requirements may be
developed as ambiguous and difficult to decompose into subordinate
requirements,; or just not make sense; because requirements analysis was not
properly performed.
4. If lessons learned are not documented as the project progresses, then they
may become difficult to recall during development of the final report; because
a lessons learned document was not available.
5. If the ATC interface requires too much of the controllers attention, it may
hinder their ability to control air/ground traffic; because they will be overtasked.
Risk Worksheets were developed along with one risk waterfall chart to aid in tracking
and documenting these initial risks.
226
Level
Likelihood
Probability of
Occurrence
Not Likely
~10%
Low likelihood
~30%
likely
~50
Highly Likely
~70
Near Certainty
~90
Consequence of Failure (C f )
Table 1. Risk Cube Definitions

5
4
3
2
1
1
Likelihood of Failure(L f )
Level
Performance/Technical
Schedule
Cost
Minimal or no impact
Minor
technical/performance
shortfall
Additional Activities required,

in order to meet key dates.
Slip < 1 week
Unit production cost

increase of <1% of Budget
Moderate
shortfall

Slip < 2 week

Major
shortfall

Slip > 2 weeks

Cannot meet Key

Performance Parameters
Will not be able to finish on

schedule

increase of >10% of Budget
227
Table 2. Design Flaw Risk Worksheet

Risk Summary Worksheet
Risk Number: R.1
Type:
Risk Title:
Design Flaws
Cost
Schedule
Performance
Description of Risk:
The AFDIRTS system concept does not address all
operational objectives; or some operational objectives
required to meet users needs go undocumented.
Consequence if Realized:
The systems specification could be submitted to
developers without necessary system specifications. This
can become an expensive fix later in system
development.
Suggested Mitigation/Avoidance/Acceptance Plan

Action/Event
Success Criteria
Risk Level if
Successful
Cf
Lf
Design and implement a user survey to poll

users, SMEs and stakeholders to elicit system
requirements.
Publish a survey on the Survey Monkey

Website and obtain at least 25
responses from users, SMEs and
stakeholders
Make contact with users and stakeholders and

keep in contact throughout the systems
engineering process.
Obtain at least 3 contacts that can be

reached at any time during concept
development for questions
228
Table 3. Traceability Risk Worksheet

Risk Number: R.2
Type:
Risk Title:
Need -> Objective ->
Requirement -> Function ->
Component Traceability
Cost
Schedule
Performance
Traceability is not maintained throughout concept
development.
The project schedule may be threatened because it will
require extra resources to incorporate tractability in the
end.

Action/Event
Learn to use CORE.
Save a different copy of CORE after
each day of work on the SM4 project
Success Criteria
All CORE videos developed by
Christopher Olson have been
watched.
At the end of each workday, the
project has been exported under
the filename date_Roig.
Risk Level if
Successful
Cf
Lf
229
Table 4. ATC Interface Risk Worksheet

Risk Number: R.3
Type:
Risk Title:
ATC interface
Cost
Schedule
Performance
The ATC interface is designed to be too complex and
requires too much of the controllers attention.
The complexity of the ATC interface may hinder Air Traffic
Controllers ability to control air/ground traffic because
they will be distracted. This could lead to ground or air
incursions.

Action/Event
The ATC interface shall be designed with
simplicity in mind; giving ATC the option of
normal or emergency operation only.
Success Criteria
The ATC interface design shall
provide only two options for ATC
to select. Additionally, the
interface shall be evaluated
utilizing Usability Heuristics for
User Interface Design developed
by Jakob Nielsen and zero
usability problems shall be
discovered.
Risk Level if
Successful
Cf
Lf
230
Table 5. Lessons Learned Risk Worksheet

Risk Number: R.4
Type:
Risk Title:
Cost
Schedule
Performance
Lessons learned are not documented as the project
progresses.
They may become difficult to recall during development
of the final report.

Action/Event
Date
Scheduled
Success Criteria
Actual
Risk Level if
Successful
Cf
Lf
Risk was accepted.
231
Table 6. Substandard Requirements Risk Worksheet

Risk Number: R.5
Type:
Risk Title:
Cost
Schedule
Performance
Substandard Requirements
System requirements are ambiguous, difficult to
understand or difficult to decompose into subordinate
requirements.
The development of inadequate requirements may lead
to a system that does not meet users needs.

Risk Level if
Successful
Cf
Lf
3
4
Action/Event
Success Criteria
Contact SMEs, Users and Stakeholders to

vet initial Operational Objectives.
Contact at least 5 SMEs, Users and

Stakeholders to discuss initial
Operational Objectives.
Apply the triumvirate of conceptual

design to Operational Requirements to
ensure that the Why interrogative is
accurately applied and incorporated into
initial Operational Requirements.
All Operational Requirements

answer the why question.
Develop a survey to poll Users, SMEs and

Stakeholders.
A survey is developed on
SurveyMonkey and at least 25
Users, SMEs and Stakeholders
participate.
2.5
Analyze performance requirements to

ensure they are implementation free as
well as answer the how much question.
All performance requirements have

the ability to be verified by analysis
or testing and they answer the how
much question.
Functional and Physical diagrams are

developed to assist in the development of
system specifications.
Functional and Physical diagrams

are documented in CORE.
232
Table 6. AFDIRTS Substandard/Inaccurate Requirements Risk Waterfall Worksheet

Risk# R.5
Title: Inadequate Requirements
Mitigation Strategies
1. Made contact with potential users to

define operational objectives and
developed potential system concepts.
Likelihood of Failure (L f )
2
3
4
5
6
2. Initial Operational Requirements were

derived from Operational Objectives.
SMEs, Users and Stakeholders were
contacted to vet initial Operational
Requirements.
Conceptual Design Report

A-Spec
Final Report
Oral Report
4. A survey was developed on the

SurveyMonkey web platform that
polled 28 Users, SMEs and Stakeholders
to obtain accurate and attainable
performance requirements.
5. Performance requirements were
reviewed that they could be verified by
analysis or testing and they answered
the how much question.
6. Functional and Physical diagrams
were developed which were utilized to
help develop system specifications.
Concept
Validation
Functional Analysis Report

Trade Study
Concept
Selection
Functional
Analysis and
Formulation
Performance
Requirements
Analysis
Performance
Requirements
Validation
Implementation
Concept
Exploration
Performance
Requirements
Formulation
Operational
Requirements
Analysis
Needs Validation
Feasibility
Definition
Functional
Analysis
Operational
Analysis
Project Proposal
Requirements Analysis Report
3. The triumvirate of conceptual design

was applied to the Operational
Requirements to ensure that the Why
interrogative was accurately applied
and incorporated into initial Operational
Requirements.
233
AFDIRTS System Specification

Table 108. Requirements
Type
Number
Composite
Functional
18
Performance
93
Programmatic
Total
124
Figure 83. Requirements Pie Chart
Programmatic, 7
Composite, 6
Functional, 18
Performance, 93
234

Table 109. Quantitative vs Qualitative
Type
Number
Qualitative
Binary
19
Quantitative
96
Total
124
Figure 84. Requirement Type Pie Chart
Qualitative
7%
Binary
15%
Quantitative
78%
235
Table 110. AFDIRTS System Requirements

Number Name
Type
Description
Metric
Verified By
R.1.1
Reliability
Composite
The AFDIRTS System shall be designed to perform

its intended functions with a reliability of 99.0%
over its total life The total life of the AFDIRTS
system shall be a minimum of 20 years (excluding
consumable parts).
Quantitative
Analysis
R.1.2
System Availability
Performance
The AFDIRTS System should have an Operational

Availability (AO) of 99.7% over its 20 Year life.
Quantitative
Analysis
R.1.3
System
Maintainability
Performance

its intended functions for its total life (20 Years)
when maintained according to the
manufacturers instructions.
Quantitative
Analysis
R.1.4
Electromagnetic
Interference
Performance
The AFDIRTS must meet the current issues of radio

suppression specification MIL-STD-461, Class 3D,
Requirements for the Control of Electromagnetic
Interference Emissions and Susceptibility. It must
be capable of operating through the entire
amplitude modulated aircraft radio frequency
range of 75 MHz 136 MHzs.
Quantitative
Test
R.1.5
Equipment Located
Outside of Paved
Surfaces
Programmatic
AFDIRTS equipment located outside of paved

surfaces shall be designed and built so
maintenance personnel can still access them.
Binary
Demonstration
236

Number Name
Type
Description
Metric
Verified By
R.1.6
Installation and
Acceptance
Standards
Composite
The AFDIRTS system shall conform to applicable

airport obstruction criteria, marking and lighting,
and equipment design and installation standards.
Binary
Inspection
R.1.7
Breakaway
Connector
Constraint
AFDIRTS elements located near the runway and

within the runway safety area shall be connected
through a connector that will disconnect upon
impact with the system.
Binary
Inspection
R.1.8
Wind Loading
Constraint
AFDIRTS elements located near the runway shall

withstand a wind loading of 300 mph. (483 km/h)
Quantitative
Test
R.1.9
Performance in
Rain
Performance
The AFDIRTS system shall be capable of detecting

objects under rainfall conditions having a specific
intensity, duration, and frequency for a two-year
category of storm in the local region (as specified
in CLIM 20, Climatology of the United States No.
20).
Quantitative
Test
R.1.10
Performance in
Snow
Performance

objects under snow conditions having a specific
20).
Quantitative
Test
R.1.11
Performance in
Wind
Performance
The AFDIRTS shall be capable of operating in

wind conditions up to 25 MPH with gusts up to
30MPH.
Quantitative
Test
237

Number Name
Type
Description
Metric
Verified By
R.1.12
Maintenance
Procedures
Programmatic
Quantitative
Analysis
R.1.13
Cleaning
Procedures
Programmatic
An operators handbook, illustrated parts

breakdown and preventive maintenance
schedule shall be developed and included with
the AFDIRTS system.
Written documentation on recommended
cleaning procedures, including solvent types and
tools shall be developed.
Qualitative
Analysis
R.1.14
Preventative
Maintenance
Procedures
Programmatic

preventive maintenance actions shall be
developed.
Qualitative
Analysis
R.1.15
Recalibration Plan
Programmatic
Written calibration and recalibration procedures

shall be developed so that FOD detection and
retrieval performance specifications can be
maintained for 20 Years.
Quantitative
Analysis
R.1.16
Scheduled
Component
Removals
Programmatic
Written documentation on scheduled

component removal timelines shall be
developed.
Qualitative
Analysis
R.1.17
Call Center
Programmatic
Quantitative
Demonstration
238
FAA AC 150/5210-24
Airport Foreign Object
Debris (FOD)
Management
FAA AC 150/5220-24
Debris (FOD) Detection
Equipment
User Interviews
Requirements
User Surveys
Table 111. AFDIRTS System Requirement Origin Map
R.1.1 Reliability
R.1.4 Electromagnetic Interference
R.1.5 Equipment Located Outside of Paved Surfaces
R.1.6 Installation and Acceptance Standards
R.1.7 Breakaway Connector
R.1.8 Wind Loading
239
FAA AC 150/5210-24
Debris (FOD)
Management
Name
Type
Basis of
Description
Metric
Verified By
R.1.18
LINK.1.2
ATC -> AUI
Performance
F.1.9 Interface
with Air Traffic
Control
T The ATC -> AUI Human Machine

Interface shall allow Air Traffic Controllers
to select Normal or Emergency Modes of
operation as well as advising ATC of
AFDIRTS system health. The AIU shall be
evaluated utilizing Usability Heuristics for
User Interface Design developed by
Jakob Nielsen and zero usability
problems shall be discovered.
Quantitative
Analysis
Requirements
User Interviews
Number
User Surveys
FAA AC 150/5220-24
Equipment
R.1.13 Cleaning Procedures

R.1.14 Preventative Maintenance Procedures
R.1.15 Recalibration Plan
R.1.16 Scheduled Component Removals
R.1.17 Call Center
Table 112. AFDIRTS External Interface Specifications
240
R.1.19
LINK.5.9
External
Power ->
Power
Transfer
Panel
Performance
F.5.4 Transfer
Power
The External Power -> Power Transfer

Panel external interface shall be
capable of transferring 120/240V singlephase AC power from the external
source to the transfer panel. The wire
gauge utilized will be dependent upon
total system current.
Quantitative
Test
241
Table 113. Command and Control Segment Requirements

Number
Name
Type
Basis of
Description
Metric
Verified By
R.2
AFDIRTS
Command and
Control
Functional
F.1 Command and

Control System
The AFDIRTS shall be capable

of centralized command and
control of all system elements.
Qualitative
Test
R.2.1
(KPP)
Power Failure
Performance
F.1.11 Restore
System
In the event of a power

failure, AFDIRTS must have the
capability to automatically
power-up and operate in the
condition and settings that
were available just prior to the
power failure.
Binary
Test
R.2.2
Navigation Data
Functional
F.1.7 Transmit
Inbound Aircraft
Data to System
Elements

of transmitting inbound
aircraft data to the Air
Retrieval Vehicle (ARV) with
100% accuracy.
Quantitative
Test
R.2.3
Navigation Modes
Functional
F.1.2 Initiate System

Modes
F.1.3 Transmit
Normal Operation
Command F.1.4
Transmit
Emergency
Command
The command and control

subsystem shall be capable of
transmitting the normal
operation command to the
Air Retrieval Vehicle (ARV).
Binary
Test
R.2.4
AFDIRTS
Communication
Composite
F.1.1 Interface with

ATC
The Command and Control

Subsystem shall provide a
method of interfacing with Air
Qualitative
Demonstration
242

Number
R.2.5
Name
Command and
Control Segment
Specification
Type
Performance
Basis of
Description

Airport Managers
Maintenance
Personnel
Traffic Control, Airport

Management, and System
Maintainers.
F.1 Command and

Control System

segment shall be capable of
transmitting data to system
elements with 99.9% reliability.
Metric
Verified By
Quantitative
Test
FAA AC 150/5210-24
Debris (FOD)
Management
FAA AC 150/5220-24
Equipment
User Interviews
Requirements
User Surveys
Table 114. Command and Control Segment Requirement Origin Map
R.2 AFDIRTS Command and Control

R.2.1 Power Failure (KPP)
243

R.2.4 AFDIRTS Communication
R.2.5 Command and Control Segment Specification
Table 115. Command and Control Subsystem Specifications

Number
Name
Type
Basis of
Description
Metric
Verified By
R.2.5.1
COMP.1.2
ATC Interface
Unit (AIU)
Specification
Performance
F.1.1
Interface
with ATC
The ATC Interface Unit (AIU) shall be

capable of allowing ATC to select Normal
or Emergency Modes of operation as well
as advising ATC of AFDIRTS system health.
The AIU shall be evaluated utilizing the
heuristic evaluation developed by Jakob
Nielsen. If usability problems are
discovered they shall not receive a
usability severity rating of greater than 1.
Quantitative
Demonstration
R.2.5.2
COMP.1.1
Airport
Management
Display Unit
(AMDU)
Specification
Performance
F.1.9
Interface
with Airport
Managers
The Airport Management Display Unit

(AMDU) shall be capable of notifying
airport personnel of unsuitable FOD
location data and AFDIRTS system health
data. The AMDU shall be evaluated
utilizing the heuristic evaluation
developed by Jakob Nielsen. If usability
problems are discovered they shall not
receive a usability severity rating of
greater than 1.
Quantitative
Demonstration
244

Number
Name
Type
Basis of
Description
Metric
Verified By
R.2.5.3
COMP.1.3
Command
and Control
CPU
Specification
Performance
F.1.2 Initiate
System
Modes
The Command and Control Computer

shall be capable of performing at a
minimum of 700,000,000 clock cycles per
second (700Mhz)
Quantitative
Test
R.2.5.4
COMP.1.6
Command
and Control
Data Link
Specification
Performance
F.1.7 Transmit
Inbound
Aircraft Data
to System
Elements
Quantitative
Test
R.2.5.5
COMP.1.7
Maintenance
User Interface
(MIU)
Specification
Performance
F.1.10.2
Display
Maintenance
Data
The command and control data link shall

comply with WP-2, Command and
Control (C2) Data Link White Paper Issued
03-18-14 that contains Minimum
Operational Performance Standards
(MOPS) for Unmanned Aircraft System
(UAS) Command and Control Data Links.
The MIU shall be capable of accepting
self-test commands from maintenance
personnel as well as displaying self-test
results and faults in critical/non-critical
subsystems. The MIU shall be evaluated
utilizing the usability heuristic evaluation
greater than 1.
Quantitative
Test
R.2.5.6
COMP.1.4
Backup CPU
Specification
Performance
F.1.11 Restore
System
The back-up command and control

computer shall be capable taking over in
the event of main computer failure. The
back-up command and control
computer shall be capable of performing
a minimum of 700,000,000 clock cycles
per second (700Mhz).
Quantitative
Test
245

Number
Name
Type
Basis of
Description
Metric
Verified By
R.2.5.7
COMP.1.3.1
Command
and Control
Software
Specification
Performance
F.1
Command
and Control
System
The Command and Control software shall

contain the instructions that allow the
AFDIRTS to command and control AFDIRTS
system elements as per AFDIRTS system
requirements. Command and Control
Software shall achieve a Design
Assurance Level (DAL) of A IAW DO178C, Software Considerations in Airborne
Systems and Equipment Certification from
RTCA Inc.
Quantitative
Test
Table 116. Command and Control Internal Interfaces

Number
Name
Type
Basis of
Description
Metric
Verified By
R.2.6
LINK.1.5
Iferret ->
AMDU Link
Specification
Performance
F.1.9
Interface
with Airport
Managers
The Iferret -> AMDU Data Link shall meet

the current issues of radio suppression
specification MIL-STD-461, Class 3D,
Requirements for the Control of
Electromagnetic Interference Emissions
and Susceptibility. It must be capable of
operating through the entire amplitude
modulated aircraft radio frequency range
of 75 MHz 136 MHzs
Quantitative
Demonstration
246
Table 117. System Health and Monitoring Segment Requirements

Number
Name
Type
Basis of
Description
Metric
Verified By
R.3
Safe
Operation
Composite
F.2 Operate Safely
The system shall not cause

damage to airport personal or
property; nor shall it become a
distraction to operations or
support personnel.
Qualitative
Demonstration
R.3.1
ATC
Emergency
Control
Performance
F.4.2 Navigate Airfield
Air Traffic Control shall be

capable of initiating an
emergency mode of operation
that removes all Air Retrieval
Vehicles from airfield operating
Quantitative
Test
R.3.2
Self-Test
Functional
The system shall be capable

self-testing non-critical
subsystems.
Binary
Demonstration
R.3.3
Self-Test
Duration
Performance
The self-test duration on mobile

system elements should not
exceed 30 seconds.
Quantitative
Test
R.3.4
Maintainer
Self-Test
Functional
System maintenance personnel

shall be capable of initiating a
self-test on both stationary and
mobile system elements.
Binary
Test
R.3.5
System
Health
Specification
Functional
F.2.2 Monitor the Health

of Stationary Element
Critical Subsystems
The AFDIRTS shall be capable of

automatically detecting faults in
critical subsystems, provide users
with data regarding faults in
Binary
Demonstration
Test
247

of Mobile Element
Critical Components
F.2.5 Compensate for
Critical Components
F.2.6 Provide Airport
Managers with System
Health Data
F.2.7 Provide ATC with
System Health Data
F.2.8 Provide
with System Health
Data
non-critical subsystems, and

compensate for failures in ARV
critical subsystems until the ARV
can navigate to designated
emergency landing areas.
FAA AC 150/5210-24
Debris (FOD)
Management
FAA AC 150/5220-24
Equipment
User Interviews
Requirements
User Surveys
Table 118. System Health and Monitoring Segment Requirement Origin Map
R.3 Safe Operation

R.3.1 Emergency (KPP)
R.3.2 Self-Test
248
FAA AC 150/5210-24
Debris (FOD)
Management
FAA AC 150/5220-24
Equipment
Requirements
User Interviews
User Surveys
R.3.3 Self-Test Duration

R.3.4 Maintainer Self-Test
R.3.5 System Health
Table 119. System Health and Monitoring Segment Subsystem Specifications

Number
Name
Type
Basis of
Description
Metric
Verified By
R.3.5.1
COMP.2.4
Command and
Control
Interface Unit
(CCIU)
specification
Performance
F.2.6 Provide
Airport
Managers with
System Health
Data
F.3.2 Determine
FOD Suitability
from a
Distance
F.4.3.2 Notify
Personnel of
Object too
The CCIU shall be capable of

providing airport managers with
AFDIRTS system health data as well as
the location of FOD Irretrievable by
automated system elements. The
AMDU shall be evaluated utilizing the
heuristic evaluation developed by
Jakob Nielsen and receive no
usability severity rating greater than
1.
Quantitative
Analysis
249

Number
Name
Type
Basis of
Description
Metric
Verified By
Large for
Retrieval
F.4.3.5 Notify
Personnel of
Overweight
Objects
R.3.5.2
COMP.2.2
System Health
Computer
(SHC)
Specification
Performance
F.2.2 Monitor
the Health of
Stationary
Element
Critical
Subsystems
The system health computer shall be

capable of performing at a minimum
of 700,000,000 clock cycles per
second (700Mhz)
Quantitative
Test
R.3.5.3
COMP.2.1
System Health
Data Link (SHR)
Specification
Performance
F.2.1 Receive
Telemetry
Signal From
Stationary
Elements
F.2.3 Receive
Telemetry Data
from Mobile
Elements
The System Health Data Link shall

operate on a frequency that does
not interfere with airport operations
and shall perform at a level greater
than or equal to 99.8% reliability at 10
years of its service life.
Quantitative
Demonstration
R.3.5.4
COMP.2.2.1
System Health
Software
Specification
Performance
F.2.4.1 Direct
SHC operation
The System Health Software shall

AFDIRTS to monitor system health and
execute self-test instructions as per
system requirements. System Health
Assurance Level (DAL) of A IAW
DO-178C, Software Considerations in
Quantitative
Test
250

Number
Name
Type
Basis of
Description
Metric
Verified By
Airborne Systems and Equipment

Certification from RTCA Inc.
Table 120. System Health and Monitoring Segment Internal Interfaces

Number
Name
Type
Description
Metric
Verified By
R.3.5.5
L.INK.2.2
SHR -> SHC
Internal Interface
Requirement
Performance
The SHR -> SHC interface shall be

capable of transferring data at
minimum of 1 gigabit per second
(Gbps).
Quantitative
Test
251
Table 121. FOD Detection Segment Requirements

Number Name
Type
Basis of
Description
Metric
Verified By
R.4
FOD
Detection
Segment
Composite
F.3 Scan
Airfield for
FOD
The FOD Detection segment shall be

capable of detecting FOD items on the
airfield and reporting its location to
system elements.
Binary
Demonstration
R.4.1.1
FOD
Location
Reporting
Performance
Location reporting shall be accurate to

within 16 ft. (5.0 m) of the actual FOD
object location.
Quantitative
Test
R.4.1.2
Suitability
Reporting
Performance
F.3.3
Determine
Location of
FOD
F.4.3.2 Notify
Personnel of
Object too
Large for
Retrieval
The system shall be capable of notifying

airport personnel of FOD unsuitable for
automated retrieval (such as animal
carcasses) with GPS coordinates
accurate to within 16 ft. (5.0 m) of the
actual FOD location.
Quantitative
Demonstration
R.4.1.3
FOD
Detection
Performance
F.3.1 Detect
FOD
The system shall be capable of detecting

single and multiple FOD items on the
AOA.
Binary
Test
R.4.1.4
Group
Object
Detection
Performance
F.3.1 Detect
FOD
The system shall have the ability to

detect 90 percent of the following group
of objects when placed within a 100 ft.
by 100 ft. (30 m by 30 m) square in the
desired coverage area. One item from
each category must be included in the
group and each item must measure no
larger than 4 in (10 cm) in any dimension
unless otherwise specified: A chunk of
Quantitative
Test
252

Number Name
Type
Basis of
Description
asphalt or concrete, Any portion of a
runway light fixture (in-pavement or
edge light), An adjustable crescent
wrench up to 8 in. (20 cm) in length), A
deep socket (at least 2 in. (5 cm) in
length), A piece of rubber from an
aircraft tire, A distorted metal strip (up to
8 in. (20 cm) in length), Fuel cap (aircraft
or automotive), Lug nut, Hydraulic line
(from aircraft or GSE, up to 8 in. (20 cm)
in length).
detect an unpainted, metal cylinder,
measuring 1.2 in (3.1 cm) high and 1.5 in
(3.8 cm) in diameter.
Metric
Verified By
Quantitative
Test
R.4.1.5
Metal
Cylinder
Detection
Performance
F.3.1 Detect
FOD
R.4.1.6
Sphere
Detection
Performance
F.3.1 Detect
FOD

detect a white, grey, or black sphere,
Quantitative
Test
R.4.1.7
Lighting
Conditions
Performance
F.3.1 Detect
FOD
The system shall demonstrate detection

performance during daylight, nighttime,
Qualitative
Test
R.4.1.8
Automated
Retrieval
Suitability
Functional
F.3.2
Determine
FOD Suitability
from a
Distance
The system shall be capable of

determining items unsuitable for
carcasses) based upon physical
characteristics.
Qualitative
Test
253

Number Name
Type
Basis of
Description
Metric
Verified By
R.4.1.9
Performance
F.3.1 Detect
FOD

FOD within 4 minutes of a FOD
occurrence.
Quantitative
Demonstration
Detection
Time
FAA AC 150/5210-24
Debris (FOD)
Management
FAA AC 150/5220-24
Equipment
User Interviews
Requirements
User Surveys
Table 122. FOD Detection Segment Requirement Origin Map
R.4.1.1 FOD Location Reporting

R.4.1.3 FOD Detection
254

Table 123. FOD Detection Segment Subsystem Specifications

Number
Name
Type
Basis of
Description
Metric
Verified By
R.4.1.10
COMP.3.1
IFerret
Specification
&AFDIRTS
Interface
Unit
Performance
F.3 Scan
Airfield for
FOD
The IFerret system is a COTS subsystem that shall

be capable of interfacing with the AFDIRTS.
Binary
Demonstration
Table 124. FOD Detection Segment Internal Interface Specifications

Number
Name
Type
R.4.1.11
LINK.3.1
IFerret &
AFDIRTS
Interface
Unit <-> NAV
Radio
Internal
Interface
Specification
Performance
Basis of
Description
Metric
The IFerret & AFDIRTS Interface Unit <-> NAV

Radio Internal Interface shall comply with
current issues of radio suppression specification
MIL-STD-461, Class 3D, Requirements for the
Control of Electromagnetic Interference
Emissions and Susceptibility. The interface must
range of 75 MHz 136 MHzs and have the
ability to transfer data a minimum of 3 miles.
Quantitative
Verified
By
Test
255
Table 125. Air Retrieval Vehicle (ARV) Segment Requirements

Number
Name
Type
Description
Metric
R.5.1.1

Dimensions
Performance
The air vehicle subsystem shall be no larger than (L x W x

H): 38L x 38.5W x 22H (excluding VERSABALL Gripper).
Quantitative
Verified
By
Analysis
*Units in inches
R.5.1.2
Maximum All-Up
Weight (AUW)
Performance
The ARV subsystem shall weigh no more than 39lbs.
Quantitative
Analysis
R.5.1.3
MAX Operational
Flight Time
Performance
The ARV subsystem shall have a MAX Operational flight

time of at least 10 min.
Quantitative
Test
R.5.1.4
MAX Forward Speed
Performance
The ARV subsystem shall have a MAX forward speed of

at least 45 MPH.
Quantitative
Test
R.5.1.5
MAX Operating
Wind Speed
Performance
The ARV Subsystem MAX Operating Wind Speed 30MPH.
Quantitative
Test
256
FAA AC 150/5210-24
Debris (FOD) Management
FAA AC 150/5220-24
Equipment
SME Interviews
User Surveys
Requirements
STEDI DRONE VADER X8
Table 126. Air Retrieval Vehicle (ARV) Segment Requirement Origin Map
R.5.1.1 Air Retrieval Vehicle Dimensions

R.5.1.2 Maximum All-Up Weight (AUW)
R.5.1.3 MAX Operational Flight Time
R.5.1.4 MAX Forward Speed
R.5.1.5 MAX Operating Wind Speed
257

Table 127. Air Retrieval Vehicle (ARV) Subsystem Specifications
Number
Name
Type
Basis of
Description
Metric
Verified By
R.5.1
COMP.4
Air Retrieval
Vehicle
Composite
F.4 Transport
Retrieval
Subsystem (ARV)
The air vehicle subsystem shall

provide a method of lift that is
capable of lifting one pound of FOD
(.7 Kilograms) moving at 20mph (30
km/h) with 1 motor not spinning.
Quantitative
R.5.2
COMP.4.1
Movement
and Control
Subsystem
Specification
Performance
F.4.1 Move and

Control ARV
The Movement and Control

Subsystem shall be capable of
providing a minimum of 80 pounds
of thrust with the ability to keep the
ARV stable in 30MPH winds and
have a reliability of 99.8% over 5000
hours of use. If the Movement and
Control Subsystem should fail it shall
fail in a manner that allows the ARV
to reach designated emergency
areas.
Quantitative
Demonstration
Test
R.5.3
COMP.4.2
Navigation
Subsystem
Functional
F.4.2 Navigate
Airfield
F.4.2.2 Process
Navigation
Commands
F.4.2.3 Detect
Obstacles
F.4.2.5 Receive
Aircraft
Trajectory Data
from ATC F.4.2.6
Anticipate
Mobile system elements shall be

capable of navigating the airfield
with 0 input from humans.
Quantitative
Demonstration
Test
258

Number
Name
Type
R.5.4
COMP.4.3
Power
Subsystem
Performance
R.5.5
COMP.4.4
FOD Retrieval
Subsystem
Functional
Basis of
Obstacle
Movement
F.4.2.7 Determine
Path Around
Obstacles
F.4.2.8 Determine
Location
F.4.4 Provide ARV
Electrical Power
F.4.3 Retrieve
FOD
F.4.3.5 Notify
Personnel of
Overweight
Objects
Description
Metric
Verified By
The Power Subsystem shall be

capable of storing a minimum 40Ah
of electric charge and be capable
of delivering a minimum of 500
Amps of continuous discharge to
the electronic speed controllers
whom shall be capable of receiving
a minimum of 500 Amps @ 18.5 volts
from the battery. All subsystems
receiving electricity from the battery
shall have zero noise induced into
the subsystems as a result of electric
motor operation.
Quantitative
Test

autonomously retrieving FOD from
paved surfaces.
Binary
Demonstration
259

Table 128. Air Retrieval Vehicle (ARV) Movement and Control Subsystem Requirements
Number Name
Type
Description
Metric
Verified By
R.5.2
Performance
The Movement and Control Subsystem shall be

capable of providing a minimum of 80 pounds
of thrust with the ability to keep the ARV stable
in 30MPH winds and have a reliability of 99.8%
over 5000 hours of use. If the Movement and
Control Subsystem should fail it shall fail in a
manner that allows the ARV to reach
designated emergency areas.
Quantitative
Demonstration
Test
Movement
and Control
Subsystem
Specification
FAA AC 150/5210-24
FAA AC 150/5220-24
Equipment
SME Interviews
User Surveys
Requirements
Table 129. Air Retrieval Vehicle (ARV) Movement and Control Subsystem Requirement Origin Map
R.5.1.1 Movement and Control Subsystem Specification
260

Table 130. Air Retrieval Vehicle (ARV) Movement and Control Subsystem Specifications
Number
Name
Type
Basis of
Description
Metric
R.5.1.1
COMP.4.1.3
COMP.4.1.4
COMP.4.1.5
COMP.4.1.6
COMP.4.1.7
COMP.4.1.8
COMP.4.1.9
COMP.4.1.10
Electric Motor
Specification
Performance
F.4.1.3 Spin #1 Propeller

F.4.1.12 Spin #4
Propeller
F.4.1.15 Spin #5
Propeller
F.4.1.17 Spin #6
Propeller
F.4.1.20 Spin #7
Propeller
F.4.1.23 Spin #8
Propeller
The ARV electric motor electric

shall weigh no more than 9 oz.
and be capable of spinning a
26x8.5 prop at 1850 RPM at 18.5
volts +/- 10%. The motor shall
have an operating power rating
of at least 750W for 3 minutes.
Quantitative
Verified
By
Test
R.5.1.2
COMP.4.1.11
COMP.4.1.12
COMP.4.1.13
COMP.4.1.14
COMP.4.1.15
COMP.4.1.16
COMP.4.1.17
COMP.4.1.18
Electronic
Speed
Controller
Specification
Performance
F.4.1.2 Control #1
Motor Speed
F.4.1.5 Control #2
Motor Speed
F.4.1.8 Control #3
Motor Speed
F.4.1.11 Control #4
Motor Speed
F.4.1.14 Control #5
Motor Speed
F.4.1.17 Control #6
Motor Speed
F.4.1.20 Control #7
Motor Speed
The electronic speed controllers

shall be capable of providing a
minimum of 18.5 volts @ 40 Amps
to the electric motors and weigh
no more than 1.5 oz.
Quantitative
Test
261

Number
Name
Type
Basis of
Description
Metric
F.4.1.23 Control #8
Motor Speed
Verified
By
R.5.1.3
COMP.4.1.19.1
MCCOMP
Software
Specification
Performance
F.4.1.1 Carry out

Instructions
The MCCOMP Software shall

contain the instructions that allow
the movement and control
subsystem to best meet system
requirements. The MCCOMP
software shall achieve a Design
DO-178C, Software
Considerations in Airborne
Systems and Equipment
Quantitative
R.5.1.4
COMP.4.1.25
COMP.4.1.25
COMP.4.1.25
COMP.4.1.25
Propeller
Specification
Performance
F.4.1.16 Generate #5
Motor Thrust
Motor Thrust
Motor Thrust
Motor Thrust
The ARV counter spinning

propeller shall be made of
carbon fiber, have a length
between 26 and 28 inches and a
pitch of between 8.5 and 9.2
degrees.
Quantitative
Inspection
R.5.1.5
COMP.4.1.21
COMP.4.1.22
COMP.4.1.23
COMP.4.1.24
Pusher
Propeller
Specification
Performance
F.4.1.4 Generate #1
Motor Thrust
F.4.1.7 Generate #2
Motor Thrust
Motor Thrust
Motor Thrust
The ARV clockwise spinning

propeller (Pusher) shall be made
of carbon fiber, have a length
degrees.
Quantitative
Inspection
Test
262

Number
Name
Type
Basis of
Description
Metric
Verified
By
R.5.1.7
COMP.4.1.19
Movement
and Control
Computer
(MCCOMP)
Specification
COMP.4.1.20
Movement
and Control
GPS Unit
(MCGPS)
Specification
Performance
F.4.1.1 Carry out

Instructions
The movement and control

computer shall be capable of
performing at a minimum of
700,000,000 clock cycles per
second (700Mhz).
Quantitative
Test
Performance
F.4.1.26 Determine GPS

Location
The movement and control GPS

shall provide horizontal and
vertical coordinates to the
movement and control
subsystem. It shall comply with all
specifications listed in RTCA Inc.
DO-316 Minimum Operational
Performance Standards for
Global Positioning System/Aircraft
Base Augmentation Systems. The
Movement and Control GPS shall
achieve a minimum of 7.8 meter
accuracy at a 95% confidence
interval.
Quantitative
Test
R.5.1.8
Table 131. Air Retrieval Vehicle (ARV) Movement and Control Subsystem Internal Interface Specification
Number
Name
Type
Description
Metric
R.5.1.6
LINK.4.1.18
ESC1 -> EM1 Internal
Interface Requirement
Performance
The ESC1 -> EM1 interface shall carry up to 18.5

Volts DC at a maximum of 40 amps equating. To
safely accommodate this amperage the wire
length shall be no longer than 4 feet with a wire
gauge of no less than 8 AWG.
Quantitative
Verified
By
Inspection
263
Table 132. Air Retrieval Vehicle (ARV) Navigation Subsystem Requirements

Number
Name
Type
Description
Metric
Verified By
R.5.2
Mobile Unit
Navigation
Functional
Mobile system elements shall be capable of

navigating the airfield with no input from humans.
Binary
Demonstration
R.5.2.1
Mobile Unit Speed
Performance

operating on the AOA at a speed of no less than 20
mph (30 km/h).
Quantitative
Demonstration
R.5.2.2
(KPP)
Mobile Unit
Movement
Clearance
Performance
The system shall be capable of detecting,

anticipating movement and avoiding all airport
traffic with 0 input from air traffic control.
Quantitative
Demonstration
R.5.2.2.1
Separation from
Obstacles
Performance
Mobile system elements shall maintain a minimum of

ten foot (3.05 meters) separation from all obstacles.
Quantitative
Test
R.5.2.2.2
Separation from
Aircraft
Performance

a minimum of fifty feet (15.24 meter) separation from
all aircraft and remain clear of jet blast.
Quantitative
Test
R.5.2.2.3
Separation from
Personnel
Performance

fifty foot (15.24 meter) separation from all personnel.
Quantitative
Test
R.5.2.2.4
Separation from
Vehicles
Performance
Mobile system elements shall maintain a minimum 25

foot (7.6 meter) separation from all support vehicles.
Quantitative
Test
R.5.2.3
Emergency
Posture
Functional

navigating to predefined emergency locations
defined by airport managers.
Binary
Demonstration
264

Number
Name
Type
Description
Metric
Verified By
R.5.2.4
FOD Location
Functional

navigating to detected FOD location.
Binary
Demonstration
R.5.2.5
Navigation
Commands
Functional
The Navigation subsystem shall be capable of

receiving and processing navigation commands
from air traffic control.
Binary
Demonstration
R.5.2.6
Disposal Area
Functional
The navigation subsystem shall be capable of

navigating to FOD disposal areas.
Binary
Test
FAA AC 150/5210-24 Airport

Foreign Object Debris (FOD)
Management

Detection Equipment
User Interviews
Requirements
User Surveys
Table 133. Air Retrieval Vehicle (ARV) Navigation Subsystem Requirement Origin Map

R.5.2.1 Mobile Unit Speed
R.5.2.2 Mobile Unit Movement Clearance (KPP)
R.5.2.2.1 Separation from Obstacles
265

Management

Detection Equipment
Requirements
User Interviews
User Surveys
R.5.2.2.2 Separation from Aircraft

R.5.2.2.3 Separation from Personnel
R.5.2.2.4 Separation from Vehicles
R.5.2.5 Navigation Commands
R.5.2.6 Disposal Area
Table 134. Air Retrieval Vehicle (ARV) Navigation Subsystem Specifications

Number
Name
Type
Basis of
Description
Metric
R.5.2.8
COMP.4.2.1
NAV Computer
Specification
Performance
F.4.2.2 Process
Navigation
Commands
The NAV computer shall be capable of

700,000,000 clock cycles per second
(700Mhz).
Quantitative
Verified
By
Test
266

Number
Name
Type
Basis of
Description
Metric
R.5.2.9
COMP.4.2.4
NAV GPS
Specification
Performance
F.4.2.8 Determine
Location
Quantitative
R.5.2.10
COMP.4.2.3
NAV RADAR Unit
Specification
Performance
F.4.2.4 Determine
Obstacle
Location
The NAV GPS shall be capable of

compiling with all specifications listed in
RTCA Inc. DO-316 Minimum
Operational Performance Standards for
Global Positioning System/Aircraft Base
Augmentation Systems. The NAV GPS
shall achieve a minimum of 7.8
horizontal meter accuracy at a 95%
confidence interval.
The ARV NAV RADAR Unit shall operate
between 110 and 300 Ghz (millimeterband) a resolution capable of
detecting aircraft, obstacles, humans,
and animals in the vicinity (100 feet) of
the ARV. The ARV NAV RADAR Unit shall
not interfere with any existing airport or
aircraft avionic systems.
Verified
By
Test
Quantitative
Test
R.5.2.11
COMP.4.2.5
NAV Radio
Specification
Performance
F.4.2.1 Receive
Navigation
Command
F.4.2.5 Receive
Aircraft Trajectory
Data from ATC
The ARV NAV Radio shall meet the

current issues of radio suppression
and Susceptibility. It must be capable
of operating through the entire
amplitude modulated aircraft radio
frequency range of 75 MHz 136 MHzs
Quantitative
Test
R.5.2.12
COMP.4.1.1
Attitude and
Heading
Performance
F.4.1.27 Determine
Position in Space
The ARV AHARS shall be capable of

determining acceleration, angular
rate, magnetic field, ambient pressure,
DeltaTheta and DeltaVelocity. The
Quantitative
Test
267

Number
Name
Type
Basis of
Reference
Systems (AHRS)
R.5.2.13
COMP.4.1.2
Barometric
Altimeter Unit
Specification
Description
Metric
Verified
By
Quantitative
Test
AHARS shall be capable of performing

these measurements with a minimum
of 99.9% accuracy.
Performance
F.4.1.28 Determine
Barometric
Pressure
The Barometric Altimeter Unit shall be

capable of calculating the current
barometric pressure reading at the
units resting altitude to determine the
ARVs Altitude Above Sea Level during
flight. The Barometric altimeter shall be
accurate to + or - .25 Feet.
Table 135. Air Retrieval Vehicle (ARV) Navigation Subsystem Internal Interface Specification
Number
Name
Type
Description
Metric
R.5.2.14
LINK.4.2.6
Internal Interface Requirement
Performance

interfacing with the NAV computer
at a data rate of no less than 1
gigabit per second and comply with
all specifications listed in RTCA Inc.
Performance Standards for Global
Positioning System/Aircraft Base
Augmentation Systems.
Quantitative
Verified
By
Inspection
Test
268
Table 136. Air Retrieval Vehicle (ARV) Power Subsystem Requirements

Number
Name
Type
Basis of
Description
Metric
R.5.3
Power Subsystem
Specification
Performance
F.4.4 Provide
ARV
Electrical
Power
The Power Subsystem shall be capable of

storing a minimum 40Ah of electric charge
and be capable of delivering a minimum of
500 Amps of continuous discharge to the
electronic speed controllers which shall be
capable of receiving a minimum of 500
Amps @ 18.5 volts from the battery. All
subsystems receiving electricity from the
battery shall have zero noise induced into
the subsystems as a result of electric motor
operation.
Quantitative
Verifi
ed By
Test
FAA AC 150/5210-24
FAA AC 150/5220-24
Equipment
SME Interviews
User Surveys
Requirements
Table 137. Air Retrieval Vehicle (ARV) Power Subsystem Requirement Origin Map
R.5.3 Power Subsystem Specification
269

Table 138. Air Retrieval Vehicle (ARV) Power Subsystem Specifications
Number
Name
Type
Basis of
Description
Metric
R.5.3.1
COMP.4.3.2
Battery
Specification
Performance
F.4.4.1 Provide
Stored Electricity
to ARV
The ARV Battery shall be capable of

storing a minimum 40Ah of electric
charge and be capable of at least 500
Amps of continuous discharge.
Quantitative
Verified
By
Test
R.5.3.2
COMP.4.3.1
Power Distribution
Board (PDB)
Specification
Performance
F.4.4.5 Provide
Power to ESC_1
F.4.4.6 Provide
Power to ESC_2
F.4.4.7 Provide
Power to ESC_3
F.4.4.8 Provide
Power to ESC_4
F.4.4.9 Provide
Power to ESC_5
F.4.4.10 Provide
Power to ESC_6
F.4.4.11 Provide
Power to ESC_7
F.4.4.12 Provide
Power to ESC_8
The power distribution board shall be

made of copper and be capable of
conducting a minimum of 500 Amps @
18.5 volts from the battery to the
electronic speed controllers.
Quantitative
Test
R.5.3.3
COMP.4.3.3
Voltage
Regulator
Specification
Performance
F.4.4.2 Regulate
NAV Subsystem
Voltage
The voltage regulator shall be capable

of regulating 18.5 volt supply voltage to
provide the necessary fixed DC voltage
to ARV subsystems (accurate to +/- 3%)
without inducing any noise into the
subsystem.
Quantitative
Test
270

Table 139. Air Retrieval Vehicle (ARV) Power Subsystem Internal Interface Specifications
Number
Name
Type
Description
Metric
R.5.3.4
LINK.4.3.4
BATT -> VR
Internal Interface
Specification
Performance
The battery BATT -> VR interface shall be capable of

transferring 18.5 volts at a minimum of 100 amps. This will
require a 1AWG copper wire as per FAA AC 21-99 Aircraft
Wiring and Bonding.
Quantitative
Verified
By
Test
271
Table 140. Air Retrieval Vehicle (ARV) FOD Gripping Subsystem Requirements
Number
Name
Type
Basis of
Description
Metric
Verified By
R.5.4
FOD
Retrieval
Functional
F.4.3 Retrieve FOD

F.4.3.5 Notify Personnel
of Overweight Objects
The ARV FOD Gripping Subsystem

shall be capable of retrieving FOD
from paved surfaces.
Binary
Demonstration
R.5.4.2
FOD
Weighing
Functional
F.4.3.4 Determine the

weight of FOD
The ARV Subsystem shall be

capable of determining when
objects are weigh greater than 1
lb.
Quantitative
Test
R.5.4.3
(KPP)
FOD Max
Weight
Performance
F.4.3 Retrieve FOD

weighing up to 1 pound (.453
kilograms)
Quantitative
Test
R.5.4.4
FOD
location
Performance

of Object too Large for
Retrieval F.4.3.5 Notify
Personnel of
Overweight Objects

shall be capable of notifying
airport personnel of objects that
are over 1 pound or .45359237
kilograms or over 12 inches in
length 12 Inches in width and 12
inches in height so that they may
be retrieved manually.
Quantitative
Test
R.5.4.5
(KPP)
FOD
Dimensions
Performance
F.4.3.1 Determine FOD

Characteristics

with dimensions of up to 12 inches
in length 12 Inches in width and
12 inches in height.
Quantitative
Test
272

Number
Name
Type
Basis of
Description
Metric
Verified By
R.5.4.6
FOD
Grasping
Performance
F.4.3.3 Grasp FOD

F.4.3.6 Release FOD

shall be capable of grasping FOD
12 inches in length 12 Inches in
width and 12 inches in height for
transport to the disposal areas.
Quantitative
Test
FAA AC 150/5210-24
Debris (FOD)
Management
FAA AC 150/5220-24
Debris (FOD)
Detection Equipment
User Interviews
Requirements
User Surveys
Table 141. Air Retrieval Vehicle (ARV) FOD Gripping Subsystem Requirement Origin Map
R.5.4 FOD Retrieval

R.5.4.2 FOD Weight Determination
R.5.4.3 FOD Weight (KPP)
R.5.4.4 FOD location
R.5.4.5 FOD Dimensions (KPP)
R.5.4.6 FOD Grasping
273

Table 142. Air Retrieval Vehicle (ARV) FOD Retrieval Subsystem Specifications
Number
Name
Type
Basis of
Description
Metric
R.5.4.1.1
COMP.4.4.3
FOD
Camera Unit
Specification
Performance
F.4.3.1
Determine
FOD
Characteristics
The FOD camera unit shall be capable of

imaging the FOD at a distance of 3 feet with a
resolution of 16 MP minimum. The FOD camera
unit shall be capable of determining FOD
characteristics and suitability of retrieval. The
FOD camera unit shall be capable of
determining the exact direction and distance to
the FOD and communicating this data to the
ARV Navigation Subsystem.
Quantitative
Verified
By
Test
R.5.4.1.2
COMP.4.4.4
Weight
Sensor
Specification
COMP.4.4.2
VERSABALL
System
Specification
Performance
F.4.3.4
Determine
FOD weight
The weight sensor shall be able to determine the

weight of items grasped by the VERSABALL
Gripper with an accuracy of (+or- .05 lb.)
Quantitative
Test
The Gripper shall have the ability to grasp an

unpainted, metal cylinder, measuring 1.2 in (3.1
cm) high and 1.5 in (3.8 cm) in diameter. The
Gripper shall have the ability grasp a sphere,
measuring 1.7 in (4.3 cm) or less in diameter A
chunk of asphalt or concrete weighing less
than 1 pound, any portion of a runway light
fixture (in-pavement or edge light), An
adjustable crescent wrench up to 8 in. (20 cm)
in length), A deep socket (at least 2 in. (5 cm) in
length), A piece of rubber from an aircraft tire, A
distorted metal strip (up to 8 in. (20 cm) in
length), Fuel cap (aircraft or automotive), Lug
nut, Hydraulic line (from aircraft or GSE, up to 8
in. (20 cm) in length).
Quantitative
Test
R.5.4.6.1
Performance
274

R.5.4.7
COMP.4.4.1
Retrieval
Telemetry
Radio
Specification
Performance
F.4.3.2 Notify
Personnel of
Object too
Large for
Retrieval
The Retrieval Telemetry Radio shall meet the

Emissions and Susceptibility. It must be capable
of operating through the entire amplitude
modulated aircraft radio frequency range of 75
MHz 136 MHzs.
Quantitative
Test
Table 143. Air Retrieval Vehicle (ARV) FOD Retrieval Subsystem Internal Interface Specifications
Number
Name
Type
Description
Metric
R.5.4.8
LINK.4.4.3
Weight Sensor <-> Versaball System
Internal Interface Specification
Performance
The Weight Sensor <-> Versaball

System Internal Interface shall be
capable of transferring the physical
weight of grasped objects to the
weight sensor for measurement. It
shall minimize aircraft vibration by at
least 80% by incorporating a
vibration absorber into the design.
Quantitative
Verified
By
Test
275
Table 144. ARV Housing and System Power Segment Requirements

Number
Name
Type
Description
Metric
Verified By
R.6
AV Housing
and Power
Specification
Performance
The AFDIRTS system shall be capable of receiving

120/240V single-phase AC external power and
transferring this power to AFDIRTS system elements.
Quantitative
Test
R.6.1
Back-Up
Power
Performance
The system shall be capable of generating back-up

120/240V single-phase AC power that will provide 10
minutes of emergency power that will give mobile
system elements enough time to navigate to emergency
standby locations.
Quantitative
Test
R.6.2
Loss of
External
Power
Performance
The back-up power subsystem shall be capable of

sensing low phase-to-ground voltage and when voltage
or frequency drops to 95% of nominal the relay shall
activate the generator.
Quantitative
Test
276
FAA AC 150/5210-24
Debris (FOD)
Management
FAA AC 150/5220-24
Equipment
Requirements
User Interviews
User Surveys
Table 145. ARV Housing and Power Segment Requirement Origin Map
R.6 AV Housing and Power Specification

R.6.1 Back-Up Power
Table 146. ARV Housing and Power Segment Subsystem Specifications

Number
Name
Type
Basis of
Description
Metric
R.6.3
COMP.5.4
ARV housing
Specification
Performance
F.5 Provide
AV Housing
F.5.6
Secure ARV
The ARV housing unit shall be capable of securing

and sheltering the ARV from the elements The
ARV housing unit shall be fireproof and provide a
method of dehumidifying the unit when relative
humidity exceeds 30%.
Quantitative
Verified
By
Test
R.6.4
COMP.5.5
Battery
Charger
Specification
Performance
F.5.8
Recharge
Air Vehicle
The ARV battery charger shall be capable of

providing an 18.5 volt 40 AMP charge to the
ARVs batteries. (1C of 40,000 mAh)
Quantitative
Test
277

Number
Name
Type
Basis of
Description
Metric
R.6.5
COMP.5.3
Generator
Specification
Performance
F.5.3
Generate
Emergency
Power
The AFDIRTS generator shall be capable of

delivering 120/240V single-phase AC power to
provide 10 minutes of emergency power that will
give mobile system elements enough time to
navigate to emergency standby locations.
Quantitative
Verified
By
Test
R.6.6
COMP.5.1
Power
Transfer
Panel
Specification
Performance
F.5.1
Accept
External
Power
F.5.4
Transfer
Power
The Power Transfer Panel shall be capable of

accepting 120/240V single-phase AC power and
transferring this power to system elements. The
Power Transfer Panel shall be capable of circuit
protection when system elements begin to pull
excessive current.
Quantitative
Test
R.6.7
COMP.5.2
Transfer
Switch
Specification
Performance
F.5.2
Detect
External
Power
Failure
The Transfer Switch shall be capable of detecting

loss of external power and automatically starting
the emergency generator when external power is
absent for 1 second.
Quantitative
Test
R.6.8
COMP.5.6
Charging
Receptacle
Specification
Performance
F.5.7
Make
Charging
Connection
The charging receptacle shall be capable of

transferring 18.5 volts @ 40 Amps from the ARV
Battery Charger to the ARV battery. It shall be
designed so that when the ARV is secured to the
housing unit the charging receptacle shall make
contact.
Quantitative
Test
278

Table 147. ARV Housing and Power Segment Internal Interface Specification
Number
Name
Type
Description
Metric
R.6.9
LINK.5.7
Gen -> PWR
Transfer PNL
Int. Interface
Spec
Performance
The Generator -> Power Transfer Panel Internal Interface shall

be capable of transferring 120/240V single-phase AC power
from the generator to the transfer panel. The wire gauge
utilized will be dependent upon total system current.
Quantitative
Verified
By
Test
279
Table 148. FOD Analysis Segment Requirements

Number
Name
Type
Basis of
Description
Metric
Verified By
R.7
FOD Analysis
Segment
Functional
F.6 Analyze
FOD Trends
F.6.2 Perform
Trend Analysis
F.6.4 Export
FOD Reports
The FOD analysis segment shall

provide a method of trend
analysis that will be utilized to
improve foreign objects left on
the airfield.
Qualitative
R.7.1
Types of Data
Functional

receiving and storing FOD alert
time and date, location
coordinates and FOD image
data.
Binary
Test
R.7.1.1
Storage of
Data
Performance
F.6.1 Accept
FOD alert time
and date,
location
coordinates
and FOD
image data
F.6.3 Retain
Data
Data collected in the FOD

detection process shall be
recorded and stored for at
least 2 years after the
detection event.
Quantitative
Test
Demonstration
280
FAA AC 150/5210-24
FAA AC 150/5220-24
Equipment
Requirements
User Interviews
User Surveys
Table 149. FOD Analysis Segment Requirement Origin Map
R.7 FOD Analysis Segment

R.7.1 Types of Data
Table 150. FOD Analysis Segment Subsystem Specifications

Number
Name
Type
R.7.2
COMP.6.1
Analysis
Computer
Specification
Performance
Basis
of
Description
Metric
The FOD analysis computer shall be capable of

performing at a minimum of 700,000,000 clock cycles
per second (700Mhz)
Quantitative
Verified
By
Test
281

Number
Name
Type
R.7.3
COMP.6.2
Analysis Radio
Specification
Performance
R.7.4
COMP.6.1.1
Analysis
Software
Specification
Performance
Basis
of
Description
Metric
The Analysis Radio shall meet the current issues of

radio suppression specification MIL-STD-461, Class 3D,
Interference Emissions and Susceptibility. It must be
capable of operating through the entire amplitude
modulated aircraft radio frequency range of 75 MHz
136 MHzs.
Quantitative
Verified
By
Test
The Analysis Computer Software shall enable the

AFDRTS Computer to retain and export upon user
request; FOD Location, FOD alert time, date of
occurrence, location coordinates, and FOD Image
data for at least two years following the FOD event.
Quantitative
Test
Table 151. FOD Analysis Segment Internal Interface Specifications

Number
Name
Type
Description
Metric
R.7.5
LINK.6.1
Computer Internal
Interface Specification
Performance
The Analysis Radio -> Analysis Computer Internal

Interface shall be capable of transferring data at
minimum of 1 gigabit per second (Gbps).
Quantitative
Verified
By
Test
282
SM4 Project Schedule Assessment
The SM4 project is representative of a real world contract between a user and system
developer. In this case, the contract is between the Johns Hopkins University and the
Student. Since calendar dates are not contractually binding, the decision was made to
use a contractual document (the Integrated Master Plan) versus an Integrated Master
Schedule (IMS).
I initially estimated that the project would be complete in 326 hours. This was based
upon other students projects; however, my project required approximately 602 hours to
complete. The reasons for the difference in time is multifaceted. First, my initial concept
was impractical. I selected a problem that I was passionate about solving; this led to a
strong (and unintentional) desire to develop solutions to the problem without the proper
elicitation of requirements from users and SMEs. My concept was reworked several
times until I had a good grasp of the needs analysis phase of the SE Method, and my
new concept was properly validated utilizing this method.
Second, the concept definition phase took longer than planned due to an incomplete
functional architecture. I did not perform functional analysis and formulation down to
the level necessary to make the make or buy decision and had to redo the functional
architecture. Even though the project took me longer than planned to complete. I
believe it allowed me to gain an excellent understanding of the systems engineering
discipline. I feel that I still have much to learn and am reluctant to say I am a Master. I
will continue to strive to become more knowledgeable through on the job training, and
research. Even though I do not feel that I have yet Mastered the SE discipline, I do
feel I have earned the M.S. Degree.
283
Table 152. AFDIRTS Integrated Master Plan
Activity Number
Activities
Planned
A
A01
Needs Analysis Phase Complete

Operational Requirements Defined
A01a
Operational Analysis Complete
A01a1
Analyze Projected Needs
A01a1.
1
Estimated Hours of Work

Actual Difference
141
312
141
312
39
Develop Needs Statement

9
A01a3
Develop Operational Objectives
10
34
A01b1
Translate Operational Objectives into Functions
20
A01b2
Allocate Functions to Subsystems
14
A01c
Feasibility Definition Complete
34
A01c1
Visualize Subsystem Technology
15
A01c2
Define Feasible Concept
10
A01c2.
1
A01d
+176
67
+33
20
-14
10
-24
Define Operational Approach
Functional Analysis Complete
215
15
A01a2
A01b
+171
Develop and Apply Feasibility Criteria9

Needs Validation Complete
34
284
Activity Number
Activities
Planned

Actual Difference
A01d1
Design Effectiveness Model
14
A01d2
Validate Needs and Feasibility
20
A01d3
Develop and Apply Measures of Effectiveness (MOE)
10
(CDRL) Concept Paper Approved
July 26th, 2015
(CDRL) Proposal Approved
July 28th, 2015
Concept Exploration Phase Complete
D01
D01a
Performance Requirements Defined

Operational Requirements Analysis Complete
80
110
80
110
20
D01a1
Analyze Operational Objectives
10
D01a2
Refine Operational Requirements
10
D01b
Performance Requirements Formulation Complete
20
D01b1
Derive Subsystem Functions
10
D01b2
Formulate Performance Parameters
10
D01b2.
1
d01c
Update and Apply Feasibility Criteria

Implementation Concept Exploration Complete
+30
60
+40
20
20
5
20
d01c1
Explore Implementation Concepts
10
d01c2
Define Performance Characteristics
10
285
Activity Number
d01c2.
1
D01d
Activities
Planned

Actual Difference
Performance Requirements Validation Complete
10
20
D01d1
Integrate Performance Characteristics
10
D01d2
Validate Performance Requirements
10
D01d2.
2
D02
D02a
E
E01
E01a
Update and Apply MOE
November 14th 2015
Concept Exploration Reworked as Required
Concept Selected
Performance Requirements Analysis
E01a1
Analyze Performance Requirements
E01a2
Refine Performance Requirements
E01a2.
1
(CDRL) RAR/CONOPS Approved
Concept Definition Phase Complete
Functional Analysis Formulation
10
105
206
+101
20
60
+40
20
86
+66
105
E01b1
Define Component Functions
10
E01b2
Formulate Functional Requirements
10
E01b2.
1
-10
Develop and Apply Trade-Off Criteria
286
Activity Number
Activities
Planned
E01c
E01d

Actual Difference
(CDRL) Functional Analysis Report Complete *should have performed after concept selection
29th, 2015
Concept Selection
30
20
E01d1
Synthesize Alternative Concepts
10
E01d2
Select Preferred Concept
10
E01e
E01e1
E01f
(CDRL) Conceptual Design Report Approved

Develop and Apply Trade-Off Criteria
Concept Validation
30
45
Conduct System Simulation
E01f2
Validate System Concept
15
F01
G
G01
H
+10
December 7th,2015
E01f1
November
(CDRL) Trade Study Approved
-15
December 19th, 2015
Concept Definition Reworked as Required
15
(CDRL) A-Spec Approved
January 3rd, 2016
A-Spec Reworked as Required
15
(CDRL) Final Report Submitted
0
January 3rd, 2016
Totals
326
602
+276
Hours
Hours
Hours
287
Lessons Learned
1. Do not select a project in which you are the SME.

My first try at a system concept was one that would allow engineers and military
maintenance personnel to better communicate (a problem I have been passionate
about solving for a long time). Since this was the case, I found it difficult to not to allow
my vision of solving the problem drive implementation. The original concept title was
the Wearable Engineering & Maintenance Collaboration System which itself implied
implementation. Instead, select a project in a field that interests you, with SMEs that are
easily accessed.
2.
Let the SMEs contribute to requirements development, but dont overdo data
collection.
I used an online survey (surveymonkey) to collect responses from SMEs. This was a
mistake. It took time soliciting participation and later, more time sorting through the
data. If the project was real or I was contributing to the body of knowledge it would
have been appropriate. Since it wasnt, my time spent in this area could have been
better utilized elsewhere. 1 or 2 experts in each domain should suffice.
3. Watch Christopher Olsons CORE videos before you enroll in 645.800
When I started the project, I did believe it was necessary to apply the SE method to
develop the concept and proposal papers. In my view, these deliverables were just
precursors to the project. Christopher Olson puts this into perspective by demonstrating
how the SE method should be applied to the project from the concept paper to the ASpec.
4. Perform the SE process (Requirements Analysis -> Functional Analysis - > Physical
Definition -> Design Validation) for each phase of the SE-Method whether your
deliverable requires it or not!
Some deliverables do not require all of the steps be performed to complete. For
example functional analysis is not required to produce the proposal; but it is required to
define feasibility and validate the need. Therefore, follow the steps of the SE Method
and let your deliverables become by-products of the process. If you use CORE, it will
help you move into the next phase of the SE Method.
288
Evaluation And Next Steps
The A-Spec listed in this document could be delivered to an engineering team to

develop during the Engineering Development Stage. However, the quality is not very
good. I did not have the resources (time, information, SE experience, software
experience, UML/SYSML experience and unlimited access to engineers/experts) nor did
I have access to the complex mathematical models that would be required to assist in
the development of a system of this scale.
With that being said, as the concept enters the Engineering Development stage,
engineers contracted to build the AFDIRTS will have a concept capable of entering the
advanced development stage however, they might need additional resources to bring
the requirements document up to par.
289
Appendix A
AFDIRTS Concept paper
290
Table of Contents
Student Biography. 292
Capability Gap/System Justification 293
Needs Statement. 294
AFDIRTS Description.... 294
Existing Technologies.. 294
AFDIRTS Preliminary Context/N2 Diagrams.. 296
Stakeholders............... 299
Risks.. 300
Schedule. 302
Systems Engineering Justification 305
Operational Objectives. 306
Measures of Effectiveness.. 307
291
Student Biography
Penniless after utilizing most of my earnings to obtain a private pilots license while
fueling general aviation aircraft at a small Fixed Based Operation (FBO)/flight training
center on Fort Lauderdale Executive Airport, I fell in love with aviation and decided to
enlist in the U.S. Navy. After completion of basic training I attended Aviation Electronics
Technician Intermediate (I) Level Repair A School, I performed three deployments on
various aircraft carriers as part of the Aircraft Intermediate Maintenance Departments
(AIMD) Sea Operational Detachment (SEAOPDET). While there, I became proficient in
the component level troubleshooting and repair of communication/navigation avionics
installed on various type/model/series (T/M/S) aircraft.
In 2004, I received orders to Helicopter Anti-Submarine Squadron Seven (HS-7) where I
performed Organizational maintenance for the first time. This was an unconventional
career move for an I Level Aviation Electronics Technician, but I had a strong desire to
work with the aircraft and despite the steep learning curve, I eventually became
proficient in all aspects of HH-60H and SH-60F maintenance.
In 2005 I was selected to lead the squadrons Avionics Shop where I successfully
supported the squadron through two demanding Arabian Gulf deployments. In this
position, I was crucial in helping the squadron attain many of its operational goals,
including the rapid integration of the HH-60H Fast Tactical Imaging (FTI) system into a
hostile environment. This involved technical coordination with the USS Harry S. Trumans
(CVN-75) Carrier Intelligence Center (CVIC) to solve compatibility problems that existed
between the aircraft and the ships user interface (just prior to the battle group transiting
the Hormuz Strait). The FTI integration was a success, which facilitated the first ever
forward looking inferred (FLIR) video of Iranian surface threats while entering the
Arabian Gulf.
In 2008, I was assigned to the Center for Naval Aviation Technical Training Unit
(CNATTU) Jacksonville, Florida where I earned my Master Training Specialist Designation.
While at CNATTU, I was responsible for leading 18 instructors as the Avionics I Level
Maintenance Training Unit (MTU) LPO, in this position I supervised the instruction and
curriculum development of 22 aviation I level maintenance courses. I also served as
292
the Lead Instructor and Course Curriculum Model Manager for the U.S. Navys I Level
IFF Maintenance Course (C-102-4052). In this role I was responsible for the local
Instruction and Navy-wide curriculum development for the course.
In 2010, I earned a Bachelors Degree in Liberal Studies with a focus in Electronic
Instrumentation from Excelsior College and nearly completed a Masters in Aeronautical
Science from Embry Riddle. I made the decision to switch graduate programs after
receiving orders to Air Test and Evaluation Squadron 23 (VX-23), Patuxent River, MD. This
decision was based on my realization of how my love for technology, solving problems
and leading people could be intertwined with aviation through the Systems Engineering
discipline.
I began the Masters in Systems Engineering Program at Johns Hopkins University
Engineering for Professionals in the fall of 2012 and have been steadily working the
program while simultaneously performing government contract maintenance oversight
at VX-23.
This program has allowed me to see the big picture not only through the eyes of a
sailor/government employee, but from the perspectives of a taxpayer, hardware
engineer, software engineer, maintainer, logistician, analyst, project manager, and
finally; a systems engineer.
I look forward to completing the project and demonstrating my mastery of the
discipline.
Capability Gap/System Justification

The aviation industry spends approximately $7 billion dollars per year in non-bird strike
FOD damage to aircraft (McCreary, 2010). In addition to the financial burden, FOD
damage to aircraft occurring at critical moments in flight has led to loss of life and
complete destruction of aircraft. An example of this is Air France Flight 4590 which
crashed killing all 109 people onboard after a titanium alloy strip, 17.1 inches long and
about 1.3 inches wide ruptured a tire and sent a piece of it through the wing during
takeoff (Weller, 2014). An automated FOD detection and retrieval system would
293
enable airports to autonomously detect, remove and track FOD on Aircraft Operating
Areas (AOA) 24 hours a day, 7 days a week.
Needs Statement
The Airfield FOD Detection, Identification, Removal and Tracking System (AFDIRTS) is to
provide a safe autonomous method of detecting, removing and tracking FOD from
AOAs 24 hours a day 7 days a week while not interfering with normal airport
operations. The AFDIRTS will be capable of command and control from the tower
allowing the airport to focus FOD searches in specific areas; or halt operations as
necessary. The AFDIRTS will be capable of operation in inclement weather. The AFDIRTS
shall be reliable, affordable and maintainable. The AFDIRTS will comply with all FAA
Regulations.
AFDIRTS Description
The AFDIRTS will be designed to autonomously detect, remove and track FOD on
Airport Operating Areas. The FAA has been testing and evaluating FOD detection
systems that automatically detect FOD and notify airport personnel when discovered
(Weller, 2014); however, automated retrieval is a new concept.
Analysis shows that automated vehicle technology is mature enough to be combined
with automated FOD detection systems to provide airports with a fully automated
method of detecting, retrieving and tracking FOD on Airport Operating Areas. The
needs analysis phase of the SE method produced a preliminary physical architecture
(Context Diagram) and the functional architecture (N2 Diagram) shown in section 3.
Existing Technologies
The FAA is currently evaluating a few different FOD detection technologies placed at
four different airfields (Weller, 2014). These technologies are listed below.
Tarsier Radar Currently being tested at T.F. Green Airport (PVD) in Providence, RI
(PVD). Developed by QinetiQ Corporation, Tarsier utilizes millimeter wave radars that
are mounted on rigid towers to sweep runways. Once FOD is detected, the integrated
294
day/night camera zooms in to identify it and ultimately have airport personnel retrieve it
(QinetiQ, 2015).
IFerret Is currently being evaluated at Chicago OHare (ORD) International Airport.
Developed by Stratech Inc., IFerret consists of a high resolution camera mounted on
rigid towers that scan for and detect FOD on Runways, Taxiways and Aircraft Aprons.
Once the FOD is detected, personnel are notified to retrieve it (Stratech, 2015).
FODetect - Is currently being tested at Boston Logan (BOS) international Airport.
Developed by XSight Systems, FODetect utilized a high resolution camera combined
with millimeter wave radar mounted on airport lighting fixtures (XSight, 2015).
FOD Finder Is currently being tested at Chicago OHare (ORD) International Airport.
Developed by Trex Enterprises Corporation, FOD Finder utilizes a Millimeter Wave Radar
and Infrared Cameras that are mounted on top of Airport Vehicles that scout AOAs for
FOD.
The most technically challenging of the operational objectives will be to provide
automated FOD retrieval. The reason for this it that it will require the use of an
autonomous vehicle to perform the functions necessary to meet the operational
objective.
According to the Automated Vehicle Institute (2013) an autonomous vehicle should
drive itself in a manner similar to that driven by a safe human driver. To do this they
outline a four step functional loop that the vehicle must perform to be effective. These
steps are:
1.
Sense the environment (what is in my vicinity?).
2.
Decipher its own location (where am I on a global map?).
3.
Plan its next move (what should I do next?)
4.
Execute the plan.
(Automated Vehicle Institute, 2013)

These functions are fairly straightforward and have been successfully applied in the
google car which has logged over 1.8 million miles of combined autonomous and
295
manual driving on the road with all 13 accidents reportedly caused by human error
(Swartz, 2015). However, autonomous driving on an active airfield will be more
complicated with function 3 plan its next move having to be decomposed further
into functions that interface with the tower and ground controllers. This will make the
already difficult job of the air traffic controller even harder by giving the controllers
additional responsibilities.
A possible solution to this problem might be to eliminate the need for Air Traffic Control
to give automated vehicles clearance. This might be accomplished by designing even
more autonomy into the vehicle. For example, the vehicle might be able to decide on
its own whether or not to enter a taxiway by obtaining data from sensors. Or, make the
decision to enter an active runway based on logic i.e. once an aircraft enters the
pattern the vehicle must exit the runway. This could be made feasible by designing
vehicle loiter points adjacent to active runways.
AFDIRTS Preliminary Context/N2 Diagrams

The systems engineering method developed by Kossikoff et al. (2011) was applied to
the development of the merged SM4 concept and proposal paper. This was
accomplished by completion of the needs analysis phase of the SE method. This
method consists of four steps that are iteratively applied throughout system
development. In the needs analysis phase these steps are known as operational
analysis, functional analysis, feasibility definition, and needs validation. The byproducts
of this phase resulted in a system level physical architecture and a system level
functional architecture. These are illustrated below in the form of a context diagram
(Figure 1) and N2 Diagram (Figure 2).
296
Obstacles
Government
Organizations
Environment
Air Traffic
Control
Physical Obstacle
Location
Regulations
Heat Energy
Sand Material
Salt Material
Ice Material
Rain Material
Snow Material
Wind Force
UV Rays Energy
Lost Item Data

Command
Signals
Active Obstacle
Detection Signal?
Reports
Heat Energy
RF Energy
Sound Energy
Resistance Force
Exhaust Material
Obstacles
Government
Organizations
Environment
FOD Data
Location Data
Status Data
Air Traffic
Control
Airport
Managers
Constraint Data
Status Data
Reports Data
Airport
Managers
Aircraft
Operators
Lost Item Data
Found Item
Notification Data
FOD Material
Aircraft
Operators
Power
Maintainer
FOD
Electrical
Energy
Excess
Electrical Energy
Power
Good Parts
Good Material
SW Update
Signal
Query Signal
Bad Parts
Used Material
Fault Codes
Status Data
Maintainer
Physical FOD
Location
Active FOD
Detection Signal?
Figure 1. AAFDRTS Context Diagram
FOD
297
Airport
Managers
Constraint Data
Government
Organizations
Air Traffic
Control
FOD
Power
Aircraft
Operators
Maintainer
Environment
Obstacles
Regulations
Electrical
Energy
Lost Item Data

Command
Signals
Physical
Obstacle Location
Active Obstacle
Detection Signal?
F.1
Operate
Safely
Heat Energy
Sand Material
Salt Material
Ice Material
Rain Material
Snow Material
Wind Force
UV Rays Energy
Excess Electrical Energy
F.2
Perform System
Command and
Control
Functions
Good Parts
Good Material
SW Update Signal
Query Signal
Physical FOD
Location
F.3
Operate in
Extreme
Weather
Found Item Notification Data
Heat Energy
RF Energy
Sound Energy
Resistance Force
Exhaust Material
Bad Parts
Fault Codes
Used Material
Obstacles
Maintainer
Power
Aircraft
Operators
Environment
F.4
Perform
Reliability,
Availability and
Maintainability
Functions
FOD Data
Location Data
Status Data
Active FOD
Detection
Emission?
F.5
Detect FOD
FOD Material
F.6
Retrieve FOD
AAFDRTS
Figure 2. AAFDRTS N2 Diagram
F.7
Perform FOD
Trend Analysis
FOD Data
Found Item
Notification
Location Data
Reports Data
Air Traffic
Control
FOD
Airport
Managers
Government
Organizations
298
Stakeholders
During the needs analysis phase potential stakeholders were contacted as a means of
gathering information for operational and functional analysis. The stakeholders are
listed below will continue to be utilized throughout the development of the AFDIRTS
system.
Sean Mulholland
Safety Director, SevenBar Aviation
Sean has experience as the safety director for SevenBar Aviation. His operational and
employee safety experience in airline terminal / ramp / flight settings will be a benefit to
system development.
Unnamed
Operations and Maintenance Manager
Unnamed manages a staff of 9 field and building maintenance workers in the
performance of daily airport maintenance activities. These activities include snow and
FOD removal. He functions as a primary liaison with airlines, airport tenants and users.
The AFDIRTS will perform some of the functions he is currently responsible for; therefore,
his experience will aid in the elicitation of requirements.
Michael Villarreal
Airline Pilot/Captain, United Parcel Service (UPS)
Michaels 30+ year career as a commercial pilot will help identify system constraints,
elicit requirements and help address safety concerns from a pilots perspective.
Dillon Stewart
A&P Apprentice, CFDI Aero
Dillon is an A&P Apprentice and participates in daily FOD checks of hangar bays and
aircraft ramps in his area of responsibility. His perspective will be utilized during the
elicitation of requirements.
299
Unknown
Air Traffic Controller
An Air Traffic Controller has yet to be identified, but it is expected that one will be
contacted prior to the start of operational requirements analysis.
Risks
A preliminary risk assessment was conducted to identify risks that will have to be
addressed during the SM4 project. These risk have been documented below.
1. If stakeholder interviews do not uncover all potential problems; or gather enough
information about the operating environment then these issues will become more
expensive to solve in the latter stages of AFDIRTS development; because the design will
be more complex and difficult to change.
2. If care is not taken to ensure traceability throughout system development, then
system architectural questions may go unanswered during the SM4 presentation;
because a traceability matrix was unavailable.
3. If the triumvirate of conceptual design; as described by Kossiakoff et al. (2011, p.175)
is not applied to requirements analysis, then system requirements may be developed as
ambiguous and difficult to decompose into subordinate requirements,; or just not make
sense; because requirements analysis was not properly performed.
4. If lessons learned are not documented as the project progresses, then they may
become difficult to recall during development of the final report; because a lessons
learned document was not available.
5. If the ATC interface requires too much of the controllers attention, it may hinder their
ability to control air/ground traffic; because they will be overtasked.
Schedule
The Merged SM4 concept and proposal paper is representative of a real world
contract between a user and system developer. In this case, the contract is between
the Johns Hopkins University and the Student. Calendar dates are not contractually
300
binding (DOD, 2005); therefore, the decision was made to use a contractual document
(the Integrated Master Plan) versus an Integrated Master Schedule (IMS). I hope to
deliver the final report and presentation by November 16, 2015.
301
Table 1. Integrated Master Plan
Difference
Activities
Actual
312
176
215
181
210
195
10
10
34
Planned
Activity
Number
A
A01
A01a
A01a1
A01a1.1
Needs Analysis Phase Complete

Operational Requirements Defined
136
Operational Analysis Complete
34
Analyze Projected Needs
15
Dev elop Needs Statement
A01a2
Define Operational Approach
A01a3
Dev elop Operational Objectiv es
A01b
136
Functional Analysis Complete
34
A01b1
Translate Operational Objectiv es into Functions
20
20
A01b2
Allocate Functions to Subsystems
14
14
34
A01c
Feasibility Definition Complete
34
A01c1
Visualize Subsystem Technology
15
15
A01c2
Define Feasible Concept
10
10
34
A01c2.1
A01d
Dev elop and Apply Feasibility Criteria
Needs Validation Complete
34
A01d1
Design Effectiv eness Model
14
14
A01d2
Validate Needs and Feasibility
20
20
10
A01d3
B
B01
C
Dev elop and Apply Measures of Effectiv eness (MOE)

(CDRL) Concept Paper Approved
10
6
Rework Needs Analysis As Required

(CDRL) Proposal Approved
302
Table 1. Integrated Master Plan Cont.
Activities
Actual
Planned
Activity
Number
D
D01
D01a
Concept Exploration Phase Complete
100
Performance Requirements Defined

Operational Requirements Analysis Complete
20
D01a1
Analyze Operational Objectiv es
10
D01a2
Refine Operational Requirements
10
D01b
Performance Requirements Formulation Complete
20
D01b1
Deriv e Subsystem Functions
10
D01b2
Formulate Performance Parameters
10
D01b2.1
d01c

Implementation Concept Exploration Complete
5
20
d01c1
Explore Implementation Concepts
10
d01c2
Define Performance Characteristics
10
d01c2.1
D01d

Performance Requirements Validation Complete
5
20
D01d1
Integrate Performance Characteristics
10
D01d2
Validate Performance Requirements
10
D01d2.2
D02
D02a
Difference
Update and Apply MOE

(CDRL) Requirements Analysis Report/CONOPS Approved
Concept Exploration Reworked as Required
5
20
10
303
Table 1. Integrated Master Plan Cont.
Activities
Actual
Planned
Activity
Number
E
E01
E01a
Concept Definition Phase Complete
Refine Performance Requirements

Functional Analysis Formulation
Define Component Functions
E01b2
Formulate Functional Requirements

(CDRL) Functional Analysis Report Complete
Concept Selection
Select Preferred Concept
E01d2
(CDRL) Trade Study

Concept Validation
E01f1
Conduct System Simulation
E01f2
Validate System Concept
G
G01
H
20
Dev elop and Apply Trade-Off Criteria
E01e1
F01
20
Synthesize Alternativ e Concepts
E01d1
Functional Analysis Reworked as Required
E01c1
E01f
20
Dev elop and Apply Trade-Off Criteria
E01b2.1
E01e
20
Analyze Performance Requirements
E01b1
E01d
100
Performance Requirements Analysis
E01a2
E01c
180
Concept Selected
E01a1
E01b
Difference
15
0
15
(CDRL) Conceptual Design Report
20
Concept Definition Reworked as Required

(CDRL) A-Spec
20
A-Spec Reworked as Required

(CDRL) Draft Final Report Submitted
20
(CDRL) Final Report and Presentation Complete
20
H01
Total
430
304
Systems Engineering Justification

According to the Seymour (2012) a demonstrable need, feasibility and sufficient
complexity must be shown in order for the SM4 project system concept to be deemed
viable.
To ensure that the proposed SM4 project system concept will meet the complexity
criterion, the characteristics of systems requiring systems engineering described by
Kossiakoff et al. (2011, p. 10) was applied to the AFDIRTS concept. These characteristics,
as they apply to the proposed SM4 project system are listed below:
The AFDIRTS will be an engineered product and will satisfy a specied need.
The AFDIRTS consists of diversified components that will have intricate relationships
with one another; it is multidisciplinary and relatively complex.
The AFDIRTS will use advanced technology in ways that are central to the
performance of its primary functions and therefore involves development risk, while
relatively high in cost.
To ensure the AFDIRTS met the feasibility and demonstrable need criterion, the
needs analysis phase of the SE method was applied to the SM4 proposed project
concept. By taking this approach, these criterion were validated during the feasibility
definition and needs validation steps of the needs analysis phase.
When applying the systems engineering method to the FOD detection and retrieval
problem, operational analysis was performed through discussions with potential
stakeholders. Research was conducted to determine the FAAs current capabilities and
future plans regarding FOD detection. This led to the identification of a capability gap
of current FOD detection systems.
After the capability gap was identified, a needs statement was developed and
overarching operational objectives were derived from the perceived users needs.
Once operational objectives were defined, they were uploaded into CORE;
operational objectives are listed below:
305
Operational Objectives
1.
Provide Safe Operation

1.1.
Provide System Redundancy
1.2.
Provide Self Diagnostics
1.3.
Provide Remote Power Cut-Off to Mobile Units
1.4.
Meet or Exceed all FAA Regulations
1.5.
Meet or Exceed all Environmental Regulations
2.
Provide Automated FOD Detection
3.
Provide Automated FOD Retrieval
4.
Provide System Command, Control and Locomotion
5.
6.
4.1.
Provide Air Traffic Control Interface
4.2.
Provide Airfield Navigation
4.3.
Provide Mobile Unit Locomotion
4.4.
Provide Obstacle Detection and Avoidance
Facilitate Inclement Weather Operation

5.1.
Provide Operation During Freezing Conditions
5.2.
Provide Operation During Hot Conditions
5.3.
Provide Operation In Wet Conditions
5.4.
Provide Operation In Windy Conditions
5.5.
Provide Operation in Sandy Conditions
5.6.
Provide Operation in Corrosive Environments
5.7.
Provide Operation in Humid Conditions
Provide a High Level of Reliability, Availability and Maintainability

6.1.
Facilitate System Reliability
6.2.
Facilitate System Availability
6.3.
Facilitate Ease of Maintenance
6.3.1. Provide Built in Tests (BIT)

6.3.2. Provide Component Modularity
7.
Provide FOD Trend Analysis

7.1.
Provide FOD Location

306
7.2.
Provide FOD Image
7.3.
Provide a method of FOD Report Transmission
After all operational objectives had been defined and decomposed, functional
analysis was performed to derive preliminary system functions; these functions were
uploaded into CORE (overarching system functions are documented in Figure 2.)
A feasibility study was performed to establish feasibility criteria for the AFDIRTS concept.
Once feasibility criteria had been applied to eligible system concepts, a feasible system
concept was defined and effectiveness analysis was performed based upon the ability;
and feasibility of the preliminary system concept to meet the customer needs within
cost, time, technological, operational, safety and regulatory constraints. From this, a
preliminary physical architecture was developed that facilitated the creation of the
preliminary context diagram (shown in Figure 1.). After a feasible system concept was
defined the needs validation step was performed. During this phase Measures of
Effectiveness (MOE) were developed based upon interviews and discussions with
potential customers as well as research into the FAAs current FOD detection system
guidance published in Advisory Circular 150/5220-24 and FOD Management guidance
published in Advisory Circular 150/5210-24. The top five MOEs are listed below:
Measures of Effectiveness
1. Provide redundancy for components or subsystems deemed High Risk during Failure
Mode, Effects and Criticality Analysis (FMECA) (Binary MOE expressed as a metric of
operational objective 1.1 Provide system redundancy)
2. Detect an unpainted metal cylinder, measuring x inch high and x inches wide; and a
white, grey, or black sphere with the radius of x inches) any time day or night in clear
weather and inclement weather conditions*. (Measurement MOE expressed as a
measurement of operational objective 2.0 Provide automate FOD detection) This MOE
was based in part on current FAA FOD detection system guidance listed in AC
150/5220-24.
3. Capable of retrieving FOD from anywhere on the AOA in under 5 minutes after
detection night and day and in clear and inclement weather conditions* (Binary MOE
expressed as a metric of operational objective 3.0 provide automated FOD retrieval).
307
4. Capable of autonomous movement on AOAs at a speed of x MPH, during clear and

inclement weather conditions*. (Measurement MOE expressed as a metric of
operational objective 4.3 provide mobile unit locomotion)
5. Detect obstacles at a distance of x feet from mobile units, day and night during clear
and inclement weather conditions *. (Measurement MOE expressed as a metric of
operational objective 4.4 Provide obstacle detection and avoidance)
* Inclement weather conditions will be defined as adverse weather that can still sustain flight operations.
Different operational scenarios were evaluated which helped translate operational

objectives into preliminary operational requirements
Three operational scenarios have been listed below:
1.
FOD is detected on an active runway.
In the event that FOD is detected on an active runway the system must take action. This
event will trigger the initiation of function 6.0 Retrieve FOD. How this Function is
accomplished will depend on feedback from stakeholders. These stakeholders will help
answer questions; such as when, if ever, should ATC be alerted of FOD detection on the
AOA? Should the system request clearance to enter an active runway? How about
Taxiways? What does the system do if it detects FOD too large to be retrieved? What
does it do with biological FOD (i.e. animal feces)? Technical research will have to be
performed to determine if the system can even distinguish between biological FOD and
hard FOD? Input from stakeholders on questions like these will be crucial to developing
a system that meets user needs.
2.
A mobile system component becomes immobilized on the AOA.
If a system element becomes immobilized on the AOA it becomes a hazard to not only
arriving and departing aircraft, but ground traffic as well. Stakeholders will be consulted
to determine the appropriate response to this type of failure. A few different options
can be analyzed. First, the mobile system element could be designed to fail in a certain
manner (i.e. when a BIT failure is experienced the mobile system elements will maneuver
onto an unpaved section of the AOA). Another option is for the mobile unit to
308
immediately stop and flash emergency lights until airport personnel can retrieve the
unit.
3.
FOD is retrieved and transported to a staging/disposal area.
Once FOD is retrieved it will be analyzed; complying with function 7.0 Provide trend
analysis functions. As this function is decomposed further (in the concept exploration
stage) questions will have to be answered about how the AFDIRTS interfaces with
retrieved FOD. For example, should the system try to account for missing components
reported by aircraft operators/support personnel? For example, if a fuel truck driver
notices a missing part on his truck, and reports it; how is this handled?
This scenario has many potentially solutions. First, the system could automatically take a
picture of the FOD and sent it electronically to aircraft operators/support personnel for
identification; or have personnel manually sort through all FOD retrieved from AOAs; or
is any of this necessary? Can the FOD just be disposed of? Feedback from stakeholders
as well as guidance from FAA Advisory Circular 150/5210-24 Airport FOD
Management will help determine how the system performs these functions.
Once operational scenarios were evaluated preliminary operational objectives were
translated into preliminary operational requirements which were subsequently
uploaded into CORE, and will be refined even further with inputs from the stakeholders
and documented in the Requirements Analysis Report during operational requirements
analysis.
Once the needs analysis phase had been completed, the system concept and
proposal paper was submitted to project mentor Jonathan Selby, Ph.D. for review.
309
Appendix B
AFDIRTS Requirements Analysis Report
310
Table of Contents
Overview. 312
Needs Statement. 312
AFDIRTS Description. 312
Systems Engineering 312
Requirements Elicitation. 315
Section I:
Survey Results. 318
Section II:
Updated User Needs.. 332
Section III:
Updated Operational Objectives.. 336
Section IV:
Updated Operational Scenarios. 338
Section V:
Competing CONOPS.. 340
Section VI:
Updated Context Diagram .. 347
Section VII:
Requirements Document.. 349
Section VIII:
Requirements Traceability & Verification Matrix. 394
Bibliography .. 408
311
Overview
The aviation industry spends approximately $7 billion dollars per year in non-bird strike
FOD damage to aircraft (McCreary, 2010). In addition to the financial burden, FOD
damage to aircraft occurring at critical moments in flight has led to loss of life and
complete destruction of aircraft. An automated FOD detection and retrieval system
would enable airports to autonomously detect, remove and track FOD on Aircraft
Operating Areas (AOA) 24 hours a day, 7 days a week.
Needs Statement
The Airfield FOD Detection, Identification, Removal and Tracking System (AFDIRTS) is to
provide a safe autonomous method of detecting, identifying, removing and analyzing
FOD trends from airports while not interfering with normal airport operations. The AFDIRTS
will provide a method of centralized command and control and be capable of
operation in inclement weather. The AFDIRTS shall be reliable, maintainable and
affordable.
AFDIRTS Description
The AFDIRTS will be designed to autonomously detect, remove and track FOD on
Airport Operating Areas. The FAA has been testing and evaluating FOD detection
systems that automatically detect FOD and notify airport personnel when discovered;
however, automated retrieval is a new concept. Analysis shows that automated
vehicle technology is mature enough to be combined with automated FOD detection
systems to provide airports with a fully automated method of detecting, retrieving and
tracking FOD on Airport Operating Areas. The Needs Analysis phase of the SE method
produced Operational Requirements that have been further refined during the
Concept Exploration phase and listed in this report.
Systems Engineering
The Requirements Analysis Report (RAR) documents the results of the Concept
Exploration Phase of the systems engineering method. The four steps of the Concept
312
Exploration phase: Operational Requirements Analysis, Performance Requirements

Formulation, Implementation Concept Exploration, and Performance Requirements
Validation have been applied to this project and the results have been listed in this
report.
In order to apply the Concept Exploration phase effectively, a system context and
multiple potential system concepts had to be clearly defined. To assist in this process,
the six primitive interrogatives described by Kossiakoff et al. (2011) were utilized. These
interrogatives: how, who, where, when, what and why; were clearly documented so
that system requirements could be developed and refined effectively. This includes the
development of performance requirements which were developed during
Performance Requirements Formulation. These performance requirements address
how much of the what interrogative was necessary to meet the need for a FOD
Detection, Identification, Removal and Tracking System.
During Concept Exploration it was necessary to consult with potential users and subject
matter experts so that these interrogatives, along with how much question could be
addressed and documented in the form of functional and performance requirements.
This was accomplished by engaging in discussions, as well as the polling of 35 subject
matter experts with a questionnaire that was designed and implemented on the
SurveyMonkey web platform. Analysis of survey results have been listed in Appendix
A. The analysis of Subject Matter Experts and Users revealed many factors that were
considered during requirements development.
System development began by posing the why question. The why interrogative
needed to be fully understood and defined. This was done during Needs Analysis and
was refined further during Operational Requirements Analysis. It is vital that the AFDIRTS
system concept has a clearly documented purpose; why is it being developed?
Operational requirements helped answer this question and were developed
systematically by the detailed analysis of users needs. (Updated SM4 user needs have
been listed in Appendix B)
Once Mission Needs were identified, Operational Objectives were developed that
could provide a solution to the mission needs (Updated SM4 Operational Objectives
313
have been listed in Appendix C). These Operational Objectives state the goal of the
system and helped facilitate the creation of Operational Requirements, which in turn;
help answer the why question.
To fully develop the system concept, the remaining interrogatives; how, who, where,
when, and what were addressed by developing Operational Scenarios (system
context) and the development of multiple competing operational concepts (CONOPS)
that could meet AFDIRTS mission needs. The refinement of Operational Scenarios (Listed
in Appendix D) helped address the where and when interrogative; while the
updated competing Concepts of Operations (Listed in Appendix E) helped address the
potential hows and whos.
According to Kossiakoff et al. (2011) requirements documentation is not carved in
stone requirements documents are living documents that are continually evolving as
the system is developed. As the AFDIRTS system concept progresses into the Concept
Definition phase, the requirement document listed in Appendix G will be refined even
further.
314
Requirements Elicitation
Air Traffic Control

The results of discussions and polling of air traffic controllers revealed their concern of
retaining the ability to control all operations conducted on aircraft movement areas.
However, even though this is a concern; Air Traffic Controller #1 believes that if they
were made to direct mobile system elements, (i.e. grant clearance for automated FOD
retrieval vehicles to enter runways and taxiways) it would become a burden to Air
Traffic Controllers. If Air Traffic Control was burdened with directing AFDIRTS system
elements the system would not be worth further development. This led to the
development of Key Performance Parameter (KPP) R.6.3 The system shall be capable
of detecting, anticipating movement and avoiding all airport traffic without input from
air traffic control. It is believed that autonomous vehicle technology is mature enough
to produce mobile system elements that are capable of detecting, anticipating
movement and avoiding traffic without the need for Air Traffic Controller direction.
Air Traffic Control #1 expressed concerns regarding the ability to have immediate
override control capability in the event of an emergency requiring movement area
clearance or system malfunction. It is believed that this capability is paramount to the
safe operation of the system; and since Air Traffic Control is already monitoring and
directing traffic they should be the ones to retain this capability. This led to the
development of KPP R.1.1.1 Air Traffic Control shall be capable of initiating an
emergency mode of operation that removes all mobile units from airfield operating
ATC -#1 expressed concerns about FOD retrieval on the grass and used a plastic bag
as an example. This capability should be incorporated into the system if possible;
however, the problem of mobile system elements dragging FOD back onto the airfield
will have to be overcome.
315
Aircraft Operators
The discussions and polling of aircraft operators revealed that they had major concerns
with the maturity of retrieval subsystem technology. More specifically, the ability of
these elements to remain clear of airport traffic. This is a concern because if aircraft
operators are uncomfortable sharing the airfield with unmanned system elements then
their animosity may result in the overutilization of crew resources (allocating them to
detect and avoid unmanned system elements versus other manned traffic); moreover,
it may have unintended consequences such as underutilization of the airfield. These
concerns lead to the realization and documentation of Risk 1.0 If aircraft operators do
not trust the systems ability to keep mobile elements clear of their aircraft, then aircraft
operators may make unnecessary errors; because they were utilizing excessive crew
resources to spot mobile system elements. and 2.0 If aircraft operators do not trust the
systems ability to keep mobile elements clear of their aircraft, then they may decide to
utilize neighboring airfields; because they feel airfields without automated FOD
detection and retrieval systems are safer. These risks along with others will be listed in
the Risk Management Report.
Aircraft Maintainers
A detailed study of the characteristics of FOD found on airfields was unrealistic for the
SM4 project. In naval aviation, maintenance personnel are utilized to perform FOD
searches on all aircraft operating areas. Since this is the case, and for the purpose of
this project; 28 Naval Aviation Maintainers from across the country were polled to help
determine the characteristics of FOD commonly found on aircraft operating areas.
The survey results show that each naval aircraft maintainer spends an average of 28
minutes a day searching for FOD on military airfields. The large amount of time
searching for FOD on airfields not only reinforces the need for an Airfield FOD Detection,
Identification, Removal and Tracking System; but gives credibility to the naval aircraft
maintainers ability to make accurate assessments regarding the characteristics of FOD
found on airfields.
316
The results of Naval Aircraft Maintainer polling estimates that the percentage of FOD
found weighing over 1lb is less than .24 percent on aircraft ramps, less than .25 percent
on airport taxiways, and less than .19 percent on runways.
From these results, it is believed that a FOD retrieval system should be capable of
retrieve FOD weighing at least 1 pound to be effective. This would permit the
automated retrieval of over 99.75 percent of all FOD and led to the development of
KPP R.5.2 The FOD retrieval subsystem shall be capable of retrieving FOD weighing up
to 1 pound or .45359237 kilograms.
Respondent #MilMaint-27 discussed the commonalities of the majority of FOD found on
airfields; stating that The most common FOD I've found in 14 years experience is 99%
random hardware such as nuts, bolts, rivets, safety wire & rocks. His statement along
with discussions from other SMEs and feasibility constraints placed upon the physical
characteristics of retrieval sub-system concepts led to the development of KPP R.5.4
The FOD retrieval subsystem shall be capable of retrieving FOD with dimensions of up
to 12 inches in length 12 Inches in width and 12 inches in height.
317
Section I
Survey Results
318
Survey Results
Participant Qualifications
Respondent #ATC-1
Name: Colleen Raney
Occupation: Air Traffic Control
Job Title: Military Radar
Unit/Mission Controller
Respondent #Aircraft Operator-1

Name: Mark Little
Occupation: Pilot
Job Title: Airline Pilot
Respondent #Aircraft Operator -2

Name: Clint Early
Occupation: Pilot
Job Title: Pilot - American Airlines

Name Jason Piper
Occupation: Pilot
Job Title: Airline Captain

Name: James Mitchell Williams
Occupation: Pilot
Job Title: Captain 767

Name: Sam Greco
Occupation: Pilot
Job Title: Airbus A320/321 Captain

Name: Bryan O'Reilly
Occupation: Pilot
Job Title: Pilot
Respondent #MilMaint-1
Name: John Laine
Occupation: Military Aircraft
Maintenance
Job Title: : NAVAIR Corrosion
Analyst
Name: Armando Rodriguez
Maintenance
Job Title: Maintenance Master
Chief
Name: Martin J. Wydra
Maintenance
Job Title: VX-23 FOD Program
Manager
Name: John Svoboda
Maintenance
Job Title: QA Inspector
Name: Steve B.
Maintenance
Job Title: QA Inspector
Name: Kristopher Micon
Maintenance
Job Title: Maintenance Chief
Name: Anonymous
Maintenance
Job Title: Maintenance Officer
Name: Bauer, Edgar
Maintenance
Job Title: Workcenter Supervisor
Name: Gary Wilson
Maintenance
Job Title: Avionics Tech
Name: Scott
Maintenance
Job Title: A/C Mechanic
Name: Ronnie E Mendoza
Maintenance
Job Title: Maintenance Control
Chief
Name: Aaron R Graybill
Maintenance
Job Title: Aviation Electronics
Technician
Name: Michael Muncy
Maintenance
Job Title: Division Chief
Name: Quentin Salmons
Maintenance
Job Title: Maintenance Chief
319
Name: Justin Monahan
Maintenance
Technician
Name: Jay Daniel Oliver
Maintenance
Job Title: Aviation Structural
Mechanic
Name: William
Maintenance
Technician
Name: Anonymous
Maintenance
Job Title: Aviation Mechanic
Name: Chris Reynolds
Maintenance
Job Title: Quality Assurance
Supervisor
Name: Anonymous
Maintenance
Job Title: Aircrew Survival
Equipment
Name: Anonymous
Maintenance
Technician
Name: Jennifer
Maintenance
Job Title: Aviation Electrician
Name: Melissa Phaff
Maintenance
Mechanic
Name: Dan Crivello
Maintenance
Job Title: Aviation Machinist Mate
Name: Anonymous
Maintenance
Job Title: Aviation Mechanic
Name: Mark Ugi
Maintenance
Job Title: Quality Assurance
Supervisor
Name: Anonymous
Maintenance
Mechanic
Name: Anonymous
Maintenance
Mechanic
320
Air Traffic Control

Number of respondents: 1
Question #1: (This question applies to Small Hub Airports only) On a scale from 1 (no
burden) to 5 (enormous burden) please rate how much of a burden would it be on
controllers to grant clearance for automated FOD retrieval vehicles to enter runways
and taxiways if the system was unable to detect and avoid traffic completely on its
own.
Answers
ATC-1:Somewhat of a burden
Question #2: (This question applies to Land Based Military Airports only) On a scale from
1 (no burden) to 5 (enormous burden) please rate how much of a burden would it be
on controllers to grant clearance for automated FOD retrieval vehicles to enter runways
and taxiways if the system was unable to detect and avoid traffic completely on its
own.
Answers
ATC-1:Somewhat of a burden
Question #3: Please add any thoughts you have in regards to the development of an
automated FOD detection and retrieval system from an ATC perspective. This could be
anything... functions you think would be required, problems you would expect to
encounter or elaborate on risk.
Answers
ATC-1:
R1. Detection reliability of system (false or inaccurate FOD detection). What is an
acceptable margin of error?
R2. Timeliness of system deployment and execution upon detection as compared to
large manned airfield 'sweeper' vehicles currently in use
321
R3. The degree of autonomy. Will overrides or fail-safes be implemented to prevent

unauthorized access to certain airport areas?
R4. The size of the retrieval system and protection of the unit(s) when in use. Will there
be airport movement restrictions for vehicular and aircraft movement when these units
are in use? Is the unit large enough to be clearly seen by all vehicles moving on the
airport surface, as well as from the tower controller when scanning the runway with the
naked eye?
R5. Control capability from the tower controllers. More on this in the next section.
automated FOD detection and retrieval system from an ATC perspective. This could be
anything... functions you think would be required, problems you would expect to
encounter or elaborate on risk.
Answers
ATC-1:
The risks should be self-explanatory. The major concerns from a control tower
standpoint are control capabilities, reliability and functionality. Tower controllers must
have complete control of all operations conducted on their movement areas. Will they
have immediate override control capability in the event of an emergency requiring
movement area clearance or system malfunction? I believe that absolutely needs to
be a priority above all else.
Tower controllers are constantly scanning the airport movement area, and airfield
management personnel are also scanning from their vehicles to detect FOD hazards.
They are able to distinguish between stationary, immediate FOD hazards and potential
hazards (i.e. a plastic bag blowing through the grass near the runway). Will the system
be able to detect those hazards not on the immediate surface area but still a potential
hazard? If not, will tower controllers be able to send the retrieval system to any specific
point on the airfield (even in the grass) to retrieve? Is the vehicle capable of doing that
or would airfield personnel need to be contacted for cleanup. A vehicle venturing into
the grass would require a FOD check of itself prior to entering the movement areas
322
again, so there is that to think about if the vehicle is in fact capable of non-movement
area cleanup
Takeaways: A major concern for Air traffic Controllers is that they retain the ability of
have complete control of all operations conducted on the movement areas. However,
when asked how much of a burden would it be on controllers to grant clearance to
FOD vehicles respondent #1 replied somewhat of a burden.
If the system is designed to automatically detect and avoid aircraft movement,
controllers would not have the additional burden of granting clearance to automated
system elements. However, since the controllers orchestrate movement along the
airfield, controllers should have the ability to remove system elements from the airfield
when the need arises.
ATC -1 expressed concerns about FOD retrieval on grass and used a plastic bag as an
example. This capability should be incorporated into the system if possible.
323
Aircraft Operators
Overview:
Question #1: If a fully automated FOD detection and retrieval system was made
available to autonomously detect and avoid aircraft while searching for and retrieving
FOD. What level of reliability should it have for you as an operator to feel comfortable
sharing the airfield with these units? This can be expressed however you choose. (i.e. 1
incident per 365 days of operation, 100 percent reliable....etc.)
Answers
Aircraft Operator - 1:
99.5%
50% reliable
I would say reliability in the middle to high 90s. There's always

some odd scenario that can't be planned or designed for
99.9%
100% regarding avoidance of aircraft.
100%
automated FOD detection and retrieval system from an Airline Pilot perspective. This
could be anything... functions you think would be required, problems you would expect
to encounter or elaborate on risk.
Answers
Aircraft Operator 1:
Maybe something such as a light beam (i.e. Electric eye)

that would detect an obstruction would be most feasible.
They have been testing a FOD system in DFW. Most pilots

know little to nothing about it. I have a brother-in-law at
DFW FAA maintenance so I know a little more - a little.
324
Make it simple. Red light means don't taxi onto, cross the
runway or takeoff. Light goes out or turns green - go.
I would think the difficulty would be mobility. A system

functioned to get FOD off the field in Arizona, would have
much different propulsion than one in Chicago with feet
of snowbanks
My concern would only be that the retrieval system

becomes the FOD.
Interference with aircraft would be a top concern. It

should supplement, not replace, human inspections of
airport surfaces.
Respondent skipped this question
Takeaways: System reliability is a big concern for pilots with 4 out of 6 aircraft operators
responding that the system should have near %100 reliability regarding the avoidance
of aircraft.
In order for the system to be safe and effective, users must have complete trust that
mobile system elements will remain clear of traffic. If operators begin to second guess
mobile system element reliability, then the crew resources required to avoid a possible
incursion between mobile system elements and aircraft could distract aircrew to the
point of jeopardizing safe airfield navigation. It is expected that upon initial operating
capability aircraft operators may be speculative (and therefore distracted) of sharing
the airfield with unmanned mobile system elements; however, this risk can be minimized
over time by a combination of training, successful operations and the minimization of
the mobile elements potential to damage aircraft by its design.
325
Aviation Maintenance (Military Aircraft)

Overview:
Question #1: How many hours a day do you estimate is spent on FOD walkdown during
land based operations at your present or prior command. This is the total time it takes to
complete a daily FOD walkdown for all shifts. For example, if the command (on
average) takes 15 minutes on both the day and night shifts, then the command would
have spent 30 minutes a day on FOD walkdown.
Answers
MilMaint-1: 21 to 30 min
MilMaint-4: Over 45 min
MilMaint-26: 1 hour
MilMaint-6: < 10 min
MilMaint-10 1 hour
Median of each respondents answer:

25.5
10
25.5
25.5
25.5
60
15.5
25.5
15.5
35.5
15.5
15.5
35.5
25.5
25.5
25.5
25.5
15.5
45
45
25.5
15.5
25.5
45
60
25.5
35.5
15.5
326
Average:
28 Minutes
Question #2: On average how many personnel participate in ALL daily command FOD
walkdowns? For example, if 15 participate on days and 20 participate on nights; 35
personnel would have participated in that days FOD walkdown.
Answers
MilMaint-1: 35
MilMaint-12: 25
MilMaint-23: 20
MilMaint-2: 35
MilMaint-13: 30
MilMaint-24: 35
MilMaint-3: 35
MilMaint-14: 35
MilMaint-25: 35
MilMaint-4: 35
MilMaint-15: 35
MilMaint-26: 35
MilMaint-5: 35
MilMaint-16: 35
MilMaint-27: 25
MilMaint-6: 5
MilMaint-17: 35
MilMaint-28: 25
MilMaint-7: 35
MilMaint-18: 25
MilMaint-8: 35
MilMaint-19: 25
MilMaint-9: 35
MilMaint-20: 30
MilMaint-10: 100
MilMaint-21: 30
MilMaint-11: 35
MilMaint-22: 20
Average of each respondents answer:

35
35
35
30
35
35
35
25
35
20
25
35
35
30
25
20
25
35
35
35
25
35
35
100
35
30
35
Average:
33 Personnel
327
Question #3: During FOD walkdown on respective airfield locations; please estimate the
percentage of FOD found weighing over 8 oz. or 1/2 of a pound.
Answers
Respondent
Aircraft Ramp
Taxiway
Runway
MilMaint-1:
<0%
<0%
<0%
MilMaint-2:
<2%
<2%
<2%
MilMaint-3:
<20%
<0%
<0%
MilMaint-4:
<0%
<0%
<0%
MilMaint-5:
<2%
<2%
<2%
MilMaint-6:
<10%
<0%
<0%
MilMaint-7:
<2%
<2%
Dont Know
MilMaint-8:
<5%
<2%
<0%
MilMaint-9:
<2%
<2%
<10%
MilMaint-10:
<2%
<2%
<2%
MilMaint-11:
<2%
<5%
<5%
MilMaint-12:
<0%
<0%
<0%
MilMaint-13:
<0%
<0%
<0%
MilMaint-14:
<2%
<2%
<2%
MilMaint-15:
<2%
<0%
<0%
MilMaint-16:
<0%
<0%
<0%
MilMaint-17:
<0%
<0%
<0%
MilMaint-18:
<2%
<0%
<0%
MilMaint-19:
<20%
<20%
Dont Know
MilMaint-20:
<5%
<2%
<2%
MilMaint-21:
Dont Know
Dont Know
Dont Know
MilMaint-22:
<2%
<2%
<2%
MilMaint-23:
<10%
<5%
<0%
MilMaint-24:
<0%
<0%
<0%
MilMaint-25:
<0%
<0%
<0%
MilMaint-26:
<0%
<0%
<0%
328
MilMaint-27:
<2%
Dont Know
Dont Know
MilMaint-28:
Dont Know
Dont Know
Dont Know
<2.62%
<1.41%
<.84%
Average:
Question #4: During FOD walkdown on respective airfield locations; please estimate the
percentage of FOD found weighing over 1 pound.
Answers
Respondent
Aircraft Ramp
Taxiway
Runway
MilMaint-1:
<0%
<0%
<0%
MilMaint-2:
<2%
2%
2%
MilMaint-3:
<0%
<0%
<0%
MilMaint-4:
<0%
<0%
<0%
MilMaint-5:
<0%
<0%
<0%
MilMaint-6:
<0%
<0%
<0%
MilMaint-7:
<0%
<0%
<0%
MilMaint-8:
<2%
<2%
<0%
MilMaint-9:
<0%
<0%
<2%
MilMaint-10:
<0%
<0%
<0%
MilMaint-11:
Dont Know
Dont Know
Dont Know
MilMaint-12:
<0%
<0%
<0%
MilMaint-13:
<0%
<0%
<0%
MilMaint-14:
<0%
<0%
<0%
MilMaint-15:
<0%
<0%
<0%
MilMaint-16:
<0%
<0%
<0%
MilMaint-17:
<0%
<0%
<0%
MilMaint-18:
<0%
<0%
<0%
MilMaint-19:
<2%
<2%
Dont Know
MilMaint-20:
<0%
<0%
<0%
329
MilMaint-21:
Dont Know
MilMaint-22:
<2%
<2%
MilMaint-23:
<0%
<0%
MilMaint-24:
Dont Know
MilMaint-25:
<0%
<0%
MilMaint-26:
<0%
<0%
MilMaint-27:
<0%
Dont Know
Dont Know
MilMaint-28:
Dont Know
Dont Know
Dont Know
Dont Know
Dont Know
Dont Know
Dont Know
Average:
< .24%
< .25%
< .19%
automated FOD detection and retrieval system from a military aircraft maintenance
perspective. This could be anything... functions you think would be required, problems
you would expect to encounter or elaborate on risk.
***Only Respondents that answered the question have been listed***
Answers
MilMaint-2:
Robotic magnetic brooms
MilMaint-7:
Many times on older ramps, especially those on seawalls, there is

steady deterioration of the actual concrete and expansion joints
that is subjectively cleaned up. Another challenge to automation
would be the variation of pad eyes along a single ramp.
MilMaint-9:
I believe that the expense to install this system will make this a low
priority and may never actually happen in this current cost slashing
government.
MilMaint-10:
Tracking and documentation is important to identify FOD prone

areas.
MilMaint-12:
How about a vacuum like the Roomba. Somehow able to identify

parameters of the search area and make sweeps of the area on a
regular basis
MilMaint-20:
Maintenance on the automated system itself.

330
MilMaint-26:
I'm not sure of the technology of something like this, to be able to

detect small pieces of metal/wood/stone/composite/rubber etc.
at an affordable price. Affordable as compared to man-hours
spent now. Also not sure how automated system would work in
conjunction with flight operations on a daily basis, i.e. having a
roaming FOD machine driving around during the taxi of aircraft or
in inclement weather situations. Sounds like a neat idea though!
MilMaint-27:
The most common fod I've found in 14 years experience is 99%

random hardware such as nuts, bolts, rivets, safety wire & rocks.
Occasionally you will find FOD from work vehicles and support
equipment on the ramp. If a developed machine could tell the
difference between asphalt/concrete & something metal, then
pending the machines ability to scan far distances and determine
differences in composition between the two, you may have
something worth utilizing. But, as machines age and their parts
wear, they could also risk becoming the cause of potential FOD as
well.
Takeaways:
28 Military maintenance personnel were polled from Navy organizational aircraft
maintenance squadrons across the country. The survey reviled that Military personal
spend an average of 28 Minutes per shift utilizing 33 personnel to search for FOD on
aircraft operating areas. This results in 15.4 man-hours per day per Navy unit.
Since military personnel spend an average of 28 Minutes searching for FOD it is

reasonable to assume that they are knowledgeable of FOD characteristics
found in different locations on military airfields. On average, military personnel
estimate that the amount of FOD discovered on military airfields weighing over a
pound is less than .25% or less than 1 in 400.
331
Section II.
Updated User Needs
332
User Need Airport Users/Aircraft Operators
Satisfied by Operational Objective
MN-AU-01
A FOD free airfield.
OO-02, OO-03, OO-05, OO-08, OO-12
MN-AU-02
Confidence that the system put in place to keep
OO-01
operating areas clear of FOD will not become a

hazard to airfield operations.
User Need Air Traffic Control

MN-ATC-01
Confidence that the systems put in place to keep
OO-01

MN-ATC-02
Timeliness of system deployment and execution
OO-02, OO-05, OO-06
upon FOD detection.

MN-ATC-03
The ability to cease operations from the tower.
OO-01
MN-ATC-04
A system that does not complicate duties or cause
OO-01, OO-02, OO-06
distractions.
333
MN-ATC-05
A method of communicating with the system.
OO-09
User Need Airport Managers

MN-AM-01
Confidence that systems put in place to keep
OO-01

MN-AM-02
A method of providing FOD tracking and trend
OO-07
analysis so that better decisions are made

regarding prevention efforts.
MN-AM-03
A method of receiving technical support.
OO-08
MN-AM-04
A method of receiving information from the
OO-09
system.
MN-AM-05
A system that complies with existing installation
OO-10
standards.
User Need Airfield Workers

MN-AW-01
A FOD free airfield.
OO-02, OO-03, OO-05, OO-08, OO-12
334
MN-AW-02
Confidence that system put in place to keep
OO-01

MN-AW-03
A method of being alerted and given the location
OO-02, OO-03, OO-04, OO-06
of FOD that cannot be retrieved by the system.

MN-AW-04
A method of being notified of defective system
OO-11
elements.
User Need System Maintainers

MN-SM-01
Clear and unambiguous preventative and
OO-11
corrective maintenance instructions.

MN-SM-02
Ease of access to system elements for preventative
OO-11
maintenance.
MN-SM-03
Efficient and effective and training system.
OO-08
MN-SM-04
A Method of testing and troubleshooting system
OO-08
components.
MN-SM-05
Access to electrical power on stationary airfield
OO-08, OO-11
elements if required for test equipment.

MN-SM-06
A method of communicating with the system.
OO-09
335
SECTION III.
Updated Operational Objectives
336
Operational Objectives
Number
OO-01
Provide safe operation.
OO-02
Provide efficient and effective system command, control.
OO-03
Provide a method of airfield scanning and FOD detection.
OO-04
Provide a method of FOD reporting.
OO-05
Provide a method of FOD retrieval.
OO-06
Facilitate mobile element Locomotion.
OO-07
Provide FOD trend analysis.
OO-08
Provide technical support.
OO-09
Provide a method of communicating with external system elements.
OO-10
Comply with installation and acceptance standards.
OO-11
Provide a reliable, maintainable, and available system.
OO-012
Facilitate adverse weather operation.
337
Section IV.
Updated Operational Scenarios
338
1. FOD is detected on the Airfield.

During this scenario, FOD will have been detected as a result of the Detect FOD
function. Once this occurs, suitability for retrieval must be ascertained. If it is an animal
carcass the automated retrieval system will not be capable of retrieving it; therefore,
airport personnel must be notified and given the location of the object so it may be
manually removed.
Once FOD is determined to be suitable for automated retrieval, the location must be
transmitted to automated retrieval subsystem. This function can be performed in
multiple ways however, there have been some constraints placed upon this function. If
the FOD Detection Subsystem and FOD Retrieval Subsystem are not combined (i.e. as in
CONOPS #1 the Roomba Option) then developers must identify a method of
ascertaining the FODs location on the AOA and then transmitting this location to the
Retrieval Subsystem. This can be done utilizing both active and passive methods.
If an active method of detection is used (i.e. Radar) then the Radar must NOT interfere
with existing airport systems. If a passive method of detection is utilized (i.e. camera)
and an active method of transmitting the FODs location to mobile retrieval subsystems
(such as a light beam) then this method must NOT cause a distraction to aircraft or
support vehicles operating on the Airfield. Once mobile units receive the FOD location,
they will have to perform a series of functions, in order to navigate to the FOD, retrieve
it, and navigate to the staging/disposal area.
2. FOD is retrieved and transported to a staging/disposal area.
After the retrieval subsystem receives notification of potentially suitable FOD and its
location from the FOD detection subsystem; the system must navigate to the FOD,
determine its suitability for transport (size and weight), and then transport it to the
disposal/staging area. Accomplishing this will require that multiple subsystems perform
many functions. The retrieval subsystem must receive the objects location and then
subsequently navigate to its location while avoiding air and ground traffic. Once the
retrieval subsystem arrives at the FODs location it must grasp the object and ascertain
its suitability for transport, then finally transport the FOD to the disposal/staging area; all
while detecting and avoiding traffic.
339
Section V.
Competing CONOPS
340
CONOPS #1 (Roomba Option shown in Figure 1)

This concept makes use of roaming mobile units that continuously detect and remove
FOD from aircraft operating areas. This method will require that these units continuously
traverse the airfield, avoiding obstacles and airport ground traffic. Once FOD is
detected the system will either retrieve it, or in the case of larger items; transmit the
location to airport personnel for retrieval.
Advantages
-
Utilizing the combined FOD detection and retrieval subsystem configuration will
eliminate the need to transmit the precise location of FOD to retrieval subsystems
since the retrieval system will already be at the location of the detected FOD.
There is no need for a permanent FOD detection infrastructure.
Since both retrieval and detection subsystems are mobile they can be easily
integrated into existing airfields.
System elements can be easily removed from the airfield in the case of inclement
weather.
Operational Availability (A O ) will benefit since detection and retrieval subsystems

can be replaced with operational units during scheduled and unscheduled
maintenance.
Disadvantages
-
The mobile detection system will unlikely be capable of detecting and retrieving
quickly moving FOD (such as a plastic bag).
In order for the mobile units to travel over unpaved airport surfaces (such as a grass
area), a method of removing FOD from the units themselves; must be developed to
prevent FOD from migrating onto the airfield.
The system will not be able to make use of existing Commercial off the Shelf (COTS)
FOD detection systems.
In order to meet requirement R.3.1.1 The system shall be capable of detecting FOD
within 4 minutes of a FOD occurrence will require many units.
341
Command
and Control
Elements
Reports
Maintenance
Obstacle
Detection and
Avoidance
FOD Detection and

Retrieval
Figure 1. AFDIRTS CONOPS #1 (Roomba Option)
342
CONOPS #2 (Ground retrieval option shown in Figure 2)

This concept makes use of existing COTS FOD detection systems that continuously
sweep the airfield for FOD. This concept will be capable of identifying objects that are
obviously to large for retrieval (such as an animal carcasses) and transmitting their
location to airport personnel for retrieval. Once FOD is determined to be potentially
suitable for automated retrieval, a mobile unit will be sent to the FODs location. This will
be accomplished by autonomously navigating the airfield (detecting and avoiding
airport traffic) and once on station, the system will make another determination of
suitability for automated retrieval. If it is determined to the FOD is suitable for retrieval,
the mobile unit will collect the FOD and navigate to the staging/disposal area.
Advantages
-
Utilizing existing FOD detection technology will minimize development costs normally
associated with new system development.
Since there will be many detectors operating from a distance, the system will be
capable of quickly sweeping the airfield for FOD.
The maturity of mobile retrieval subsystem locomotion elements will maximize system
reliability.
Disadvantages
-
The mobile retrieval system element will unlikely be capable of retrieving fast moving
FOD (such as a plastic bag).
In order for the mobile retrieval units to travel over unpaved airport surfaces (such as
a grass area), a method of removing FOD from the units themselves; must be
developed to prevent FOD from migrating onto the airfields.
343
Command
and Control
Elements
Reports
Maintenance
Obstacle
Detection and
Avoidance
FOD
Detection
FOD Retrieval
Figure 2. AFDIRTS CONOPS #2 (Ground Retrieval Option)
344
CONOPS #3 (airborne option shown in figure 3)

This concept will also make use of existing COTS FOD detection systems. However, the
retrieval subsystem will be airborne. This system concept will allow the retrieval
subsystem elements to more easily navigate the airfield by allowing retrieval units to
navigate above obstacles and gassy areas that would normally require complex
navigation patterns to avoid. The detection subsystem will be capable of identifying
objects that are obviously too large for retrieval (such as an animal carcasses) and
transmitting their location to airport personnel for retrieval. Once FOD is determined to
be potentially suitable for automated retrieval, a mobile airborne unit will be sent to the
FODs location. The airborne unit will collect the FOD and navigate to the
staging/disposal area.
Advantages
-
The ability of retrieval units to navigate over obstacles can decrease retrieval time
and minimize navigation complexity.
The potential for airborne retrieval units to nimbly transverse the airfield over paved
and unpaved surfaces; may allow the airborne units to retrieve migrating FOD (i.e.
plastic bags, cardboard, and paper)
Once FOD was retrieved from grassy areas dragging FOD back onto the airfield as a
result of surface contact would not be a concern.
If the system is successful, the FAA may see drones as an advantage to the
aviation community.
The airborne units have the potential to be utilized as a bird deterrent.
Disadvantages
-
The drone technology may be frowned upon by the FAA; and getting approval
for the units to operate may involve too much time navigating bureaucratic red
tape.
Airborne units will be more susceptible to course deviation due to wind gusts and jetblast.
345
Command
and Control
Reports
Maintenance
FOD
Detection
Obstacle
Detection and
Avoidance
FOD
Disposal
FOD Retrieval
Figure 3. AFDIRTS CONOPS #3 (Airborne Option)
346
SECTION VI.
Updated Context Diagram
347
Air Traffic
Control
Environment
Command (D)
Heat (E) Sand (M)
Salt (M) Hail (M)
Ice (M) Water (M)
Wind (F) Cold (E)
FAA
Airport
Managers
Health (D)
Unsuitable FOD
Location (D)
Heat (E)
Sound (E)
Resistance (F)
Unsuitable FOD
Location (D)
Status (D)
Reports (D)
Reports (D)
Obstacle Detection (E)
Obstacles
Location (D)
AFDIRTS
Visual Location (E)

Visual Trajectory (E)
Electrical
Energy (E)
Forces (F)
Energy (E)
Data (D)
Signals (S)
Materials (M)
Visual FOD
Location (E)
Visual FOD
Identification (D)
Aircraft
Operators
Parts (M)
Materials (M)
Fault Codes (D)
FOD
Excess
Electrical (E)
Parts (M)
Materials (M)
SW Update (S)
Query (S)
Power
Maintainer
Figure 1. Updated Context Diagram
348
Section VII.
Requirements Document
349
Section VII. Requirements Document

KEY PERFORMANCE PARAMETERS

R.2.4 Power Failure
R.5.2 FOD Weight
The system shall be capable of retrieving FOD weighing up to 1 pound (.45359237
kilograms)
350

ORIGINATING REQUIREMENTS
R Need Statement
The Airfield FOD Detection, Identification, Removal and Tracking System (AFDIRTS)
is to provide a safe autonomous method of detecting, identifying, removing and
analyzing FOD trends from airports while not interfering with normal airport
operations. The AFDIRTS will provide a method of centralized command and
control (KPP R.2.1) and be capable of operation in inclement weather. The
AFDIRTS shall be reliable, maintainable and affordable.
R.1 Safe Operation
R.4 FOD Reporting
R.5 FOD Retrieval
351
R.1 Safe Operation
hier Safe Operation

R.1
Safe Operation
Requirement
R.1.1
R.1.1.1
verified by
refined by
Emergency
Demonstration
Requirement
VerificationRequ...
refined by
verified by
Execution Speed
Test
Requirement
VerificationRequ...
Date:
November 7, 2015
Figure 1. Safe Operation Requirements Hierarchy Diagram
The system shall not cause damage to airport personal or property; nor shall it
become a distraction to operations or support personnel.
R Need Statement
R.1.1 Emergency
OO-1 Provide safe operation
352

hier System Command and Control

R.2
System Command
and Control
Requirement
basis of
R.2.1
refined by
refined by
R.2.2
R.2.3
refined by
R.2.4
refined by
verified by
Command and
Control System
System Command
Location of
Aircraft
Unsuitable FOD
Power Failure
Test
Function
Requirement
Requirement
Requirement
Requirement
VerificationRequ...
verified by
verified by
verified by
verified by
Test
Test
Test
Test
VerificationRequ...
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
Figure 2. System Command and Control Requirements Hierarchy Diagram
The system shall be capable of centralized command and control of all system
elements.
R Need Statement
R.2.4 Power Failure
OO-2 Provide efficient and effective system command and control.
353
hier FOD Scanning and Detection

R.3
FOD Scanning
and Detection
Requirement
R.3.1
refined by
Airfield Scanning
verified by
Demonstration
FOD Detection
Requirement
R.3.1.1
refined by
R.3.2
VerificationRequ...
Requirement
verified by
refined by
Detection Time
Demonstration
Requirement
VerificationRequ...
verified by
basis of
R.3.2.1
refined by
Detect FOD
Group Object
Detection
Function
Requirement
Demonstration
R.3.2.2
R.3.2.4
refined by
Metal Cylinder
Detection
Requirement
verified by
R.3.2.3
refined by
Sphere Detection
Requirement
Test
R.3.2.5
refined by
verified by
Automated
Test
Requirement
Requirement
VerificationRequ...
verified by
verified by
verified by
verified by
Test
Test
VerificationRequ...
VerificationRequ...
VerificationRequ...
refined by
Lighting
Conditions
Test
Test
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
Figure 8. FOD Scanning and Detection Requirements Hierarchy Diagram
The system shall be capable of scanning the airfield and detecting single and
multiple FOD items.
R Need Statement
R.3.2 FOD Detection
OO-3 Provide a method of airfield scanning and FOD detection.
354

R.4 FOD Reporting
hier FOD Reporting

R.4
FOD Reporting
Requirement
R.4.1
R.4.1.1
refined by
R.4.1.2
refined by
verified by
FOD Location
Reporting
Demonstration
Requirement
VerificationRequ...
refined by
R.4.1.3
refined by
verified by
Active Reporting
Passive Reporting
Suitability
Reporting
Test
Requirement
Requirement
Requirement
VerificationRequ...
Date:
November 7, 2015
Figure 3. FOD Reporting Requirements Hierarchy Diagram
The system shall be capable of reporting FOD location data and FOD
characteristics to the retrieval subsystem.
R Need Statement
OO-4 Provide a method of FOD Reporting.
355

R.5 FOD Retrieval
hier FOD Retrieval

R.5
FOD Retrieval
Requirement
R.5.1
refined by
R.5.2
refined by
R.5.3
refined by
R.5.4
refined by
verified by
FOD Weight
Determination
FOD Weight
FOD location
FOD Dimensions
Demonstration
Requirement
Requirement
Requirement
Requirement
VerificationRequ...
verified by
verified by
verified by
verified by
Test
Test
Test
Test
VerificationRequ...
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
Figure 4. FOD Retrieval Requirements Hierarchy Diagram
The system shall be capable autonomously retrieving FOD from both paved and
grass surfaces.
R Need Statement
R.5.2 FOD Weight
R.5.3 FOD location
OO-05 Provide a method of FOD retrieval.
356

hier Mobile Unit Locomotion

R.6
Mobile Unit
Locomotion
Requirement
R.6.1
refined by
R.6.2
refined by
R.6.3
refined by
refined by
R.6.4
R.6.5
refined by
R.6.6
refined by
R.6.7
refined by
verified by
Mobile Unit Speed
Mobile Unit
Navigation
Mobile Unit
Movement Clea...
Separation from
Obstacles
Separation from
Aircraft
Separation from
Personnel
Separation from
Vehicles
Test
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
VerificationRequ...
verified by
R.6.2.1
refined by
R.6.2.2
refined by
Demonstration
FOD Location
Emergency
Posture
VerificationRequ...
Requirement
Requirement
R.6.2.3
refined by
verified by
verified by
verified by
verified by
verified by
verified by
Standby Location
Demonstration
Demonstration
Test
Test
Test
Test
Requirement
VerificationRequ...
VerificationRequ...
VerificationRequ...
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
Figure 5. Mobile Unit Locomotion Requirements Hierarchy Diagram
The system shall provide a method of locomotion for mobile system elements.
R Need Statement
OO-06 Facilitate mobile element locomotion.
357


hier Provide FOD Trend Analysis
R.7
Provide FOD
Trend Analysis
Requirement
basis of
refined by
R.7.1
verified by
Analyze FOD
Trends
Types of Data
Demonstration
Function
Requirement
VerificationRequ...
R.7.1.1
refined by
verified by
Storage of Data
Test
Requirement
VerificationRequ...
refined by
R.7.1.1.1
verified by
Data Retention
Test
Requirement
VerificationRequ...
verified by
Demonstration
VerificationRequ...
Date:
November 7, 2015
Figure 6. Provide FOD Trend Analysis Requirements Hierarchy Diagram
The system shall provide a method of trend analysis.
R Need Statement
R.7.1 Types of Data
OO-07 Provide FOD trend analysis.
358

hier System Communication

R.8
System
Communication
Requirement
R.8.1
refined by
R.8.2
refined by
R.8.3
refined by
verified by
ATC
Communication
Airport
Management C...
Maintainer
Communication
Demonstration
Requirement
Requirement
Requirement
VerificationRequ...
verified by
verified by
verified by
Demonstration
Demonstration
Demonstration
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
Figure 7. System Communication Requirements Hierarchy Diagram
The system shall provide a method of communicating with air traffic control,
airport management, and system maintainers.
R Need Statement
OO-09 Provide a method of communicating with external system elements.
359


hier Technical Support
R.9
Technical Support
Requirement
R.9.1
R.9.1.1
refined by
R.9.1.2
refined by
refined by
R.9.2
refined by
verified by
Maintenance
Procedures
Call Center
Analysis
Requirement
Requirement
VerificationRequ...
R.9.1.3
refined by
R.9.1.4
refined by
verified by
verified by
Cleaning
Procedures
Preventative
Maintenance Pr...
Recalibration Plan
Scheduled
Component Re...
Analysis
Demonstration
Requirement
Requirement
Requirement
Requirement
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
Figure 8. Technical Support Requirements Hierarchy Diagram
System users shall be provided with technical support.
R Need Statement
R.9.2 Call Center
OO-08 Provide technical support.
360


hier Installation and Acceptance Standards
R.10
Installation and
Acceptance Sta...
Requirement
R.10.1
R.10.1.1
refined by
R.10.1.2
refined by
refined by
verified by
Elements Located
Near The Runway
Inspection
Requirement
VerificationRequ...
R.10.1.3
refined by
R.10.1.4
refined by
verified by
Breakaway
Connector
Element Height
Frangible Coupling
Wind Loading
Inspection
Requirement
Requirement
Requirement
Requirement
VerificationRequ...
Date:
November 7, 2015
Figure 9. Installation and Acceptance Standards Requirements Hierarchy Diagram
The system shall conform to applicable airport obstruction criteria, marking and
lighting, and equipment design and installation standards.
R Need Statement
OO-10 Comply with installation and acceptance standards.
361


hier Reliability, Availability and Maintainability
R.11
Reliability,
Availability and...
Requirement
R.11.1
refined by
R.11.2
refined by
verified by
System
Availability
System
Maintainability
Analysis
Requirement
Requirement
VerificationRequ...
verified by
R.11.2.1
refined by
R.11.2.2
refined by
verified by
Analysis
System Health
Equipment
Located Outside...
Analysis
VerificationRequ...
Requirement
Requirement
VerificationRequ...
Date:
November 7, 2015
Figure 10. Reliability, Availability and Maintainability Requirements Hierarchy Diagram
The system shall provide a high level of reliability, availability and maintainability.
R Need Statement
OO-11 Provide a reliable, maintainable, and available system.
362


hier Operate in Adverse Weather Conditions
R.12
Operate in
Adverse Weathe...
Requirement
R.12.1
refined by
R.12.2
refined by
R.12.3
refined by
verified by
Performance in
Rain
Performance in
Snow
Performance in
Wind
Test
Requirement
Requirement
Requirement
VerificationRequ...
verified by
verified by
verified by
Test
Test
Test
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
Figure 11. Operate in Adverse Weather Conditions Requirements Hierarchy Diagram
The system shall be capable of operating in rain, wind and snow.
R Need Statement
OO-12 Facilitate adverse weather operation.
363

FUNCTIONAL REQUIREMENTS
R.1.1 Emergency
hier Emergency
R.1.1
Emergency
Requirement
R.1.1.1
refined by
verified by
Execution Speed
Test
Requirement
VerificationRequ...
verified by
Demonstration
VerificationRequ...
Date:
November 7, 2...
Figure 12. Emergency Requirements Hierarchy Diagram

The system shall be capable of entering an emergency mode of operation that
removes mobile units from Airport Operating Areas.
R.1 Safe Operation
Air Traffic Control shall be capable of initiating system modes.
364


The system shall be capable of determining the location and trajectory of inbound
aircraft.
The system shall be capable of notifying airport personnel when FOD is
determined to be unsuitable for automated retrieval.
hier Airfield Scanning

R.3.1
Airfield Scanning
Requirement
R.3.1.1
refined by
verified by
Detection Time
Demonstration
Requirement
VerificationRequ...
verified by
Demonstration
VerificationRequ...
Date:
November 7, 2...
Figure 13. Airfield Scanning Requirements Hierarchy Diagram
365


The system shall be capable of scanning the runways, taxiways, aircraft ramps
and adjoining grass areas for FOD.
hier FOD Location Reporting

R.4.1
FOD Location
Reporting
Requirement
R.4.1.1
refined by
R.4.1.2
refined by
R.4.1.3
refined by
verified by
Active Reporting
Passive Reporting
Suitability
Reporting
Test
Requirement
Requirement
Requirement
VerificationRequ...
verified by
verified by
verified by
Demonstration
Demonstration
Demonstration
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
Figure 14. FOD Location Reporting Requirements Hierarchy Diagram

The system shall provide a method of transmitting FOD location data to the
retrieval subsystem.
R.4 FOD Reporting
366


The system shall be capable of determining when objects are too heavy for
retrieval.
R.5 FOD Retrieval
hier Mobile Unit Navigation

R.6.2
Mobile Unit
Navigation
Requirement
R.6.2.1
refined by
R.6.2.2
refined by
R.6.2.3
refined by
verified by
FOD Location
Emergency
Posture
Standby Location
Demonstration
Requirement
Requirement
Requirement
VerificationRequ...
verified by
verified by
verified by
Demonstration
Demonstration
Demonstration
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
Figure 15. Mobile Unit Navigation Requirements Hierarchy Diagram

Mobile system elements shall be capable of navigating the airfield autonomously.
367


Mobile system elements shall be capable of navigating to FOD locations.
Mobile system elements shall be capable of navigating to predefined emergency
locations defined by airport managers.
Mobile system elements shall be capable of navigating to standby locations that
will be determined by concept selection.
368

R.7.1 Types of Data
hier Types of Data

R.7.1
Types of Data
Requirement
R.7.1.1
refined by
verified by
Storage of Data
Test
Requirement
VerificationRequ...
refined by
R.7.1.1.1
verified by
Data Retention
Test
Requirement
VerificationRequ...
Date:
November 7, 2015
Figure 16. Types of Data Requirements Hierarchy Diagram

The system shall be capable of receiving and storing FOD alert time and date,
location coordinates and FOD image data.
369

hier Storage of Data

R.7.1.1
Storage of Data
Requirement
refined by
R.7.1.1.1
verified by
Data Retention
Test
Requirement
VerificationRequ...
verified by
Demonstration
VerificationRequ...
Date:
November 7, 2...
Figure 17. Storage of Data Requirements Hierarchy Diagram

Data collected in the FOD detection process shall be recorded and stored.
R.7.1 Types of Data
370

hier System Maintainability

R.11.2
System
Maintainability
Requirement
R.11.2.1
refined by
R.11.2.1.1
refined by
R.11.2.2
refined by
verified by
System Health
Equipment
Located Outside...
Analysis
Requirement
Requirement
VerificationRequ...
refined by
R.11.2.1.2
verified by
verified by
System Health
Self Test & Fault

Notification
Test
Demonstration
Requirement
Requirement
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
Figure 18. System Maintainability Requirements Hierarchy Diagram

The system should be designed to ease maintenance functions.
371

hier System Health

R.11.2.1.1
System Health
Requirement
refined by
R.11.2.1.1.1
refined by
R.11.2.1.1.2
verified by
Mobile Element
System Health
Stationary
Element System...
Demonstration
Requirement
Requirement
VerificationRequ...
verified by
verified by
Demonstration
Demonstration
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
Figure 19. System Health Requirements Hierarchy Diagram

The system shall be capable of continuously monitoring system health of critical
subsystems.
372

hier Self Test & Fault Notification

R.11.2.1.2
Self Test & Fault
Notification
Requirement
refined by
R.11.2.1.2.1
refined by
R.11.2.1.2.2
verified by
Mobile Element
Self-Test
Stationary
Element Self-Test
Demonstration
Requirement
Requirement
VerificationRequ...
refined by
R.11.2.1.2.1.1
verified by
refined by
R.11.2.1.2.2.1
verified by
Mobile Element
Self-Test Duration
Demonstration
Stationary
Element Self-Tes...
Demonstration
Requirement
VerificationRequ...
Requirement
VerificationRequ...
Date:
November 7, 2015
Figure 20. Self-Test & Fault Notification Requirements Hierarchy Diagram

The system shall be capable self-testing non-critical subsystems.
373

hier Mobile Element Self-Test

R.11.2.1.2.1
Mobile Element
Self-Test
Requirement
refined by
R.11.2.1.2.1.1
verified by
Mobile Element
Self-Test Duration
Demonstration
Requirement
VerificationRequ...
verified by
Test
VerificationRequ...
Date:
November 7, 2...
Figure 21. Mobile Element Self-Test Requirements Hierarchy Diagram

Mobile elements shall perform a self-test upon initialization and upon request from
maintenance personnel.
374

hier Stationary Element Self-Test

R.11.2.1.2.2
Stationary
Element Self-Test
Requirement
refined by
R.11.2.1.2.2.1
verified by
Stationary
Element Self-Tes...
Demonstration
Requirement
VerificationRequ...
verified by
verified by
Analysis
Demonstration
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
Figure 22. Stationary Element Self-Test Requirements Hierarchy Diagram

Stationary system elements shall perform a self-test of non-critical subsystems
when requested by the user.
375

PERFORMANCE REQUIREMENTS

R.1.1 Emergency
R.2.4 Power Failure
The system shall be capable of detecting FOD within 4 minutes of a FOD
occurrence.
376

R.3.2 FOD Detection

hier FOD Detection
R.3.2
FOD Detection
Requirement
basis of
R.3.2.1
refined by
R.3.2.2
refined by
R.3.2.3
refined by
R.3.2.4
refined by
R.3.2.5
refined by
verified by
Detect FOD
Group Object
Detection
Metal Cylinder
Detection
Sphere Detection
Lighting
Conditions
Automated
Test
Function
Requirement
Requirement
Requirement
Requirement
Requirement
VerificationRequ...
verified by
verified by
verified by
verified by
verified by
Test
Test
Test
Test
Test
VerificationRequ...
VerificationRequ...
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
Figure 23. FOD Detection Requirements Hierarchy Diagram

The system shall be capable of detecting and reporting the location of single and
multiple FOD items on the AOA to the retrieval subsystem as well as airport
personal when FOD (such as animal carcasses) are unsuitable for retrieval.
377


The system shall have the ability to detect 90 percent of the following group of
objects when placed within a 100 ft. by 100 ft. (30 m by 30 m) square in the
desired coverage area. One item from each category must be included in the
group and each item must measure no larger than 4 in (10 cm) in any dimension
unless otherwise specified: A chunk of asphalt or concrete, Any portion of a
runway light fixture (in-pavement or edge light), An adjustable crescent wrench
up to 8 in. (20 cm) in length), A deep socket (at least 2 in. (5 cm) in length), A
piece of rubber from an aircraft tire, A distorted metal strip (up to 8 in. (20 cm) in
length), Fuel cap (aircraft or automotive), Lug nut, Hydraulic line (from aircraft or
GSE, up to 8 in. (20 cm) in length).
R.3.2 FOD Detection
The system shall have the ability to detect an unpainted, metal cylinder,
measuring 1.2 in (3.1 cm) high and 1.5 in (3.8 cm) in diameter.
R.3.2 FOD Detection
378


The system shall have the ability to detect a white, grey, or black sphere,
R.3.2 FOD Detection
The system shall demonstrate detection performance during daylight, nighttime,
R.3.2 FOD Detection
Location reporting methods that utilize an active method of reporting location
(such as a light beam) shall not interfere with or cause a distraction to normal
airport operations.
379


Location reporting methods that utilize a passive method of reporting, such as GPS
coordinates shall be accurate to within 16 ft. (5.0 m) of the actual FOD object
location.
Performance requirement derived from FAA AC 150/5220-24 Airport Foreign
The system shall be capable of notifying airport personnel of FOD unsuitable for
automated retrieval (such as animal carcasses) with GPS coordinates accurate to
within 16 ft. (5.0 m) of the actual FOD location.
R.5.2 FOD Weight
The system shall be capable of retrieving FOD weighing up to 1 pound or
.45359237 kilograms
R.5 FOD Retrieval
380

R.5 FOD Retrieval
Mobile system elements shall maintain a minimum of ten feet (3.05 meters)
separation from all obstacles.
separation from all aircraft.
381

separation from all personnel.
Mobile system elements shall maintain a minimum 25 feet (7.6 meter) separation
from all support vehicles.
The system shall be capable of receiving and transmitting data to air traffic control
without causing any interference to existing systems.
The system shall be capable of receiving and transmitting data to airport
managers without causing any interference to existing systems.
382

The system shall be capable of receiving and transmitting data to maintenance
personnel without causing any interference to existing systems.
The system should have an Operational Availability (AO) of 99.9%
hier System Health and Fault Notification
R.11.2.1
System Health
Requirement
refined by
R.11.2.1.1
refined by
R.11.2.1.1.1
refined by
R.11.2.1.2
verified by
System Health
Self Test & Fault

Notification
Test
Requirement
Requirement
VerificationRequ...
refined by
R.11.2.1.1.2
verified by
refined by
R.11.2.1.2.1
refined by
R.11.2.1.2.2
verified by
Mobile Element
System Health
Stationary
Element System...
Demonstration
Mobile Element
Self-Test
Stationary
Element Self-Test
Demonstration
Requirement
Requirement
VerificationRequ...
Requirement
Requirement
VerificationRequ...
Date:
November 7, 2015
Figure 24. System Health and Fault Notification Requirements Hierarchy Diagram

The system shall be capable of automatically detecting faults in critical
subsystems and providing users with data regarding faults in non-critical
subsystems.
383


384


Mobile subsystems shall be capable of continuously monitoring the health of
critical subsystems and compensating for faults in critical subsystems until they
can exit the airport operating area.
Stationary elements shall employ a method of monitoring system health of critical
subsystems and employ a method of notifying users when faults are detected.
The self-test duration on mobile system elements should not exceed 30 seconds.
When stationary elements are asked to perform a self-test, the self-test shall not
interfere with the systems ability to operate safely; if the self-test takes a FOD
detection element off line it shall be capable of recovering in no longer than 60
seconds.
385


The system shall be capable of detecting objects under rainfall conditions having
a specific intensity, duration, and frequency for a two-year category of storm in
the local region (as specified in CLIM 20, Climatology of the United States No. 20).
The system shall be capable of detecting objects under snow conditions having a
specific intensity, duration, and frequency for a two-year category of storm in the
local region (as specified in CLIM 20, Climatology of the United States No. 20).
The system shall be capable of operating in wind conditions up to 50 MPH with
gusts up to 70MPH.
386
PROGRAMMATIC REQUIREMENTS
R.9.1.1 Maintenance Procedures
hier Maintenance Procedures

R.9.1
Maintenance
Procedures
Requirement
R.9.1.1
refined by
R.9.1.2
refined by
R.9.1.3
refined by
R.9.1.4
refined by
verified by
Cleaning
Procedures
Preventative
Maintenance Pr...
Recalibration Plan
Scheduled
Component Re...
Analysis
Requirement
Requirement
Requirement
Requirement
VerificationRequ...
verified by
verified by
verified by
verified by
Analysis
Analysis
Analysis
Analysis
VerificationRequ...
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
Figure 25. Maintenance Procedures Requirements Hierarchy Diagram

An operators handbook, illustrated parts breakdown and preventive
maintenance schedule shall be developed and included with the system.
387

Written documentation on recommended cleaning procedures, including solvent
types and tools shall be developed.
Written documentation on recommended preventive maintenance actions shall
be developed.
Written calibration and recalibration procedures shall be developed so that FOD
detection and retrieval programmatic specifications can be maintained for the life
of system.
Written documentation on scheduled component removal timelines shall be
developed.
388
R.9.2 Call Center

Equipment located outside of paved surfaces shall be designed and built so
maintenance personnel can have access.
389

DESIGN CONSTRAINTS

Mobile system elements shall be capable of operating on the AOA at a speed of
no less than 20 mph (30 km/h).
Data systems shall have the capability to retain the data for at least two years
after the detection event.
390

DESIGN CONSTRAINTS
hier Elements Located Near The Runway

R.10.1
Elements Located
Near The Runway
Requirement
R.10.1.1
refined by
R.10.1.2
refined by
R.10.1.3
refined by
R.10.1.4
refined by
verified by
Breakaway
Connector
Element Height
Frangible Coupling
Wind Loading
Inspection
Requirement
Requirement
Requirement
Requirement
VerificationRequ...
verified by
verified by
verified by
verified by
Inspection
Inspection
Inspection
Inspection
VerificationRequ...
VerificationRequ...
VerificationRequ...
VerificationRequ...
Date:
November 7, 2015
Figure 26. Elements Located Near the Runway Requirements Hierarchy Diagram

Sensors located near the runway shall comply with applicable FAA regulations.
391

DESIGN CONSTRAINTS

connected through a connector that will disconnect upon sensor impact.
The height of the sensors located near the runway and within the runway safety
area shall be no more than 30 in (0.76 m).
AC 150/5340-30, Design and Installation Details for Airport Visual Aids
mounted on a frangible coupling.
392

DESIGN CONSTRAINTS

Elements located near the runway shall withstand a wind loading of 300 mph. (483
km/h)
393
Section VIII.
Requirements Traceability & Verification Matrix
394
Section VIII. Requirements Traceability & Verification Matrix
Number
R
Name
Need Statement
Type
Composite
Origin
Originating
Refines
Refined by
Requirement R.1
Safe Operation
Requirement R.2
System Command
and Control
Requirement R.3
FOD Scanning and
Detection
Requirement R.4
FOD Reporting
Requirement R.5
FOD Retrieval
Requirement R.6
Mobile Unit
Locomotion
Requirement R.7
Provide FOD Trend
Analysis
Requirement R.8
System
Communication
Requirement R.9
Technical Support
Requirement R.10
Installation and
Acceptance
Standards
Requirement R.11
Reliability,
Availability and
Maintainability
Requirement R.12
Verified by
Analysis
Demonstration
Inspection
Test
395
Number
Name
Type
Origin
R.1
Safe Operation
Composite
Originating
R.1.1
Emergency
Functional
Derived
R.1.1.1
Execution
Speed
System
Command and
Control
Performance
Derived
Composite
Originating
R.2.1
System
Command
Functional
Design
Decision
R.2.2
Location of
Aircraft
Functional
Derived
R.2.3
Unsuitable FOD
Functional
Derived
R.2.4
Power Failure
Performance
Derived
R.2
Refines
Requirement R
Need Statement
Requirement
R.1 Safe
Operation
Requirement
R.1.1 Emergency
Requirement R
Need Statement
Requirement
R.2 System
Command and
Control
Requirement
R.2 System
Command and
Control
Requirement
R.2 System
Command and
Control
Requirement
R.2 System
Refined by
Operate in Adverse
Weather Conditions
Requirement R.1.1
Emergency
Requirement R.1.1.1
Execution Speed
Verified by
Demonstration
Test
Demonstration
Requirement R.2.1
System Command
Requirement R.2.2
Location of Aircraft
Requirement R.2.3
Unsuitable FOD
Requirement R.2.4
Power Failure
Test
Test
Test
Test
Test
396
Number
Name
Type
Composite
Origin
R.3
FOD Scanning
and Detection
Originating
R.3.1
Airfield Scanning Functional
Derived
R.3.1.1
Detection Time
Performance
Derived
R.3.2
FOD Detection
Performance
Derived
R.3.2.1
Group Object
Detection
Performance
Derived
R.3.2.2
Metal Cylinder
Detection
Performance
Derived
Refines
Command and
Control
Requirement R
Need Statement
Requirement
R.3 FOD
Scanning and
Detection
Requirement
R.3.1 Airfield
Scanning
Requirement
R.3 FOD
Scanning and
Detection
Requirement
R.3.2 FOD
Detection
Requirement
R.3.2 FOD
Detection
Refined by
Verified by
Requirement R.3.1
Airfield Scanning
Requirement R.3.2
FOD Detection
Requirement R.3.1.1
Detection Time
Demonstration
Demonstration
Demonstration
Requirement R.3.2.1
Group Object
Detection
Requirement R.3.2.2
Metal Cylinder
Detection
Requirement R.3.2.3
Sphere Detection
Requirement R.3.2.4
Lighting Conditions
Requirement R.3.2.5
Automated
Retrieval Suitability
Test
Test
Test
397
Number
Name
Type
Origin
Refines
R.3.2.3
Sphere
Detection
Performance
Derived
R.3.2.4
Lighting
Conditions
Performance
Derived
R.3.2.5
Automated
Retrieval
Suitability
FOD Reporting
Functional
Derived
Composite
Originating
R.4.1
FOD Location
Reporting
Functional
Derived
Requirement
R.4 FOD
Reporting
R.4.1.1
Active
Reporting
Performance
Derived
R.4.1.2
Passive
Reporting
Performance
Derived
R.4.1.3
Suitability
Reporting
Performance
Derived
R.5
FOD Retrieval
Composite
Originating
Requirement
R.4.1 FOD
Location
Reporting
Requirement
R.4.1 FOD
Location
Reporting
Requirement
R.4.1 FOD
Location
Reporting
Requirement R
Need Statement
R.4
Requirement
R.3.2 FOD
Detection
Requirement
R.3.2 FOD
Detection
Requirement
R.3.2 FOD
Detection
Requirement R
Need Statement
Refined by
Verified by
Test
Test
Test
Requirement R.4.1
FOD Location
Reporting
Requirement R.4.1.1
Active Reporting
Requirement R.4.1.2
Passive Reporting
Requirement R.4.1.3
Suitability Reporting
Demonstration
Test
Demonstration
Demonstration
Demonstration
Requirement R.5.1
FOD Weight
Demonstration
398
Number
Name
Type
Origin
R.5.1
FOD Weight
Determination
Functional
Design
Decision
R.5.2
FOD Weight
Performance
Derived
R.5.3
FOD location
Functional
Derived
R.5.4
FOD Dimensions
Performance
Derived
R.6
Mobile Unit
Locomotion
Composite
Originating
Refines
Requirement
R.5 FOD
Retrieval
Requirement
R.5 FOD
Retrieval
Requirement
R.5 FOD
Retrieval
Requirement
R.5 FOD
Retrieval
Requirement R
Need Statement
Refined by
Determination
Requirement R.5.2
FOD Weight
Requirement R.5.3
FOD location
Requirement R.5.4
FOD Dimensions
Verified by
Test
Test
Test
Test
Requirement R.6.1
Mobile Unit Speed
Requirement R.6.2
Mobile Unit
Navigation
Requirement R.6.3
Mobile Unit
Movement
Clearance
Requirement R.6.4
Separation from
Obstacles
Requirement R.6.5
Separation from
Test
399
Number
Name
Type
Origin
R.6.1
Mobile Unit
Speed
Constraint
Derived
R.6.2
Mobile Unit
Navigation
Functional
Derived
R.6.2.1
FOD Location
Functional
Derived
R.6.2.2
Emergency
Posture
Functional
Derived
R.6.2.3
Standby
Location
Functional
Derived
R.6.3
Mobile Unit
Movement
Clearance
Separation from
Obstacles
Functional
Design
Decision
Performance
Derived
R.6.4
Refines
Requirement
R.6 Mobile Unit
Locomotion
Requirement
R.6 Mobile Unit
Locomotion
Requirement
R.6.2 Mobile Unit
Navigation
Requirement
R.6.2 Mobile Unit
Navigation
Requirement
R.6.2 Mobile Unit
Navigation
Requirement
R.6 Mobile Unit
Locomotion
Requirement
R.6 Mobile Unit
Locomotion
Refined by
Aircraft
Requirement R.6.6
Separation from
Personnel
Requirement R.6.7
Separation from
Vehicles
Requirement R.6.2.1
FOD Location
Requirement R.6.2.2
Emergency Posture
Requirement R.6.2.3
Standby Location
Verified by
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Demonstration
Test
400
Number
Name
Type
Origin
R.6.5
Separation from
Aircraft
Performance
Derived
R.6.6
Separation from
Personnel
Performance
Derived
R.6.7
Separation from
Vehicles
Performance
Derived
R.7
Composite
Originating
R.7.1
Provide FOD
Trend Analysis
Types of Data
Functional
Derived
R.7.1.1
Storage of Data
Functional
Derived
R.7.1.1.1
Data Retention
Constraint
Derived
R.8
System
Communication
Composite
Originating
Refines
Requirement
R.6 Mobile Unit
Locomotion
Requirement
R.6 Mobile Unit
Locomotion
Requirement
R.6 Mobile Unit
Locomotion
Requirement R
Need Statement
Requirement
R.7 Provide FOD
Trend Analysis
Requirement
R.7.1 Types of
Data
Requirement
R.7.1.1 Storage
of Data
Requirement R
Need Statement
Refined by
Verified by
Test
Test
Test
Requirement R.7.1
Types of Data
Requirement R.7.1.1
Storage of Data
Demonstration
Requirement
R.7.1.1.1 Data
Retention
Test
Requirement R.8.1
ATC
Communication
Requirement R.8.2
Airport
Management
Communication
Requirement R.8.3
Maintainer
Communication
Demonstration
Test
Demonstration
401
Number
Name
Type
Origin
Refines
R.8.1
ATC
Communication
Performance
Derived
R.8.2
Airport
Management
Communication
Maintainer
Communication
Performance
Derived
Performance
Derived
R.9
Technical
Support
Composite
Originating
R.9.1
Maintenance
Procedures
Programmatic Derived
Requirement
R.9 Technical
Support
R.9.1.1
Cleaning
Procedures
Requirement
R.9.1
Maintenance
Procedures
R.8.3
Requirement
R.8 System
Communication
Requirement
R.8 System
Communication
Requirement
R.8 System
Communication
Requirement R
Need Statement
Refined by
Verified by
Demonstration
Demonstration
Demonstration
Requirement R.9.1
Maintenance
Procedures
Requirement R.9.2
Call Center
Requirement R.9.1.1
Cleaning
Procedures
Requirement R.9.1.2
Preventative
Maintenance
Procedures
Requirement R.9.1.3
Recalibration Plan
Requirement R.9.1.4
Scheduled
Component
Removals
Analysis
Analysis
Analysis
402
Number
Name
Type
Origin
Refines
R.9.1.2
Preventative
Maintenance
Procedures
R.9.1.3
Recalibration
Plan
R.9.1.4
Scheduled
Component
Removals
R.9.2
Call Center
R.10
Installation and
Acceptance
Standards
Elements
Located Near
The Runway
Composite
Originating
Constraint
Derived
Requirement
R.10 Installation
and
Acceptance
Standards
Breakaway
Connector
Constraint
Derived
Requirement
R.10.1 Elements
Located Near
The Runway
R.10.1
R.10.1.1
Requirement
R.9.1
Maintenance
Procedures
Requirement
R.9.1
Maintenance
Procedures
Requirement
R.9.1
Maintenance
Procedures
Requirement
R.9 Technical
Support
Requirement R
Need Statement
Refined by
Verified by
Analysis
Analysis
Analysis
Demonstration
Requirement R.10.1
Elements Located
Near The Runway
Requirement
R.10.1.1 Breakaway
Connector
Requirement
R.10.1.2 Element
Height Requirement
R.10.1.3 Frangible
Coupling
Requirement
R.10.1.4 Wind
Loading
Inspection
Inspection
Inspection
403
Number
Name
Type
Origin
R.10.1.2
Element Height
Constraint
Derived
R.10.1.3
Frangible
Coupling
Constraint
Derived
R.10.1.4
Wind Loading
Constraint
Derived
R.11
Reliability,
Availability and
Maintainability
Composite
Originating
R.11.1
System
Availability
Performance
Derived
R.11.2
System
Maintainability
Functional
Derived
R.11.2.1
System Health
and Fault
Notification
Performance
Derived
Refines
Requirement
R.10.1 Elements
Located Near
The Runway
Requirement
R.10.1 Elements
Located Near
The Runway
Requirement
R.10.1 Elements
Located Near
The Runway
Requirement R
Need Statement
Requirement
R.11 Reliability,
Availability and
Maintainability
Requirement
R.11 Reliability,
Availability and
Maintainability
Requirement
R.11.2 System
Maintainability
Refined by
Verified by
Inspection
Inspection
Inspection
Requirement R.11.1
System Availability
Requirement R.11.2
System
Maintainability
Analysis
Requirement
R.11.2.1 System
Health and Fault
Notification
Requirement
R.11.2.2 Equipment
Located Outside of
Paved Surfaces
Requirement
R.11.2.1.1 System
Health Requirement
Analysis
Analysis
Test
404
Number
Name
Type
Origin
Refines
R.11.2.1.1
System Health
Functional
Derived
Requirement
R.11.2.1 System
Health and Fault
Notification
R.11.2.1.1.1
Mobile Element
System Health
Performance
Derived
R.11.2.1.1.2
Stationary
Element System
Health
Self-Test & Fault
Notification
Performance
Derived
Functional
Derived
Requirement
R.11.2.1.1 System
Health
Requirement
R.11.2.1.1 System
Health
Requirement
R.11.2.1 System
Health and Fault
Notification
Mobile Element
Self-Test
Functional
Derived
R.11.2.1.2.1.1 Mobile Element

Self-Test
Duration
Performance
Derived
R.11.2.1.2.2
Functional
Derived
R.11.2.1.2
R.11.2.1.2.1
Stationary
Element Self-Test
Requirement
R.11.2.1.2 SelfTest & Fault
Notification
Requirement
R.11.2.1.2.1
Mobile Element
Self-Test
Requirement
R.11.2.1.2 Self-
Refined by
R.11.2.1.2 Self-Test &
Fault Notification
Requirement
R.11.2.1.1.1 Mobile
Element System
Health Requirement
R.11.2.1.1.2
Stationary Element
System Health
Verified by
Demonstration
Demonstration
Demonstration
Requirement
R.11.2.1.2.1 Mobile
Element Self-Test
Requirement
R.11.2.1.2.2
Stationary Element
Self-Test
Requirement
R.11.2.1.2.1.1 Mobile
Element Self-Test
Duration
Demonstration
Requirement
R.11.2.1.2.2.1
Stationary Element
Demonstration
Demonstration
Test
405
Number
Name
Type
Origin
Refined by
Test & Fault

Notification
Requirement
R.11.2.1.2.2
Stationary
Element Self-Test
Requirement
R.11.2 System
Maintainability
Self-Test
Performance
Requirement R.12.1
Performance in Rain
Requirement R.12.2
Performance in
Snow Requirement
R.12.3 Performance
in Wind
R.11.2.1.2.2.1 Stationary
Element Self-Test
Performance
Performance
R.11.2.2
Equipment
Located
Outside of
Paved Surfaces
Operate in
Adverse
Weather
Conditions
Composite
Originating
Requirement R
Need Statement
R.12.1
Performance in
Rain
Performance
Derived
R.12.2
Performance in
Snow
Performance
Derived
R.12.3
Performance in
Wind
Performance
Derived
Requirement
R.12 Operate in
Adverse
Weather
Conditions
Requirement
R.12 Operate in
Adverse
Weather
Conditions
Requirement
R.12 Operate in
Adverse
Weather
Conditions
R.12
Derived
Refines
Verified by
Analysis
Demonstration
Demonstration
Test
Test
Test
Test
406
407
References
FAA. (2009, September 30). Advisory Circular150/5220-24 Airport Foreign Object Debris
(FOD) Detection Equipment. Retrieved
from: http://www.faa.gov/documentLibrary/media/Advisory_Circular/150_5220_
24.pdf
FAA. (2010, September 30). Advisory Circular 150/5210-24 Airport Foreign Object Debris.
Retrieved
from: http://www.faa.gov/documentLibrary/media/Advisory_Circular/150_5210_
24.pdf
Kossiakoff, A., Sweet, W. N., Seymour, S. J., & Biemer, S. M. (2011). Sysytems Engineering
Principles and Practice (2nd edition). Hoboken: John Wiley & Sons.
408
Appendix C
AFDIRTS Functional Analysis Report
409
Table of Contents
Systems Engineering 411
Updated Context Diagram 412
AFDIRTS Function Tree.. 413
Functional Tractability Matrix 414
AFDIRTS Requirement/Functional Map. 418
AFDIRTS Functional Architecture. 419
410
Systems Engineering
The Systems Engineering Method as described by Kossiakoff et al. (2011) is being utilized
to assist in completion of the SM4 project. At this point, user needs have been identified,
operational objectives have been defined, and operational and performance
requirements have been developed that would satisfy operational objectives. These
requirements were documented in the Requirements Analysis Report (RAR).
The Functional Analysis Report (FAR) documents the results of both the Performance
Requirements Analysis and Functional Analysis and Formulation steps of Concept
Definition phase. At this point, performance requirements have been analyzed and
refined while functions have been allocated to the component level. Even though
some functions have been allocated to the component level, the preliminary
functional architecture listed in this report has been designed to facilitate a wide-range
of physical solutions. In the RAR (Concept Exploration), three competing CONOPS were
explored, as system development continues and a concept is selected; both the
functional architecture and requirements document will be refined to reflect the
progress made through Concept Definition. These requirements will ultimately be
documented in the A-Spec.
411
AFDIRTS Updated Context Diagram
Air Traffic
Control
Environment
Rain (M)
Wind (F)
Snow (M)
Location Data (D)
Heat (E)
Sound (E)
Resistance (E)
System Health (D)

System Status (D)
Reports (D)
Obstacles

Airport
Managers
ATC Command (D)

Aircraft Radar Data
(D)
AFDIRTS
Aircraft
Operators

Forces (F)
Energy (E)
Data (D)
Signals (S)
FOD Location (E)

Materials (M)
Parts (M)
Materials (M)
Fault Codes (D)
System Health (D)
Power
Parts (M)
Materials (M)
SW Update (S)
FOD
Maintainer
Figure 1. Updated AFDIRTS Context Diagram
412
AFDIRTS Function Tree
Figure 2. AFDIRTS Functional Tree
413
AFDIRTS Functional Traceability Matrix

Table 1. AFDIRTS Functional Traceability Matrix
Number Name
Based on
R Need Statement
F.1.1
Perform AFDIRTS
Functions
Command and Control
System
Interface with ATC
F.1.2
F.1.3
F.1.9
Transmit Normal
Operation Command
Transmit Emergency
Command
Determine Location,
Trajectory and Speed
of Inbound Aircraft.
Transmit Inbound
Aircraft Data to System
Elements
Managers
Interface with
Initiate Self-Test
Display Maintenance
Data
Restore System
F.2
Operate Safely
R.1 Safe Operation
F.2.1
Perform Self-Test Upon

Initialization
F.2.2

Stationary Element
Critical Subsystems
Mobile Element Critical
Subsystems
Compensate for
Critical Subsystems
R.1.2 System Health Requirement

R.13.2.1 Self-Test
R.1.2 System Health
F.1
F.1.4
F.1.5
F.1.6
F.1.7
F.1.8
F.1.8.1
F.1.8.2
F.2.3
F.2.4


Airport Management Communication
Maintainer Communication
R.9.2
R.9.3
R.2.3 Power Failure
R.1.2 System Health

414

Number Name
Based on
F.2.5
R.1.2 System Health
F.3
Provide Airport
Health Data
Provide ATC with
System Health Data
Provide Maintenance
Health Data
F.3.1
Detect FOD
F.3.2
Determine FOD
Suitability from a
Distance
FOD
Process Suitability and
Location of FOD
Retrieve FOD

R.3.2
FOD Detection
R.3.2.1
Group Object Detection
R.3.2.2
Metal Cylinder Detection R.3.2.3 Sphere
Detection R.3.2.4 Lighting Conditions
R.3.2.5 Automated Retrieval Suitability R.4.1.3
Suitability Reporting R.5.3 FOD location
F.2.6
F.2.7
F.3.3
F.3.4
F.4
F.4.1
F.4.2
F.4.3
F.4.4
F.4.5
Determine FOD
Dimensions
Notify Personnel of
Object too Large for
Retrieval
Grasp FOD
R.1.2 System Health

R.1.2 System Health
R.3 FOD Search

R.4 FOD Reporting Requirement R.4.1 FOD
Location Reporting
R.5.2
FOD Weight
R.5.3 FOD location
R.5.5 FOD Grasping
R.5 FOD Retrieval Requirement R.5.3 FOD
location
R.5 FOD Retrieval
F.4.7
Determine FOD weight

Notify Personnel of
Overweight Objects
Transport FOD to
Disposal Area
Release FOD
F.5
Navigate Airfield
F.5.1
Process Navigation
Commands
F.4.6
R.5.5 FOD Grasping
415

Number Name
Based on
F.5.2
R.1.1 Emergency
R.1.1.1 Execution
Speed
F.5.3
F.5.4
F.5.5
F.5.6
F.5.7
F.5.8
Navigate to
Emergency Standby
Location
Navigate to FOD
Location
Navigate to Disposal
Area
Detect Obstacles
Receive Aircraft
Trajectory Data
Anticipate Obstacle
Movement
Avoid Obstacles
R.7.3 FOD Location

R.7.5 Disposal Area
F.5.9
Determine Location

R.7.1.2 Separation from Aircraft R.7.1.3
Separation from Personnel
Separation from Vehicles
F.5.10
Control Motion
F.6
F.6.2.2
F.6.2.3
F.7
F.7.1
F.7.2
F.7.3
F.7.4
F.7.5
F.8
Locomote System
Elements
Facilitate Power
Facilitate Movement
Control
Facilitate Motion
Facilitate Braking
Maintain System
Accept Parts
Accept Materials
Accept SW Updates
Eject Materials
Eject Parts
Provide Power
F.8.1
Accept External Power
R.12 System Power
F.8.2
Detect External Power

Failure
F.6.1
F.6.2
F.6.2.1
R.7.1.4

R.12 System Power
416

Number Name
Based on
F.8.3
Generate Emergency
Power
Transfer Power
Analyze FOD Trends

Accept FOD alert time
and date, location
coordinates and FOD
image data
Retain Data
Export FOD Reports

R.8.1 Types of Data
F.8.4
F.9
F.9.1
F.9.2
F.9.3
F.9.4
R.12 System Power

R.8.1.1 Storage of Data R.8.1.1.1 Data Retention
417
AFDIRTS Requirement/Functional Map

Table 2. AFDIRTS Requirement/Function Map
418
F. AFDIRTS System
n2 Perform AFDIRTS Functions
(Ext) Aircraft
Radar Data ...
(Ext) ATC ...
(Ext) Maint...
(Ext) FOD
Identification
from FOD
(Ext) FOD L...
(Ext) FOD
Identificatio...
(Ext) FOD L...
At FOD Loca...
(Ext) Aircraf...
(Ext) Obsta...
(Ext) Obsta...
Location Da...
(Ext)
Materials fr...
(Ext) Parts ...
(Ext) SW U...
(Ext)
Electrical
Energy from
Power
At FOD
Location
Signal (S)
F.1
System Context
System
Health (D)
Emergency...
Fault Codes...
System Hea...
System Hea...
Inbound
Aircraft Data
from Comm...
Navigation ...
Command and
Control System
F.2
Operate Safely
System Context
Unsuitable
FOD Location
Data
F.3
Scan Airfield for
FOD
System Context
FOD Location
Data to
Mobile Units
FOD
Characteristic
s (D)
Suitablity D...
FOD Charac...
Fod Illumina...
Suitablity D...
Unsuitable ...
Navigation
Modes (D)
FOD too
Large (S)
FOD too
Large (S)
Unsuitable
FOD Locatio...
FOD
Coordinates
Aircraft
Illumination ...
FOD Coordi...
Obstacle Ill...
F.4
Unsuitable
FOD (D)
Unsuitable
FOD Locatio...
Retrieve FOD
System Context
F.5
Navigate Airfield
System Context
Movement
Command to
Locomote
System Ele...
F.6
Heat to
Environment
Resistance t...
Sound to En...
Locomote System
Elements
System Context
F.7
Materials to
Maintainer
Parts to
Maintainer
Maintain System
System Context
Power Failure
Signal from
Power (S)
transferred...
transferred
Power (E)
transferred
Power (E)
transferred
Power (E)
transferred
Power (E)
transferred
Power (E)
transferred
Power (E)
F.8
transferred
Power (E)
Provide Power
System Context
F.9
Analyze FOD
Trends
Reports to
Airport
Managers (E)
System Context
Date:
November 18, 2015
Figure 3. F. AFDIRTS N2 Diagram
419

Based On:
n2 Command and Control System
(Ext) ATC
Command
from ATC
System Hea...
Emergency
Operation
Command (S)
System
Health (D)
Unsuitable
FOD Locatio...
(Ext) Aircraft
Radar Data
from ATC
(Ext)
Maintenance
Commands ...
System Hea...
Power Failure
Signal from
Power (S)
F.1.1
Interface with
ATC
System Context
System
Health to
ATC (E)
Command
Signal (S)
F.1.2
Initiate System
Modes
System Context
Normal
Operation
Command (S)
Emergency
Operation
Command (S)
F.1.3
Transmit Normal
Operation
Command
System Context
Navigation
Modes (D)
F.1.4
Transmit
Emergency
Command
System Context
Navigation
Modes (D)
F.1.5
Determine
Location,
Trajectory and
Speed of Inbou...
System Context
Aircraft
Location (D)
F.1.6
Inbound
Aircraft Data
from
Command a...
Transmit Inbound
Aircraft Data to
System Elements
System Context
F.1.7
System
Health to
Airport Man...
Unsuitable ...
Interface with
Airport Managers
System Context
F.1.8
System
Health Data
to Maintainer
(E)
Interface with
Maintenance
Personnel
System Context
System
Resume
Signal (S)
System
Resume
Signal (S)
System
Resume
Signal (S)
System
Resume
Signal (S)
System
Resume
Signal (S)
F.1.9
Restore System
System Context
Date:
November 17, 2015
Figure 4. F.1 Command and Control (N2 Diagram)
420
effbd Command and Control System

F.1.3
Normal Operation
Command (S)
Transmit Normal
Operation Command
(Ext) ATC
Command from
ATC
F.1.1
Command
Signal (S)
Interface with ATC
F.1.2
System Context
OR
OR
F.1.4
(Ext) Aircraft
Radar Data from
ATC
Transmit Emergency Command

Emergency
Operation
Command (S)
Aircraft Location
(D)
F.1.5
System Health (D)
Inbound Aircraft Data from

Command and Control (D)
System Context
System Context
System Context
Unsuitable FOD Data to

Airport Managers
F.1.6
Determine Location,
Trajectory and Speed of
Inbound Aircraft.
Transmit Inbound Aircraft Data

to System Elements
System Context
System Context
System Health to Airport

Managers (E)
AND
AND
Unsuitable FOD
Location Data
F.1.7
System Health Data to
Maintainer (E)

Managers
(Ext) Maintenance
Commands from
Maintainer
System Context
F.1.8
Interface with
System Context
Ref.
OR
OR
Ref.
F.1.9
Restore System
System Context
Power Failure Signal
from Power (S)
System Resume
Signal (S)
Date:
November 17, 2015
Figure 5. F.1 Command and Control (Enhanced FFBD)
421

Based On:
Table 2. F.1.1 Interface with ATC Interfacing Items
Interfacing Items
(Ext) ATC Command from ATC
Input To:
Output From:
(External) ATC IOs
Command Signal (S)
Input To:
Output From:
System Health (D)
Input To:
Personnel
Output From:
F.2 Operate Safely
System Health Data
Data
Output From:
422

Based On:
Table 3. F.1.2 Initiate System Modes Interfacing Items
Interfacing Items
Command Signal (S)
Input To:
Output From:
Input To:
Output From:
Input To:
Command
Output From:
Input To:
System Elements
Personnel
Output From:
423
F.1.3 Transmit Normal Operation Command

Based On:
Table 4. F.1.3 Transmit Normal Operation Command Interfacing Items
Interfacing Items
Input To:
Output From:
Command
F.4 Retrieve FOD
Input To:
Command
Output From:
424

Based On:
Table 5. F.1.4 Transmit Emergency Command Interfacing Items
Interfacing Items
Input To:
Output From:
Input To:
Output From:
Command
F.4 Retrieve FOD
F.1.5 Determine Location, Trajectory and Speed of Inbound Aircraft.

Based On:
Table 6. F.1.5 Determine Location, Trajectory and Speed of Inbound Aircraft Interfacing Items
Interfacing Items
(Ext) Aircraft Radar Data from ATC
Input To:
Output From:
(External) Aircraft Operators IOs
Input To:
425
System Elements
Output From:
Input To:
System Elements
Personnel
Output From:
F.1.6 Transmit Inbound Aircraft Data to System Elements

Based On:
Interfacing Items
Input To:
System Elements
Output From:

and Control (D)
Input To:
Output From:
System Elements
Input To:
426
Interfacing Items
System Elements
Personnel
Output From:

Based On:
Interfacing Items
System Health (D)
Input To:
Personnel
Output From:
F.2 Operate Safely
System Health Data
Data
System Health to Airport Managers (E)
Output From:
Input To:
427
Interfacing Items
System Elements
Personnel
Output From:
Unsuitable FOD Data to Airport Managers
Output From:
Input To:
Output From:
FOD
F.4 Retrieve FOD
Large for Retrieval
Objects
F.1.8 Interface with Maintenance Personnel

Based On:
Interfacing Items
Maintainer
Input To:
428
Interfacing Items
Personnel
Output From:
System Health (D)
Input To:
Personnel
Output From:
F.2 Operate Safely
System Health Data
Data
Output From:
Personnel
Input To:
System Elements
Personnel
Output From:
429
effbd Interface with Maintenance Personnel

(Ext)
Maintenance
Commands
from Maintainer
F.1.8.1
F.1.8.2
Display Maintenance
Data
Initiate Self-Test
Ref.
System Health
Data to Maintainer
(E)
System
Health (D)
Ref.
System Context
System Context
Fault Codes (D)
Date:
November 17, 2015
Figure 6. F.1.8 Interface with Maintenance Personnel (Enhanced FFBD)
n2 Interface with Maintenance Personnel
(Ext)
Maintenance
Commands
from Mainta...
System
Health (D)
F.1.8.1
Initiate Self-Test
System Context
Fault Codes
(D)
F.1.8.2
Display
Maintenance Data
System Context
Fault Codes
to Maintainer
System
Health Data...
Date:
November 17, 2015
Figure 7. F.1.8 Interface with Maintenance Personnel (N2 Diagram)

Based On:
Interfacing Items
Maintainer
Input To:
430
Interfacing Items
Personnel
Output From:
Fault Codes (D)
Input To:
Output From:

Based On:
Interfacing Items
Fault Codes (D)
Input To:
Output From:
Output From:
System Health (D)
Input To:
Personnel
Output From:
F.2 Operate Safely
System Health Data
Data
431
Interfacing Items
Output From:
Personnel

Based On:
R.2.3 Power Failure
Table 12. F.1.9 Restore System Interfacing Items
Interfacing Items
Input To:
Output From:
F.8 Provide Power
Input To:
System Elements
Personnel
Output From:
432
F.2 Operate Safely

Based On:
R.1 Safe Operation
Table 13. F.2 Operate Safely Interfacing Items
Interfacing Items
System Health (D)
Input To:
Personnel
Output From:
F.2 Operate Safely
System Health Data
Data
Transferred Power (E)
Input To:
F.2 Operate Safely
F.4 Retrieve FOD
F.7 Maintain System
Output From:
F.8 Provide Power
433
effbd Operate Safely

Critical Subsystem
Telemetry Data from
Stationary Elements
F.2.5
Fault Data (D)
F.2.2
System
Initialization

Stationary Element
Critical Subsystems
F.2.1
Ref.
Perform Self Test

Upon Initialization
System Context
AND
System Health (D)
Provide Airport Managers

System Context
F.2.6
Critical
Subsystem
Degraded Signal
F.2.3
AND
Provide ATC with System

Health Data
OR
F.2.4
OR
Ref.
System Context
System Context
Mobile Element
Critical Subsystems
Compensate for
Critical Subsystems
System Context
System Context
F.2.7
Provide Maintenance
Health Data
System Context
Critical Subsystem
Telemetry Data From
Mobile Elements
Self-Test Results
(D)
Date:
November 17, 2015
Figure 8. F.2 Operate Safely (Enhanced FFBD)
434
n2 Operate Safely
System
Initialization
Critical
Subsystem
Telemetry
Data from S...
Critical
Subsystem
Telemetry
Data From ...
F.2.1
Perform Self Test
Upon Initialization
System Context
F.2.2
Monitor the
Health of
Stationary
Element Critical ...
System Context
F.2.3
Monitor the
Health of Mobile
Element Critical
Subsystems
System Context
Self-Test
Results (D)
Self-Test
Results (D)
Self-Test
Results (D)
Fault Data (D)
Fault Data (D)
Fault Data (D)
Fault Data (D)
Fault Data (D)
Fault Data (D)
Critical
Subsystem
Degraded
Signal
F.2.4
Compensate for
Failures in Mobile
Unit Critical
Subsystems
System Context
F.2.5
Provide Airport
Managers with
System Health
Data
System Context
System
Health (D)
F.2.6
Provide ATC with
System Health
Data
System Context
Date:
System
Health (D)
F.2.7
Provide
Maintenance
Personnel with
System Health ...
System Context
System
Health (D)
November 17, 2015
Figure 9. F.2 Operate Safely (N2 Diagram)
435

Based On:
R.1.2 System Health
R.13.2.1 Self-Test
Table 14. F.2.1 Perform Self-Test Upon Initialization Interfacing Items
Interfacing Items
Input To:
System Health Data
Data
Output From:
System Initialization
Input To:
F.2.2 Monitor the Health of Stationary Element Critical Subsystems

Based On:
R.1.2 System Health
Table 15. F.2.2 Monitor the Health of Stationary Element Critical Subsystems Interfacing Items
Interfacing Items
Critical Subsystem Telemetry Data from

Stationary Elements
Input To:
Fault Data (D)
Input To:
System Health Data
Data
Output From:
436
Table 15. F.2.2 Monitor the Health of Stationary Element Critical Subsystems Interfacing Items
Interfacing Items
F.2.3 Monitor the Health of Mobile Element Critical Subsystems

Based On:
R.1.2 System Health
Table 16. F.2.3 Monitor the Health of Mobile Element Critical Subsystems Interfacing Items
Interfacing Items
Input To:
Output From:
Critical Subsystem Telemetry Data From

Mobile Elements
Input To:
F.2.4 Compensate for Failures in Mobile Unit Critical Subsystems

Based On:
Table 17. F.2.4 Compensate for Failures in Mobile Unit Critical Subsystems Interfacing Items
Interfacing Items
Input To:
Output From:
Fault Data (D)
Input To:
System Health Data
437
Data
Output From:
F.2.5 Provide Airport Managers with System Health Data

Based On:
R.1.2 System Health
Interfacing Items
Fault Data (D)
Input To:
System Health Data
Data
Output From:
Input To:
System Health Data
Data
Output From:
System Health (D)
Input To:
438
Interfacing Items
Personnel
Output From:
F.2 Operate Safely
System Health Data
Data
F.2.6 Provide ATC with System Health Data

Based On:
R.1.2 System Health
Interfacing Items
Fault Data (D)
Input To:
System Health Data
Data
Output From:
Input To:
System Health Data
Data
Output From:
439
Interfacing Items
System Health (D)
Input To:
Personnel
Output From:
F.2 Operate Safely
System Health Data
Data
F.2.7 Provide Maintenance Personnel with System Health Data

Based On:
R.1.2 System Health
Table 20. F.2.7 Provide Maintenance Personnel with System Health Data Interfacing Items
Interfacing Items
Fault Data (D)
Input To:
System Health Data
Data
Output From:
Input To:
System Health Data
440
Table 20. F.2.7 Provide Maintenance Personnel with System Health Data Interfacing Items
Interfacing Items
Data
Output From:
System Health (D)
Input To:
Personnel
Output From:
F.2 Operate Safely
System Health Data
Data
441

Based On:
R.3 FOD Search
Interfacing Items
Input To:
F.3.1 Detect FOD
F.4 Retrieve FOD
Output From:
(External) FOD IOs
Input To:
F.4 Retrieve FOD
Large for Retrieval
F.4.3 Grasp FOD
Output From:
(External) FOD IOs
Input To:
Distance
data
Output From:
F.3.1 Detect FOD
Input To:
(External) FOD IOs
Output From:
442
Interfacing Items
Input To:
Output From:
FOD
Input To:
FOD
data
Output From:
Distance
Input To:
F.2 Operate Safely
F.4 Retrieve FOD
F.7 Maintain System
Output From:
F.8 Provide Power
Input To:
Output From:
FOD
443
Interfacing Items
F.4 Retrieve FOD
Large for Retrieval
Objects
444
effbd Scan Airfield for FOD
FOD
Characteristics (D)
(Ext) FOD
Identification
from FOD
Suitablity Data (D)
F.3.1
Determine FOD
Suitability from a
Distance
Detect FOD
System Context
Ref.
Unsuitable FOD
Location Data
F.3.2
F.3.4
System Context
AND
AND
F.3.3
Process Suitability
and Location of FOD
Ref.
System Context
FOD
System Context
FOD Location (D)
(Ext) FOD Location

from FOD

Mobile Units
Fod Illumination to
FOD
Date:
November 18, 2015
Figure 10. F.3 Scan Airfield for FOD (Enhanced FFBD)
445
n2 Scan Airfield for FOD
(Ext) FOD
Identification
from FOD
FOD
Characteristic
s (D)
(Ext) FOD
Location from
FOD
Suitablity
Data (D)
F.3.1
Detect FOD
System Context
FOD
Characteristic
s (D)
FOD
Characteristic
s (D)
F.3.2
Determine FOD
Suitability from a
Distance
System Context
Suitablity
Data (D)
Suitablity
Data (D)
FOD Location
(D)
Fod
Illumination
to FOD
F.3.3
Determine
Location of FOD
System Context
F.3.4
Process
Suitability and
Location of FOD
System Context
Date:
FOD Location
Data to
Mobile Units
Unsuitable ...
November 18, 2015
Figure 11. F.3 Scan Airfield for FOD (N2 Diagram)
F.3.1 Detect FOD

Based On:
R.3.2 FOD Detection
Interfacing Items
Input To:
F.3.1 Detect FOD
F.4 Retrieve FOD
Output From:
(External) FOD IOs
446
Interfacing Items
Input To:
Distance
data
Output From:
F.3.1 Detect FOD
F.3.2 Determine FOD Suitability from a Distance

Based On:
Interfacing Items
Input To:
Distance
data
Output From:
F.3.1 Detect FOD
Input To:
FOD
data
Output From:
Distance
447

Based On:
Interfacing Items
Input To:
F.4 Retrieve FOD
Large for Retrieval
F.4.3 Grasp FOD
Output From:
(External) FOD IOs
Input To:
(External) FOD IOs
Output From:
FOD Location (D)
Input To:
FOD
Output From:
F.3.4 Process Suitability and Location of FOD

Based On:
R.4 FOD Reporting
Interfacing Items
FOD Location (D)
Input To:
448
Interfacing Items
FOD
Output From:
Input To:
Output From:
FOD
Input To:
FOD
data
Output From:
Distance
Input To:
Output From:
FOD
F.4 Retrieve FOD
Large for Retrieval
Objects
449
F.4 Retrieve FOD

Based On:
R.5 FOD Retrieval
R.5.2 FOD Weight
Interfacing Items
Input To:
F.3.1 Detect FOD
F.4 Retrieve FOD
Output From:
(External) FOD IOs
Input To:
F.4 Retrieve FOD
Large for Retrieval
F.4.3 Grasp FOD
Output From:
(External) FOD IOs
Input To:
F.4 Retrieve FOD
data
Output From:
FOD too Large (S)
Input To:
Large for Retrieval
450
Interfacing Items
data
Output From:
F.4 Retrieve FOD
Input To:
Output From:
Command
F.4 Retrieve FOD
Input To:
F.2 Operate Safely
F.4 Retrieve FOD
F.7 Maintain System
Output From:
F.8 Provide Power
Unsuitable FOD (D)
Input To:
Output From:
F.4 Retrieve FOD
Input To:
Output From:
451
Interfacing Items
FOD
F.4 Retrieve FOD
Large for Retrieval
Objects
452
effbd Retrieve FOD

F.4.2
FOD too Large (S)
Unsuitable FOD
Location Data
At FOD Location
Signal (S)
Notify Personnel of Object

too Large for Retrieval
F.4.1
Ref.
Determine FOD
Dimensions
System Context
System Context
OR
OR
(Ext) FOD Location
from FOD
Notify Personnel of
Overweight Objects
F.4.4
F.4.3
(Ext) FOD
Identification from
FOD
Determine FOD
weight
Grasp FOD
System Context
System Context
FOD (M)
Grasped
FOD (F)
Ref.
F.4.5
Overweight
Signal
Navigation Modes
(D)
System Context
OR
OR
F.4.6
F.4.7
Transport FOD to
Disposal Area
Suitable for
Transport Signal
Release FOD
System Context
System Context
Date:
November 18, 2015
Figure 12. F.4 Retrieve FOD (Enhanced FFBD)
453
n2 Retrieve FOD
(Ext) FOD
Identificatio...
At FOD Loca...
FOD (M)
(Ext) FOD
Location from
FOD
FOD too La...
(Ext) FOD
Location from
FOD
FOD too
Large (S)
FOD (M)
At Disposal
Area Signal
F.4.1
Determine FOD
Dimensions
System Context
F.4.2
Notify Personnel
of Object too
Large for
Retrieval
System Context
FOD (M)
FOD too
Large (S)
Unsuitable
FOD Location
Data
F.4.3
Grasped FOD
(F)
Grasp FOD
System Context
F.4.4
Determine FOD
weight
System Context
Suitable for
Transport
Signal
Overweight
Signal
F.4.5
Notify Personnel
of Overweight
Objects
System Context
Unsuitable
FOD Location
Data
F.4.6
Transport FOD to
Disposal Area
System Context
Navigation
Modes (D)
F.4.7
Release FOD
System Context
Date:
November 18, 2015
Figure 13. F.4 Retrieve FOD (N2 Diagram)

Based On:
Interfacing Items
Input To:
F.3.1 Detect FOD
454
Interfacing Items
F.4 Retrieve FOD
Output From:
(External) FOD IOs
Input To:
F.4 Retrieve FOD
data
Output From:
FOD (M)
Input To:
F.4.3 Grasp FOD
Output From:
FOD too Large (S)
Input To:
Large for Retrieval
data
Output From:
F.4 Retrieve FOD
455
F.4.2 Notify Personnel of Object too Large for Retrieval

Based On:
R.5.3 FOD location
Interfacing Items
Input To:
F.4 Retrieve FOD
Large for Retrieval
F.4.3 Grasp FOD
Output From:
(External) FOD IOs
FOD too Large (S)
Input To:
Large for Retrieval
data
Output From:
F.4 Retrieve FOD
Input To:
Output From:
FOD
F.4 Retrieve FOD
Large for Retrieval
Objects
456
F.4.3 Grasp FOD

Based On:
R.5.5 FOD Grasping
Table 29. F.4.3 Grasp FOD Interfacing Items
Interfacing Items
Input To:
F.4 Retrieve FOD
Large for Retrieval
F.4.3 Grasp FOD
Output From:
(External) FOD IOs
FOD (M)
Input To:
F.4.3 Grasp FOD
Output From:
Grasped FOD (F)
Input To:
Output From:
F.4.3 Grasp FOD
457

Based On:
Table 30. F.4.4 Determine FOD weight Interfacing Items
Interfacing Items
Grasped FOD (F)
Input To:
Output From:
F.4.3 Grasp FOD
Overweight Signal
Input To:
Objects
Output From:
Input To:
Output From:
effbd Determine FOD weight

F.4.5
Notify Personnel
of Overweight ...
System Context
OR
F.4.3
F.4.6
Grasped
FOD (F)
Grasp FOD
Transport FOD to
Disposal Area
F.4.4
System Context
OR
Determine FOD
weight
System Context
OR
System Context
Ref.
Suitable for
Transport ...
Ref.
Overweight
Signal
Date:
November 18, 2015
Figure 14. F4.4 Determine FOD weight (Enhanced FFBD)
458
n2 Determine FOD weight
Grasped FOD
(F)
F.4.4
Determine FOD
weight
System Context
Overweight
Signal
Suitable for
Transport S...
University Edition - For Aca...
Date:
November ...
Figure 15. F4.4 Determine FOD weight (N2 Diagram)
F.4.5 Notify Personnel of Overweight Objects

Based On:
R.5 FOD Retrieval
R.5.3 FOD location
Table 31. F.4.5 Notify Personnel of Overweight Objects Interfacing Items
Interfacing Items
Overweight Signal
Input To:
Objects
Output From:
Input To:
Output From:
FOD
F.4 Retrieve FOD
Large for Retrieval
Objects
459

Based On:
R.5 FOD Retrieval
Table 32. F.4.6 Transport FOD to Disposal Area Interfacing Items
Interfacing Items
Input To:
Output From:
Command
F.4 Retrieve FOD
Input To:
Output From:
F.4.7 Release FOD

Based On:
R.5.5 FOD Grasping
Table 33. F.4.7 Release FOD Interfacing Items
Interfacing Items
Input To:
F.4.7 Release FOD
Output From:

Based On:
460
Interfacing Items
Input To:

Obstacle
Input To:
Output From:
Input To:
Output From:
Output From:
FOD Coordinates
Input To:
data
Output From:
Input To:
Output From:
FOD
Input To:
461
Interfacing Items
and Control (D)
Output From:
System Elements
Input To:

System Elements
Input To:
Output From:
Input To:
Output From:
Command
F.4 Retrieve FOD
Input To:
Output From:
Input To:
F.2 Operate Safely
462
Interfacing Items
F.3
F.4
F.5
F.6
F.7
F.9

Retrieve FOD
Navigate Airfield
Maintain System
Analyze FOD Trends
Output From:
F.8 Provide Power
463
effbd Navigate Airfield

F.5.2
Navigate to Emergency
Standby Location

Mobile Units
Standby
Emergency
Location
Coordinates
At Emergency
Location Signal
At Disposal Area
Signal
System Context
F.5.1
At FOD Location
Signal (S)
Obstacle Illumination
to Obstacle
F.5.3
FOD Coordinates
Process Navigation
Commands
(Ext) Obstacle
Location from
Obstacle
OR
Navigate to FOD Location
OR
System Context
System Context
Movement Command
to Locomote System
Elements
F.5.4
Navigation
Commands
(Ext) Obstacle
Identification from
Obstacle
Navigate to Disposal Area
Disposal Area
Coordinates
System Context
Obstacle Path
F.5.5
F.5.7
Detect Obstacles
System Context
Ref.
AND
AND
AND
F.5.6
(Ext) Aircraft
Location from
Aircraft (E)
Inbound Aircraft
Data from
Command and
Control (D)
Anticipate Obstacle
Movement
Avoid Obstacles
Control Motion
AND
System Context
Obstacle
Trajectory
System Context
Obstacle
Characteristics
F.5.9
Determine Location
Location Data from

Environment
Ref.
System Context
System Context
Receive Aircraft
Trajectory Data
F.5.10
F.5.8
Aircraft Illumination to
Aircraft
Coordinates (D)
System Context
Date:
November 18, 2015
Figure 16. F.5 Navigate Airfield (Enhanced FFBD)
464
n2 Navigate Airfield
(Ext) Aircraft
Location from
Aircraft (E)
Inbound Air...
(Ext)
Obstacle
Identificatio...
(Ext) Obsta...
FOD Location
Data to
Mobile Units
Navigation
Modes (D)
Location
Data from
Environment
FOD
Coordinates
F.5.1
Process
Navigation
Commands
System Context
Navigation
Commands
Navigation
Commands
Navigation
Commands
F.5.2
At
Emergency
Location Si...
Standby Em...
Navigate to
Emergency
Standby Location
System Context
F.5.3
Navigate to FOD
Location
System Context
System Context
At Disposal
Area Signal
Disposal Area
Coordinates
At Disposal
Area Signal
F.5.5
Detect Obstacles
System Context
Obstacle
Characteristic
s
Obstacle
Illumination
to Obstacle
Obstacle
Characteristic
s
Aircraft
Illumination
to Aircraft
F.5.6
Receive Aircraft
Trajectory Data
System Context
F.5.7
Anticipate
Obstacle
Movement
System Context
Obstacle
Trajectory
F.5.8
Avoid Obstacles
System Context
Coordinates
(D)
At FOD
Location
Signal (S)
FOD Coordi...
F.5.4
Navigate to
Disposal Area
Coordinates
(D)
At FOD
Location
Signal (S)
FOD Coordi...
Coordinates
(D)
Coordinates
(D)
Obstacle Path
F.5.9
Determine
Location
Coordinates
(D)
System Context
F.5.10
Control Motion
System Context
Date:
Movement
Command to
Locomote
System Ele...
November 18, 2015
Figure 17. F.5 Navigate Airfield (N2 Diagram)

Based On:
Interfacing Items
Navigation Commands
Input To:
Location
465
Interfacing Items
Output From:
Input To:
Output From:
Command
F.4 Retrieve FOD
F.5.2 Navigate to Emergency Standby Location

Based On:
R.1.1 Emergency
Interfacing Items
Input To:
Output From:
Location
Coordinates (D)
Input To:
Location
Output From:
Navigation Commands
Input To:
466
Interfacing Items
Location
Output From:

Coordinates
Input To:
Output From:
Location

Based On:
R.7.3 FOD Location
Interfacing Items
Input To:
F.4 Retrieve FOD
data
Output From:
Coordinates (D)
Input To:
Location
Output From:
FOD Coordinates
Input To:
467
Interfacing Items
data
Output From:
Input To:
Output From:
FOD
Navigation Commands
Input To:
Location
Output From:
468

Based On:
R.7.5 Disposal Area
Table 38. F.5.4 Navigate to Disposal Area Interfacing Items
Interfacing Items
Input To:
F.4.7 Release FOD
Output From:
Coordinates (D)
Input To:
Location
Output From:
Input To:
Output From:
Navigation Commands
Input To:
Location
Output From:
469

Based On:
Table 39. F.5.5 Detect Obstacles Interfacing Items
Interfacing Items
Obstacle
Input To:
Output From:
Input To:
Output From:
Input To:
Output From:
Input To:
Output From:
470

Based On:
Table 40. F.5.6 Receive Aircraft Trajectory Data Interfacing Items
Interfacing Items
Input To:
Output From:

and Control (D)
Input To:
Output From:
System Elements
Input To:
Output From:

Based On:
Interfacing Items
Input To:
Output From:
471
Interfacing Items
Obstacle Trajectory
Input To:
Output From:

Based On:
Interfacing Items
Coordinates (D)
Input To:
Location
Output From:
Obstacle Path
Input To:
Output From:
Obstacle Trajectory
Input To:
Output From:

Based On:
472

Table 43. F.5.9 Determine Location Interfacing Items
Interfacing Items
Coordinates (D)
Input To:
Location
Output From:
Input To:

Based On:
Interfacing Items
Input To:
F.4.7 Release FOD
Output From:
Input To:
Output From:
Location
Input To:
F.4 Retrieve FOD
473
Interfacing Items
data
Output From:
Coordinates (D)
Input To:
Location
Output From:
Input To:
Output From:
FOD Coordinates
Input To:
data
Output From:

System Elements
Input To:
Output From:
Obstacle Path
Input To:
474
Interfacing Items
Output From:

Coordinates
Input To:
Output From:
Location
475

Based On:
Interfacing Items
Heat to Environment
Input To:
Output From:

System Elements
Input To:
Output From:
Input To:
Output From:
Input To:
Output From:
Input To:
476
Interfacing Items
F.2
F.3
F.4
F.5
F.6
F.7
F.9
Operate Safely
Retrieve FOD
Navigate Airfield
Maintain System
Analyze FOD Trends
Output From:
F.8 Provide Power
effbd Locomote System Elements
Mobile Unit
Energy Source
Mobile Unit
Power
F.6.1
Facilitate Power
System Context
Ref.
AND
Ref.
AND
F.6.2
Facilitate
Movement
System Context
Movement
Command to
Locomote System
Elements
Heat to
Environment
Date:
November 18, 2015
Figure 18. F.6 Locomote System Elements (Enhanced FFBD)
477
n2 Locomote System Elements
Mobile Unit
Energy
Source
Movement
Command to
Locomote
System Ele...
F.6.1
Facilitate Power
System Context
Mobile Unit
Power
F.6.2
Facilitate
Movement
System Context
Heat to
Environment
Resistance t...
Sound to En...
Date:
November 18, 2015
Figure 19. Locomote System Elements (N2 Diagram)

Based On:
Table 46. F.6.1 Facilitate Power Interfacing Items
Interfacing Items
Mobile Unit Energy Source
Input To:
Mobile Unit Power
Input To:
Output From:
478

Based On:
Interfacing Items
Heat to Environment
Input To:
Output From:
Mobile Unit Power
Input To:
Output From:

System Elements
Input To:
Output From:
Input To:
Output From:
Input To:
Output From:
479
Interfacing Items
effbd Facilitate Movement

Movement Command
to Locomote System
Elements
Resistance to
Environment
F.6.2.1
Control
F.6.2.3
System Context
Ref.
Facilitate Braking
AND
AND
Ref.
F.6.2.2
System Context
Facilitate Motion
Mobile Unit
Power
Heat to
Environment
System Context
Mobile Unit
Kinetic Energy
Sound to
Environment
Date:
November 18, 2015
Figure 20. F.6.2 Facilitate Movement (Enhanced FFBD)
480
n2 Facilitate Movement
Mobile Unit
Power
Movement
Command to...
Mobile Unit
Power
Movement
Command to...
Movement
Command to
Locomote
System Ele...
F.6.2.1
Facilitate
Directional Control
System Context
Mobile Unit
Kinetic Energy
Resistance to
Environment
Mobile Unit
Kinetic Energy
Sound to
Environment
F.6.2.2
Facilitate Motion
System Context
F.6.2.3
Facilitate Braking
Heat to
Environment
System Context
Date:
November 18, 2015
Figure 21. Facilitate Movement (N2 Diagram)

Based On:
Interfacing Items
Input To:
Output From:
Mobile Unit Power
Input To:
Output From:

System Elements
Input To:
481
Interfacing Items
Output From:
Input To:
Output From:

Based On:
Interfacing Items
Input To:
Output From:
Mobile Unit Power
Input To:
Output From:

System Elements
Input To:
482
Interfacing Items
Output From:
Input To:
Output From:

Based On:
Interfacing Items
Heat to Environment
Input To:
Output From:
Input To:
Output From:

System Elements
Input To:
483
Interfacing Items
Output From:
484
F.7 Maintain System

Based On:
Interfacing Items
Input To:
F.7 Maintain System
Output From:
Input To:
F.7 Maintain System
F.7.1 Accept Parts
Output From:
Input To:
F.7 Maintain System
Output From:
Input To:
Output From:
F.7 Maintain System
Parts to Maintainer
Input To:
Output From:
F.7 Maintain System
F.7.5 Eject Parts
Input To:
F.2 Operate Safely
485
Interfacing Items
F.3
F.4
F.5
F.6
F.7
F.9

Retrieve FOD
Navigate Airfield
Maintain System
Analyze FOD Trends
Output From:
F.8 Provide Power
effbd Maintain System

(Ext) Parts from
Maintainer
F.7.1
Accept Parts
System Context
(Ext) Materials
from Maintainer
F.7.2
Accept Materials
System Context
F.7.3
Ref.
AND
Accept SW
Updates
AND
Ref.
System Context
Materials to
Maintainer
F.7.4
(Ext) SW Update
from Maintainer
Eject Materials
System Context
Parts to Maintainer
F.7.5
Eject Parts
System Context
Date:
November 18, 2015
Figure 22. F.7 Maintain System (Enhanced FFBD)
486
n2 Maintain System
(Ext)
Materials
from
Maintainer
(Ext) Parts
from
Maintainer
(Ext) SW
Update from
Maintainer
F.7.1
Accept Parts
System Context
F.7.2
Accept Materials
System Context
F.7.3
Accept SW
Updates
System Context
F.7.4
Materials to
Maintainer
Eject Materials
System Context
F.7.5
Eject Parts
Parts to
Maintainer
System Context
Date:
November 18, 2015
Figure 23 Maintain System (N2 Diagram)

F.7.1 Accept Parts
Based On:
Table 52. F.7.1 Accept Parts Interfacing Items
Interfacing Items
Input To:
F.7 Maintain System
F.7.1 Accept Parts
Output From:

Based On:
487

Table 53. F.7.2 Accept Materials Interfacing Items
Interfacing Items
Input To:
F.7 Maintain System
Output From:

Based On:
Table 54. F.7.3 Accept SW Updates Interfacing Items
Interfacing Items
Input To:
F.7 Maintain System
Output From:

Based On:
Table 55. F.7.4 Eject Materials Interfacing Items
Interfacing Items
Input To:
Output From:
F.7 Maintain System
488
F.7.5 Eject Parts

Based On:
Table 56. F.7.5 Eject Parts Interfacing Items
Interfacing Items
Parts to Maintainer
Input To:
Output From:
F.7 Maintain System
F.7.5 Eject Parts
489
F.8 Provide Power

Based On:
R.12 System Power
Table 57. F.8 Provide Power Interfacing Items
Interfacing Items
Input To:
F.8 Provide Power
Output From:
Input To:
Output From:
F.8 Provide Power
Input To:
F.2 Operate Safely
F.4 Retrieve FOD
F.7 Maintain System
Output From:
F.8 Provide Power
490
effbd Provide Power

Power (E)
F.8.1
(Ext) Electrical
Energy from
Power
Power Failure
Signal from
Power (S)
Accept External
Power
System Context
AND
AND
F.8.2
Detect External
Power Failure
F.8.4
System Context
Ref.
Transfer Power
OR
OR
F.8.3
Ref.
System Context
Generate
Emergency Power
transferred
Power (E)
System Context
Generator Power
Date:
November 18, 2015
Figure 24 F.8 Provide Power (Enhanced FFBD)
n2 Provide Power
(Ext)
Electrical
Energy from
Power
(Ext)
Electrical
Energy from
Power
F.8.1
Accept External
Power
Power (E)
System Context
F.8.2
Power Failure
Signal from
Power (S)
Detect External
Power Failure
System Context
F.8.3
Generate
Emergency Power
System Context
Generator
Power
F.8.4
Transfer Power
transferred
Power (E)
System Context
Date:
November 18, 2015
Figure 25. Provide Power (N2 Diagram)

Based On:
491
R.12 System Power

Table 58. F.8.1 Accept External Power Interfacing Items
Interfacing Items
Input To:
F.8 Provide Power
Output From:
Power (E)
Input To:
Output From:

Based On:
Interfacing Items
Input To:
F.8 Provide Power
Output From:
Input To:
Output From:
F.8 Provide Power

Based On:
492

Table 60. F.8.3 Generate Emergency Power Interfacing Items
Interfacing Items
Generator Power
Input To:
Output From:

Based On:
R.12 System Power
Interfacing Items
Generator Power
Input To:
Output From:
Power (E)
Input To:
Output From:
Input To:
F.2 Operate Safely
F.4 Retrieve FOD
F.7 Maintain System
Output From:
F.8 Provide Power
493

Based On:
Interfacing Items
Input To:
F.4 Retrieve FOD
data
Output From:
Input To:
Distance
data
Output From:
F.3.1 Detect FOD
FOD Coordinates
Input To:
data
Output From:
FOD too Large (S)
Input To:
Large for Retrieval
494
Interfacing Items
data
Output From:
F.4 Retrieve FOD
Input To:
Output From:
Input To:
FOD
data
Output From:
Distance
Input To:
F.2 Operate Safely
F.4 Retrieve FOD
F.7 Maintain System
Output From:
F.8 Provide Power
495
effbd Analyze FOD Trends

At FOD Location
Signal (S)
FOD Trend Data

(D)
FOD Coordinates
F.9.1
Ref.
F.9.2
Accept FOD alert time and

date, location coordinates
and FOD image data
F.9.4
F.9.3
Retain Data
System Context
System Context
System Context
Export FOD Reports
System Context
Suitablity Data (D)
FOD
Characteristics
(D)
Ref.
Reports to
Airport Managers
(E)
Raw FOD
Data
FOD too Large (S)
Date:
November 18, 2015
Figure 26. F.9 Analyze FOD Trends (Enhanced FFBD)
496
n2 Analyze FOD Trends
At FOD Loca...
FOD Charac...
FOD Coordi...
FOD too La...
F.9.1
Accept FOD alert
time and date,
location
coordinates and...
System Context
Raw FOD
Data
F.9.2
Perform Trend
Analysis
System Context
FOD Trend
Data (D)
FOD Trend
Data (D)
F.9.3
Retain Data
System Context
F.9.4
Reports to
Airport
Managers (E)
Export FOD
Reports
System Context
Date:
November 18, 2015
Figure 27. Analyze FOD Trends (N2 Diagram)
F.9.1 Accept FOD alert time and date, location coordinates and FOD image data
Based On:
R.8.1 Types of Data
Table 63. F.9.1 Accept FOD alert time and date, location coordinates and FOD image data
Interfacing Items
Interfacing Items
Input To:
F.4 Retrieve FOD
data
Output From:
497
Interfacing Items
Interfacing Items
Input To:
Distance
data
Output From:
F.3.1 Detect FOD
FOD Coordinates
Input To:
data
Output From:
FOD too Large (S)
Input To:
Large for Retrieval
data
Output From:
F.4 Retrieve FOD
Raw FOD Data
Input To:
Output From:
data
Input To:
FOD
498
Interfacing Items
Interfacing Items
data
Output From:
Distance

Based On:
Table 64. F.9.2 Perform Trend Analysis Interfacing Items
Interfacing Items
FOD Trend Data (D)
Input To:
F.9.3 Retain Data
Output From:
Raw FOD Data
Input To:
Output From:
data
499
F.9.3 Retain Data

Based On:
Table 65. F.9.3 Retain Data Interfacing Items
Interfacing Items
FOD Trend Data (D)
Input To:
F.9.3 Retain Data
Output From:

Based On:
Table 66. F.9.4 Export FOD Reports Interfacing Items
Interfacing Items
FOD Trend Data (D)
Input To:
F.9.3 Retain Data
Output From:
Input To:
Output From:
500
Appendix D
AFDIRTS Conceptual Design Report (CDR
501
Table of Contents
Updated Context Diagram....
504
AFDIRTS Physical Description 505

AFDIRTS Physical Tree. 505
AFDIRTS Physical Decomposition 506
COMP.1 Command and Control Segment............................................. 506
Command and Control Physical Description... 506
Command and Control Segment Physical Tree.. 506
Command and Control Segment Physical Block Diagram.. 507
Command and Control Segment Functional Traceability Matrix 507
Command and Control Segment Interface Description.. 508
COMP.2 System Health and Monitoring Segment. 513
System Health and Monitoring Segment Physical Description 513
System Health and Monitoring Segment Physical Tree. 513
System Health and Monitoring Segment Physical Block Diagram. 514
System Health and Monitoring Segment Functional Traceability Matrix. 515
System Health and Monitoring Segment Interface Description
516
COMP.3 FOD Detection Segment.. 518

FOD Detection Segment Physical Description 518
FOD Detection Segment Physical Tree.
519
FOD Detection Segment Physical Block Diagram. 519

FOD Detection Segment Functional Traceability Matrix.. 520
FOD Detection Segment Interface Description.. 520
COMP.4 Air Retrieval Vehicle (ARV).. 522
Air Retrieval Vehicle (ARV) Physical Description.. 522
Air Retrieval Vehicle (ARV) Conceptual Image 522
Air Retrieval Vehicle Physical Tree 522
COMP.4.1 ARV Movement and Control Subsystem 523
Movement and Control Physical Description 523
Movement and Control Physical Block Diagram. 523
Movement and Control Subsystem Functional Traceability Matrix 524
Movement and Control Subsystem Interface Descriptions 526
502
COMP4.2 ARV Navigation Subsystem 536

ARV Navigation Subsystem Physical Description. 536
ARV Navigation Subsystem Physical Tree 536
ARV Navigation Subsystem Physical Block Diagram 537
ARV Navigation Subsystem Functional Traceability Matrix. 538
ARV Navigation Subsystem Interface Descriptions 539
COMP.4.3 ARV Power Subsystem 542
ARV Power Subsystem Physical Description 542
ARV Power Subsystem Physical Tree 542
ARV Power Subsystem Physical Block Diagram 543
ARV Power Subsystem Functional Traceability Matrix
544
ARV Power Subsystem Interface Descriptions 545

COMP.4.3 ARV Retrieval Subsystem 548
ARV Retrieval Subsystem Physical Description
548
VERSABALL Gripper Image 548

ARV Retrieval Subsystem Physical Tree 548
ARV Retrieval Subsystem Physical Block Diagram 549
ARV Retrieval Subsystem Functional Traceability Matrix 550
ARV Retrieval Subsystem Interface Descriptions
550
553
Power and Housing Segment Physical Description 553

Power and Housing Segment Conceptual Image 553
Power and Housing Segment Physical Tree
554
Power and Housing Physical Block Diagram 554

Power and Housing Segment Functional Traceability Matrix
555
Power and Housing Segment Interface Descriptions .
555
COMP.6 FOD Analysis Segment
558
FOD Analysis Segment Physical Description
558
FOD Analysis Segment Physical Tree
558
Analysis Segment Physical Block Diagram 559

Analysis Segment Functional Traceability Matrix 559
Analysis Segment Interface Descriptions
560
503
Updated AFDIRTS Context Diagram
Air Traffic
Control
Environment
Heat (E)
Sound (E)
Rain (M)
Resistance (E)
Wind (F)
Snow (M)
GPS Signals (D)
Gravity (F)
Inertia (F)
Barometric
Pressure
System Health (D)

System Status (D)
Reports (D)
Obstacles

Airport
Managers
ATC Command (D)

Aircraft Radar Data
(D)
AFDIRTS
Aircraft
Operators

Forces (F)
Energy (E)
Data (D)
Signals (S)
FOD Location (E)

Materials (M)
Parts (M)
Materials (M)
Fault Codes (D)
System Health (D)
Power
Parts (M)
Materials (M)
SW Update (S)
FOD
Maintainer
Figure 1. Updated AFDIRTS Context Diagram
504
AFDIRTS Physical Description
The Concept Exploration phase of the systems engineering method produced three
concepts that could potentially solve the need for a FOD Detection and Retrieval
system. The three options were; the Roomba Option, which made use of roaming
mobile units that would continuously search the airfield for FOD (much like the vacuum
Roomba). The ground retrieval option, which made use of existing FOD detection
systems that would continuously sweep the airfield for FOD and then when found,
location would be transmitted to the mobile units for retrieval. And finally, the Airborne
Option which operated much like the ground retrieval option except the retrieval units
were airborne.
The Airborne Option was selected during the Concept Selection step of the systems
engineering method and the physical architecture has been documented in this report.
Informal trade studies revealed many advantages to the Airborne Option. Some of the
factors of selection were; mobile unit speed, ability to navigate above obstacles, ability
to cross unpaved surfaces and ease of FOD disposal. Additionally, it is believed that in
future versions, could incorporate bird deterrent functionality.
The AFDIRTS consists of six major subsystems that are discussed in more detail below.
505
The Command and Control Segment of the AFDIRTS is made up of 7 Hardware

Configuration Items (HWCI) and 1 Software Configuration Item (SWCI) integrated to
perform function F.1 Command and Control the System. In addition to command and
control the Segment allows users to interface with the AFDIRTS.
506
Figure 3. COMP.1 Command and Control Segment Physical Block Diagram
ATC -> ARIU
pbd Command and Control Segment
COMP.3.1
IFerret TM &
AFDIRTS Interface
Unit
Maintenance IUser
Interface (MUI)
Airport Management
Display Unit (AMDU)
Subsystem
Subsystem
Subsystem
CPU <-> MUI
CPU <-> AMDU
ATC User Interface

(AUI)
HWCI
COMP.1.5
ATC Radar Interface
Unit (ARIU)
Subsystem
COMP.1.6
(CCR) Command and
Control Radio
COMP.1.3
HWCI
Command and
Control Computer
(CCC)
CPU <-> CCR
HWCI
BACKUP CPU <-> CPU
NAV Radio
HWCI
CPU <-> AUI
COMP.6.1
COMP.4.2.5
Retrieval Telemetry
Radio
HWCI
ARIU-> CPU
Command and Control Computer (CCC) -> IFerret TM & AFDIRTS Interface U...
COMP.1.1
COMP.1.7
COMP.4.4.1
Command and
Control Interface Unit
(CCIU)
COMP.1.2
COMP.2.4
CCR -> NAV Radio
External System
External System
AMDU -> AIRPORT MANAGERS
ATC -> AUI
AUI -> ATC
Airport Managers
MUI -> MAINTAINER
External System
Subsystem
ENV.3
Maintainer
CCR-> Airport Management Display Unit
ENV.6
Air Traffic Control
Iferret -> AMDU
ENV.1
COMP.1.4
Backup CPU
Analysis Computer
Subsystem
HWCI
Date:
December 4, 2015
Table 1. COMP.1 Command and Control Segment Functional Traceability Matrix
Number
Name
Type
Performs
COMP.1
Command and Control

Segment
Segment
Function F.1 Command

and Control System
COMP.1.1
Airport Management
Display Unit (AMDU)
Subsystem

with Airport Managers
COMP.1.2
ATC User Interface (AUI)
Subsystem

with ATC
507
COMP.1.3
Command and Control

Computer (CCC)
HWCI
Function F.1.2 Initiate

System Modes
COMP.1.3.1
Command and Control OS
SWCI
COMP.1.4
Backup CPU
Subsystem
COMP.1.5
ATC Radar Interface Unit

(ARIU)
Subsystem
COMP.1.6
(CCR) Command and

Control Radio
HWCI
COMP.1.7
Maintenance User
Interface (MUI)
Subsystem
Function F.1.5 Determine

Location, Trajectory and
Function F.1.9 Restore
System
Function F.1.10 Receive
Location Trajectory and
Speed of Inbound Aircraft
Normal Operation
Command
Emergency Command
Inbound Aircraft Data to
System Elements
Function Receive
Unsuitable FOD Data From
ARV
with Maintenance
Personnel
Function F.1.8.1 Initiate
Self-Test
Function F.1.8.2 Display
Maintenance Data
Table 2. COMP.1 Command and Control Segment Interface Description
Number
Name
Transfers
Connects to
L.1.1
AUI -> ATC
Item System
Health to ATC
Component
COMP.1.2 ATC User
Interface (AUI)
Component
ENV.1 Air Traffic
Control
508
L.1.2
L.1.3
L.1.4
L.1.5
L.1.6
ATC -> AUI
MUI -> MAINTAINER
AMDU -> AIRPORT

MANAGERS
Iferret -> AMDU
Command and
Control Computer
(CCC) -> IFerret TM
& AFDIRTS Interface
Unit
Item (Ext) ATC

Command from
ATC
Item (Ext)
Maintenance
Commands from
Maintainer
Item System
Health Data to
Maintainer
Item System
Health to Airport
Managers
Item Unsuitable
FOD Data to Airport
Managers
Item FOD
Location
Item Unsuitable
FOD Location Data
Item Navigation
Modes
Component
COMP.1.2 ATC User
Interface (AUI)
Component
ENV.1 Air Traffic
Control
Component
COMP.1.7
Maintenance User
Interface (MUI)
Component
ENV.6 Maintainer
Component
COMP.1.1 Airport
Management
Display Unit (AMDU)
Component
ENV.3 Airport
Managers
Component
COMP.1.1 Airport
Management
Display Unit (AMDU)
Component
COMP.3.1 IFerret
TM & AFDIRTS
Interface Unit
Component
COMP.1.3
Command and
Control Computer
(CCC)
Component
COMP.3.1 IFerret
TM & AFDIRTS
Interface Unit
509
L.1.7
L.1.8
L.1.9
L.1.10
ATC -> ARIU
CCIU ->
COMMAND AND
CONTROL CPU
ARIU-> CPU
CPU <-> MUI
Item (Ext)
Aircraft Radar Data
from ATC
Item Self-Test
Results
Item System
Health
Item Aircraft
Trajectory Data
Item
Maintenance
Commands
Item Self-Test
Results
Item System
Health Data to
Maintainer
Component
COMP.1.5 ATC
Radar Interface
Unit (ARIU)
Component
ENV.1 Air Traffic
Control
Component
COMP.1.3
Command and
Control Computer
(CCC)
Component
COMP.2.4
Command and
Control Interface
Unit (CCIU)
Component
COMP.1.3
Command and
Control Computer
(CCC)
Component
COMP.1.5 ATC
Radar Interface
Unit (ARIU)
Component
COMP.1.3
Command and
Control Computer
(CCC)
Component
COMP.1.7
Maintenance User
Interface (MUI)
510
L.1.11
CPU <-> AMDU
Item Self-Test
Results
Item System
Health to Airport
Managers
L.1.12
CPU <-> AUI
Item Command
Signal
Item Self-Test
Results
Item System
Health to ATC
L.1.13
L.1.14
Analysis Computer > AMDU
BACKUP CPU <->

CPU
Item Reports to
Airport Managers
Item CPU Data
Component
COMP.1.1 Airport
Management
Display Unit (AMDU)
Component
COMP.1.3
Command and
Control Computer
(CCC)
Component
COMP.1.2 ATC User
Interface (AUI)
Component
COMP.1.3
Command and
Control Computer
(CCC)
Component
COMP.1.1 Airport
Management
Display Unit (AMDU)
Component
COMP.6.1 Analysis
Computer
Component
COMP.1.3
Command and
Control Computer
(CCC)
Component
COMP.1.4 Backup
CPU
511
L.1.15
L.1.16
L.1.17
L.1.18
CPU <-> CCR
CCR-> Airport
Management
Display Unit
Retrieval Telemetry
Radio -> CCR
CCR -> NAV Radio
Item Aircraft
Trajectory Data
Item Emergency
Operation
Command
Item
Maintenance
Commands
Item Normal
Operation
Command
Item Unsuitable
FOD Location Data
Item Unsuitable
FOD Location Data
From ARV
Item Unsuitable
FOD Location Data
Item Inbound
Aircraft Data to
ARV
Item Navigation
Modes
Component
COMP.1.3
Command and
Control Computer
(CCC)
Component
COMP.1.6 (CCR)
Command and
Control Radio
Component
COMP.1.1 Airport
Management
Display Unit (AMDU)
Component
COMP.1.6 (CCR)
Command and
Control Radio
Component
COMP.1.6 (CCR)
Command and
Control Radio
Component
COMP.4.4.1
Retrieval Telemetry
Radio
Component
COMP.1.6 (CCR)
Command and
Control Radio
Component
COMP.4.2.5 NAV
Radio
512
COMP.2 FOD System Health and Monitoring Segment
Figure 4. COMP.2 System Health and Monitoring Segment Physical Tree
513
Figure 5. COMP.2 System Health and Monitoring Segment Physical Block Diagram
pbd System Health Monitoring Segment
COMP.1.3
Command and
Control Computer
(CCC)
HWCI
COMP.2.1
COMP.2.4
System Heath Radio

(SHR)
Command and Control

Interface Unit (CCIU)
HWCI
HWCI
SHR -> SHC
Critical Components -> SHR
SHC -> CCIU

COMP.2.2
System Health
Computer (SHC)
HWCI
SHC-> Critical Components

COMP.2.3
Components Defined
as "Critical" During
Advanced
Development
HWCI
Date:
December 4, 2015
514
Table 3. COMP.2 System Health and Monitoring Segment Functional Traceability Matrix
Number
Name
Type
Performs
COMP.2
System Health
Monitoring
Segment
Segment
Function F.2
Operate Safely
COMP.2.1
System Heath
Radio (SHR)
HWCI
COMP.2.2
System Health
Computer (SHC)
HWCI
COMP.2.2.1
System Health
Software
SWCI
COMP.2.3
Components
During Advanced
Development
HWCI
COMP.2.4
Command and
Control Interface
Unit (CCIU)
HWCI
Function F.2.1
Receive Telemetry
Signal From
Stationary Elements
Function F.2.3
Receive Telemetry
Data from Mobile
Elements
Function F.2.2
Monitor the Health
of Stationary
Element Critical
Subsystems
Function F.2.4
Monitor the Health
of Mobile Element
Critical
Components
Function F.2.4.1
Direct SHC
operation
Function F.2.5
Compensate for
Failures in Mobile
Unit Critical
Components
Function F.2.6
Provide Airport
Managers with
System Health Data
Function F.2.7
Provide ATC with
System Health Data
Function F.2.8
Provide
Maintenance
515
Personnel with
System Health Data
Table 4. COMP.2 System Health and Monitoring Segment Interface Descriptions
Number
Name
L.2.1
Critical
Item Critical
Components -> SHR Subsystem
Telemetry Signal
From Mobile
Elements
Item Critical
Subsystem
Telemetry Signal
from Stationary
Elements
SHR -> SHC
Item Critical
Subsystem
Telemetry Data
From Mobile
Elements
Item Critical
Subsystem
Telemetry Data
from Stationary
Elements
SHC -> CCIU
Item Fault Data
L.2.2
L.2.3
Transfers
Connects to
Component
COMP.2.1 System
Heath Radio (SHR)
Component
COMP.2.3
Components
During Advanced
Development
Component
COMP.2.1 System
Heath Radio (SHR)
Component
COMP.2.2 System
Health Computer
(SHC)
Component
COMP.2.2 System
Health Computer
(SHC)
Component
COMP.2.4
516
L.2.4
SHC-> Critical
Components
Item Critical
Component
Degraded Signal
Command and
Control Interface
Unit (CCIU)
Component
COMP.2.2 System
Health Computer
(SHC)
Component
COMP.2.3
Components
During Advanced
Development
517
Figure 6. IFerretTM Detection System
518
Figure 7. COMP.3 FOD Detection Segment Physical Tree
Figure 8. COMP.3 FOD Detection Segment Physical Block Diagram

pbd Detection Segment
COMP.4
(ARV) Segment
Segment
COMP.1.1
Airport Management
Display Unit (AMDU)
Subsystem
IFerret -> ARU

COMP.6.2
Iferret -> AMDU
Analysis Radio
HWCI

COMP.1.3
COMP.3.1
IFerret TM &
AFDIRTS Interface
Unit
Command and Control Computer (CCC) -> IFerret TM & AFDIRTS Interface Unit
Command and
Control Computer
(CCC)
HWCI
Subsystem
Date:
December 4, 2015
519
Table 5. COMP.3 FOD Detection Segment Functional Traceability Matrix
Number
Name
Type
Performs
COMP.3
Detection Segment
Segment
Function F.3 Scan

Airfield for FOD
COMP.3.1
IFerret TM & AFDIRTS

Interface Unit
Subsystem
Function F.3.1
Detect FOD
Function F.3.2
Determine FOD
Suitability from a
Distance
Function F.3.3
Determine Location
of FOD
Function F.3.4
Process Suitability
and Location of
FOD
Table 6. COMP.3 FOD Detection Segment Interface Descriptions
Number Name
Transfers
Connects to
L.3.1
Item FOD
Location Data to
Mobile Units
Component
COMP.3.1 IFerret
TM & AFDIRTS
Interface Unit
L.3.2
IFerret -> ARU

Item FOD
Characteristics
Item Suitability
Data
Component
COMP.4 Air
Retrieval Vehicle
(ARV) Segment
Component
COMP.3.1 IFerret
TM & AFDIRTS
Interface Unit
Component
COMP.6.2 Analysis
Radio
520
L.1.6
L.1.5
Command and Control

Computer (CCC) -> IFerret TM
& AFDIRTS Interface Unit
Iferret -> AMDU
Item Navigation
Modes
Item FOD
Location
Item Unsuitable
FOD Location Data
Component
COMP.1.3
Command and
Control Computer
(CCC)
Component
COMP.3.1 IFerret
TM & AFDIRTS
Interface Unit
Component
COMP.1.1 Airport
Management
Display Unit (AMDU)
Component
COMP.3.1 IFerret
TM & AFDIRTS
Interface Unit
521
COMP.4 Air Retrieval Vehicle (ARV) Segment
The Air Retrieval Vehicle (ARV) is designed to transport the Retrieval Subsystem System
to the FODs location on the airfield and grasp it with a COTS gripper, the VERSABALL
developed by Empire Robotics. The ARV consists of four Subsystems; the Movement and
Control Subsystem, the Navigation Subsystem, ARV Power Subsystem, and the Retrieval
Subsystem. These subsystems will be discussed in detail below.
Figure 10. COMP.4 Air Retrieval Vehicle Physical Tree
522
COMP.4.1 Movement and Control Subsystem
The Movement and Control Subsystem has been designed to facilitate movement and
stability of the ARV while maneuvering to waypoints. It consists of an Attitude and
Heading Reference System (AHARS), Barometric Altimeter, GPS Unit, Movement and
Control Computer, 8 Propellers, 8 Electric Motors and 8 Electronic Speed Controllers.
Figure 11. COMP.4.1 Movement and Control Subsystem Physical Tree
Figure 12. COMP.4.1 Movement and Control Physical Block Diagram

pbd Movement and Control Subsystem
ENV.4
Environment

External System
Electronic Speed
Controller (ESC)_3
Electronic Speed
Controller (ESC)_4
HWCI
HWCI
HWCI
HWCI
HWCI
MMCPU - > ESC_3
EM_#8 -> Prop_#8
EM_#7 -> Prop_#7
EM_#6 -> Prop_#6
EM_#5 -> Prop_#5
MCGPS - > MCCPU
COMP.4.1.10
COMP.4.1.9
Electric Motor
(EM)_6
Electric Motor
(EM)_7
Electric Motor
(EM)_8
HWCI
HWCI
HWCI
HWCI
COMP.4.1.1
Attitude and Heading
Reference Systems
(AHRS)
COMP.4.1.8
Electric Motor
(EM)_5
COMP.4.1.15
COMP.4.1.16
COMP.4.1.17
COMP.4.1.18
Electronic Speed
Controller (ESC)_5
Electronic Speed
Controller (ESC)_6
Electronic Speed
Controller (ESC)_7
Electronic Speed
Controller (ESC)_8
HWCI
HWCI
HWCI
HWCI
HWCI
AHARS -> MCCPU
MMCPU - > ESC_4
Electronic Speed
Controller (ESC)_2
Part
ESC8 -> EM8
ESC3 -> EM3
ESC4 -> EM4

GPS Unit (MCGPS)
Electronic Speed
Controller (ESC)_1
MMCPU - > ESC_2
BARALT - > MCCPU
ESC2 -> EM2
COMP.4.1.20
COMP.4.1.14
Propeller_8
Part
MMCPU - > ESC_8
HWCI
COMP.4.1.28
Propeller_7
Part
ESC7 -> EM7
HWCI
COMP.4.1.27
Propeller_6
MMCPU - > ESC_7
HWCI
HWCI
COMP.4.1.26
ESC6 -> EM6
HWCI
ESC1 -> EM1
Electric Motor
(EM)_4
COMP.4.1.13
COMP.4.1.7
Barometric Altimeter
Electric Motor
(EM)_3
MMCPU -> ESC_1
Part
COMP.4.1.2
COMP.4.1.6
Electric Motor
(EM)_2
COMP.4.1.12
Propeller_5
MMCPU - > ESC_6
COMP.4.1.5
Electric Motor
(EM)_1
COMP.4.1.11
COMP.4.1.25
ESC5 -> EM5
COMP.4.1.4
Propeller_4
Part
EM_#3 -> Prop_#3
EM_#2 -> Prop_#2
EM_#1 -> Prop_#1
COMP.4.1.3
Propeller_3
Part
Part
Part
COMP.4.1.24
COMP.4.1.23
Propeller_2
MMCPU - > ESC_5
COMP.4.1.22
Barometric Altimeter / Environment
Propeller_1
EM_#4 -> Prop_#4
COMP.4.1.21
COMP.4.1.19
PDB -> ESC_5
COMP.4.3.1
PDB -> ESC_6
Power Distribution
Board (PDB)
PDB -> ESC_8
HWCI
PDB -> ESC_7
PDB -> ESC_4
HWCI
PDB-> ESC_3
PDB -> ESC_2
PDB -> ESC_1

Computer (MCCOMP)
COMP.4.2.1
NAV Computer
HWCI
Date:
December 4, 2015
523
Table 7. COMP.4.1 Movement and Control Subsystem Functional Traceability Matrix
Number
Name
Type
Performs
COMP.4.1
Movement and
Control Subsystem
Subsystem
COMP.4.1.1
Attitude and
Heading Reference
Systems (AHRS)
HWCI
Function F.4.1
Move and Control
ARV
Function F.4.1.27
Determine Position
in Space
COMP.4.1.2
Barometric
Altimeter
HWCI
COMP.4.1.3
Electric Motor
(EM)_1
HWCI
COMP.4.1.4
Electric Motor
(EM)_2
HWCI
Function F.4.1.6
Spin #2 Propeller
COMP.4.1.5
Electric Motor
(EM)_3
HWCI
Function F.4.1.9
Spin #3 Propeller
COMP.4.1.6
Electric Motor
(EM)_4
HWCI
Function F.4.1.12
Spin #4 Propeller
COMP.4.1.7
Electric Motor
(EM)_5
HWCI
Function F.4.1.15
Spin #5 Propeller
COMP.4.1.8
Electric Motor
(EM)_6
HWCI
Function F.4.1.18
Spin #6 Propeller
COMP.4.1.9
Electric Motor
(EM)_7
HWCI
Function F.4.1.21
Spin #7 Propeller
COMP.4.1.10
Electric Motor
(EM)_8
HWCI
Function F.4.1.24
Spin #8 Propeller
COMP.4.1.11
Electronic Speed
Controller (ESC)_1
HWCI
COMP.4.1.12
Electronic Speed
Controller (ESC)_2
HWCI
COMP.4.1.13
Electronic Speed
Controller (ESC)_3
HWCI
Function F.4.1.2
Control #1 Motor
Speed
Function F.4.1.5
Control #2 Motor
Speed
Function F.4.1.8
Control #3 Motor
Speed
Function F.4.1.28
Determine
Barometric Pressure
Function F.4.1.3
Spin #1 Propeller
524
COMP.4.1.14
Electronic Speed
Controller (ESC)_4
HWCI
COMP.4.1.15
Electronic Speed
Controller (ESC)_5
HWCI
COMP.4.1.16
Electronic Speed
Controller (ESC)_6
HWCI
COMP.4.1.17
Electronic Speed
Controller (ESC)_7
HWCI
COMP.4.1.18
Electronic Speed
Controller (ESC)_8
HWCI
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
HWCI
COMP.4.1.19.1
MCCOPM Software
SWCI
COMP.4.1.20
Movement and
Control GPS Unit
(MCGPS)
HWCI
COMP.4.1.21
Propeller_1
Part
COMP.4.1.22
Propeller_2
Part
COMP.4.1.23
Propeller_3
Part
COMP.4.1.24
Propeller_4
Part
COMP.4.1.25
Propeller_5
Part
Function F.4.1.11
Control #4 Motor
Speed
Function F.4.1.14
Control #5 Motor
Speed
Function F.4.1.17
Control #6 Motor
Speed
Function F.4.1.20
Control #7 Motor
Speed
Function F.4.1.23
Control #8 Motor
Speed
Function F.4.1.1
Carry out
Movement and
Control Instructions
Function F.4.1.1.1
Supply MCCOMP
Instructions
Function F.4.1.26
Determine GPS
Location
Function F.4.1.4
Generate #1 Motor
Thrust
Function F.4.1.7
Generate #2 Motor
Thrust
Function F.4.1.10
Generate #3 Motor
Thrust
Function F.4.1.13
Generate #4 Motor
Thrust
Function F.4.1.16
Generate #5 Motor
Thrust
525
COMP.4.1.26
Propeller_6
Part
COMP.4.1.27
Propeller_7
Part
COMP.4.1.28
Propeller_8
Part
Function F.4.1.19
Generate #6 Motor
Thrust
Function F.4.1.22
Generate #7 Motor
Thrust
Function F.4.1.25
Generate #8 Motor
Thrust
Table 8. COMP.4.1 Movement and Control Subsystem Interface Descriptions
Number Name
L.4.1.1
#1 Propeller <->
Environment
L.4.1.2
L.4.1.3
L.4.1.4
L.4.1.5
#2 Propeller <->
Environment
#3 Propeller <->
Environment
#4 Propeller <->
Environment
Barometric Altimeter /
Environment
Transfers
Connects to
Component
COMP.4.1.21
Propeller_1
Component
ENV.4 Environment
Component
COMP.4.1.22
Propeller_2
Component
ENV.4 Environment
Component
COMP.4.1.23
Propeller_3
Component
ENV.4 Environment
Component
COMP.4.1.24
Propeller_4
Item Barometric
Pressure
Component
ENV.4 Environment
Component
COMP.4.1.2
Barometric
Altimeter
526
L.4.1.6
L.4.1.7
L.4.1.8
L.4.1.9
L.4.1.10
L.4.1.11
L.4.1.12
#5 Propeller <->
Environment
#6 Propeller <->
Environment
#7 Propeller <->
Environment
#8 Propeller <->
Environment
EM_#1 -> Prop_#1
EM_#2 -> Prop_#2
EM_#3 -> Prop_#3
Component
ENV.4 Environment
Component
COMP.4.1.25
Propeller_5
Component
ENV.4 Environment
Component
COMP.4.1.26
Propeller_6
Component
ENV.4 Environment
Component
COMP.4.1.27
Propeller_7
Component
ENV.4 Environment
Component
COMP.4.1.28
Propeller_8
Item #1 Propeller
Rotation
Item #2 Propeller
Rotation
Item #3 Propeller
Rotation
Component
ENV.4 Environment
Component
COMP.4.1.3 Electric
Motor (EM)_1
Component
COMP.4.1.21
Propeller_1
Component
COMP.4.1.4 Electric
Motor (EM)_2
Component
COMP.4.1.22
Propeller_2
Component
COMP.4.1.5 Electric
Motor (EM)_3
527
L.4.1.13
L.4.1.14
L.4.1.15
L.4.1.16
L.4.1.17
L.4.1.18
EM_#4 -> Prop_#4
EM_#5 -> Prop_#5
EM_#6 -> Prop_#6
EM_#7 -> Prop_#7
EM_#8 -> Prop_#8
ESC1 -> EM1
Item #4 Propeller
Rotation
Item #5 Propeller
Rotation
Item #6 Propeller
Rotation
Item #7 Propeller
Rotation
Item #8 Propeller
Rotation
Component
COMP.4.1.23
Propeller_3
Component
COMP.4.1.6 Electric
Motor (EM)_4
Component
COMP.4.1.24
Propeller_4
Component
COMP.4.1.7 Electric
Motor (EM)_5
Component
COMP.4.1.25
Propeller_5
Component
COMP.4.1.8 Electric
Motor (EM)_6
Component
COMP.4.1.26
Propeller_6
Component
COMP.4.1.9 Electric
Motor (EM)_7
Component
COMP.4.1.27
Propeller_7
Component
COMP.4.1.10
Electric Motor
(EM)_8
Component
COMP.4.1.28
Propeller_8
Component
COMP.4.1.3 Electric
Motor (EM)_1
528
L.4.1.19
L.4.1.20
L.4.1.21
L.4.1.22
L.4.1.23
ESC2 -> EM2
ESC3 -> EM3
ESC4 -> EM4
ESC5 -> EM5
ESC6 -> EM6
Component
COMP.4.1.11
Electronic Speed
Controller (ESC)_1
Component
COMP.4.1.4 Electric
Motor (EM)_2
Component
COMP.4.1.12
Electronic Speed
Controller (ESC)_2
Component
COMP.4.1.5 Electric
Motor (EM)_3
Component
COMP.4.1.13
Electronic Speed
Controller (ESC)_3
Component
COMP.4.1.6 Electric
Motor (EM)_4
Component
COMP.4.1.14
Electronic Speed
Controller (ESC)_4
Component
COMP.4.1.7 Electric
Motor (EM)_5
Component
COMP.4.1.15
Electronic Speed
Controller (ESC)_5
Component
COMP.4.1.8 Electric
Motor (EM)_6
Component
COMP.4.1.16
Electronic Speed
Controller (ESC)_6
529
L.4.1.24
L.4.1.25
L.4.1.26
L.4.1.27
L.4.1.28
ESC7 -> EM7
ESC8 -> EM8
MMCPU -> ESC_1
MMCPU - > ESC_2
MMCPU - > ESC_3
Item #1 Motor Speed
Item #2 Motor Speed
Item #3 Motor Speed
Component
COMP.4.1.9 Electric
Motor (EM)_7
Component
COMP.4.1.17
Electronic Speed
Controller (ESC)_7
Component
COMP.4.1.10
Electric Motor
(EM)_8
Component
COMP.4.1.18
Electronic Speed
Controller (ESC)_8
Component
COMP.4.1.11
Electronic Speed
Controller (ESC)_1
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.12
Electronic Speed
Controller (ESC)_2
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.13
Electronic Speed
Controller (ESC)_3
Component
COMP.4.1.19
530
L.4.1.29
L.4.1.30
L.4.1.31
L.4.1.32
MMCPU - > ESC_4
MMCPU - > ESC_5
MMCPU - > ESC_6
MMCPU - > ESC_7
Item #4 Motor Speed
Item #5 Motor Speed
Item #6 Motor Speed
Item #7 Motor Speed
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.14
Electronic Speed
Controller (ESC)_4
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.15
Electronic Speed
Controller (ESC)_5
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.16
Electronic Speed
Controller (ESC)_6
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.17
Electronic Speed
Controller (ESC)_7
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
531
L.4.1.33
L.4.1.34
L.4.1.35
L.4.1.36
L.4.1.37
MMCPU - > ESC_8
AHARS -> MCCPU
BARALT - > MCCPU
MCGPS - > MCCPU
PDB -> ESC_1
Item #8 Motor Speed
Item AHRS
Coordinates
Item Digitized
Barometric Pressure
Item MCGPS Data
Item XX Volts DC to
ESC_1
Component
COMP.4.1.18
Electronic Speed
Controller (ESC)_8
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.1
Attitude and
Heading Reference
Systems (AHRS)
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.2
Barometric
Altimeter
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.1.20
Movement and
Control GPS Unit
(MCGPS)
Component
COMP.4.1.11
532
Electronic Speed
Controller (ESC)_1
L.4.1.38
L.4.1.39
L.4.1.40
L.4.1.41
PDB -> ESC_2
PDB-> ESC_3
PDB -> ESC_4
PDB -> ESC_5
Item XX Volts DC to
ESC_2
Item XX Volts DC to
ESC_3
Item XX Volts DC to
ESC_4
Item XX Volts DC to
ESC_5
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.12
Electronic Speed
Controller (ESC)_2
Component
COMP.4.3.1
Power Distribution
Board (PDB)
Component
COMP.4.1.13
Electronic Speed
Controller (ESC)_3
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.14
Electronic Speed
Controller (ESC)_4
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.15
Electronic Speed
Controller (ESC)_5
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
533
L.4.1.42
L.4.1.43
L.4.1.44
L.4.1.45
L.4.1.46
PDB -> ESC_6
PDB -> ESC_7
PDB -> ESC_8
NAV Computer ->

MCCPU
VR -> MCCPU
Item XX Volts DC to
ESC_6
Item XX Volts DC to
ESC_7
Item XX Volts DC to
ESC_8
Item Navigation
Instructions
Item Obstacle Path
Component
COMP.4.1.16
Electronic Speed
Controller (ESC)_6
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.17
Electronic Speed
Controller (ESC)_7
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.18
Electronic Speed
Controller (ESC)_8
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.2.1 NAV
Computer
Component
COMP.4.1.20
Movement and
Control GPS Unit
(MCGPS)
534
L.4.1.47
VR -> BARALT
Component
COMP.4.3.3
Voltage Regulator
Component
COMP.4.1.2
Barometric
Altimeter
Component
COMP.4.3.3
Voltage Regulator
535
COMP.4.2 ARV Navigation Subsystem
Figure 13. COMP4.2 ARV Navigation Subsystem Physical Tree
536
Figure 14. COMP.4.2 ARV Navigation Subsystem Physical Block Diagram

pbd ARV Navigation Subsystem
ENV.7
GPS Satellites
External System
HWCI
nil
Analysis Computer
COMP.4.2.3
NAV RADAR Unit
HWCI
HWCI
(CCR) Command and

Control Radio
HWCI
HWCI
COMP.4.2.1
NAV Computer
Weight Sensor
HWCI
COMP.4.2.4
NAV GPS
HWCI
COMP.1.6
Analysis Radio
COMP.4.4.4
NAV Camera & Image

Processing Unit
(NCIPU)
NAV RADAR UNIT<-> NAV Computer
COMP.4.2.2
COMP.6.2
ENV.9
COMP.6.1
Obstacles
COMP.4.4.3
FOD Camera Unit
HWCI
CCR -> NAV Radio
HWCI
COMP.4.1.19
HWCI
COMP.4.2.5
NAV Radio

Computer (MCCOMP)
COMP.4.4.2
NAV Computer -> VERSABALL System
HWCI
VERSABALL System
HWCI
Date:
December 4, 2015
537
Table 9. COMP.4.2 ARV Navigation Subsystem Functional Traceability Matrix
Number
Name
Type
Performs
COMP.4.2
ARV Navigation Subsystem
Subsystem
Function F.4.2
Navigate Airfield
COMP.4.2.1
NAV Computer
HWCI
COMP.4.2.2
NAV Camera & Image

Processing Unit (NCIPU)
HWCI
Function F.4.2.2
Process Navigation
Commands
Function F.4.2.6
Anticipate
Obstacle
Movement
Function F.4.2.7
Determine Path
Around Obstacles
Function F.4.2.3
Detect Obstacles
COMP.4.2.3
NAV RADAR Unit
HWCI
COMP.4.2.4
NAV GPS
HWCI
COMP.4.2.5
NAV Radio
HWCI
Function F.4.2.4
Determine
Obstacle Location
Function F.4.2.8
Determine Location
Function F.4.2
Navigate Airfield
Function F.4.2.1
Receive Navigation
Commands
Function F.4.2.5
Receive Aircraft
Trajectory Data
from ATC
538
Table 10. COMP.4.2 ARV Navigation Subsystem Interface Descriptions
Number Name
L.4.2.1
L.4.2.2
L.4.2.3
L.4.2.4
L.4.2.5
L.4.2.6
Transfers
Item (Ext)
Obstacle
Identification from
Obstacle
Item (Ext)
Aircraft Location
from Aircraft
Item (Ext)
Obstacle Location
from Obstacle
Item Obstacle
Illumination to
Obstacle
Item Location
Data from GPS
Satellites
Item At FOD
Location Signal
Item At FOD
Location Signal
Item
Coordinates
Connects to
Component
COMP.4.2.2 NAV
Camera & Image
Processing Unit
(NCIPU)
Component
ENV.7 Obstacles
Component
COMP.4.2.3 NAV
RADAR Unit
Component
ENV.7 Obstacles
Component
COMP.4.2.4 NAV
GPS
Component
ENV.9 GPS Satellites
Component
COMP.4.2.4 NAV
GPS
Component
COMP.6.1 Analysis
Computer
Component
COMP.4.2.4 NAV
GPS
Component
COMP.4.4.3 FOD
Camera Unit
Component
COMP.4.2.1 NAV
Computer
539
L.4.2.7
NAV RADAR UNIT<-> NAV

Computer
Item **NAV
RADAR UNIT<->
NAV Computer**
L.4.2.8
Item Obstacle
Characteristics
L.4.2.9
L.4.2.10
L.4.2.11
L.4.2.12

Computer

System
Item Transport to
Disposal Location
Signal
Item At Disposal
Location Signal
Item Navigation
Instructions
Item Obstacle
Path
Item Inbound
Aircraft Trajectory
Component
COMP.4.2.4 NAV
GPS
Component
COMP.4.2.1 NAV
Computer
Component
COMP.4.2.3 NAV
RADAR Unit
Component
COMP.4.2.1 NAV
Computer
Component
COMP.4.2.2 NAV
Camera & Image
Processing Unit
(NCIPU)
Component
COMP.4.2.1 NAV
Computer
Component
COMP.4.4.4 Weight
Sensor
Component
COMP.4.2.1 NAV
Computer
Component
COMP.4.4.2
VERSABALL System
Component
COMP.4.1.19
Movement and
Control Computer
(MCCOMP)
Component
COMP.4.2.1 NAV
Computer
Component
COMP.4.2.1 NAV
Computer
540
Item Navigation
Command
L.4.2.13
L.1.18
CCR -> NAV Radio
Item Inbound
Aircraft Data to
ARV
Item Navigation
Modes
Component
COMP.4.2.5 NAV
Radio
Component
COMP.4.2.5 NAV
Radio
Component
COMP.6.2 Analysis
Radio
Component
COMP.1.6 (CCR)
Command and
Control Radio
Component
COMP.4.2.5 NAV
Radio
541
COMP.4.3 ARV Power Subsystem
Battery, a Power Distribution Board, and a Voltage Regulator.
**The Type of Battery that will be utilized (Nickel Cadmium (NiCd), Nickel-Metal Hydride
(NiMH), Lead Acid, Lithium-Ion (Li-Ion) Lithium-Polymer (LiPo) will be determined in a formal trade
study and submitted as a SM4 deliverable**
Figure 15. COMP.4.3 ARV Power Subsystem Physical Tree
542
Figure 16. COMP.4.3 ARV Power Subsystem Physical Block Diagram

pbd Power Subsystem
COMP.4.2
ARV Navigation
Subsystem
Subsystem
COMP.4.4
VR ->ARV Command and NAV Subsystem
COMP.4.1
Subsystem
Retrieval Subsystem
Subsystem
VR -> Retrieval Subsys...
Movement and
Control Subsystem
VR - > AHRS
COMP.5.5
COMP.4.3.3
Battery Charger
HWCI
Voltage Regulator
BATT -> VR
HWCI
COMP.4.3.2
Battery
COMP.4.1.11
PDB -> ESC_1
BATT -> PDB
COMP.4.1.13
Electronic Speed
Controller (ESC)_3
Electronic Speed
Controller (ESC)_4
HWCI
PDB -> ESC_6
HWCI
Electronic Speed
Controller (ESC)_7
HWCI
COMP.4.1.16
Electronic Speed
Controller (ESC)_6
HWCI
PDB -> ESC_8
COMP.4.1.14
PDB -> ESC_7
PDB -> ESC_4
HWCI
Power Distribution
Board (PDB)
PDB-> ESC_3
HWCI
PDB -> ESC_2
Electronic Speed
Controller (ESC)_5
COMP.4.1.17
COMP.4.3.1
COMP.4.1.12
Electronic Speed
Controller (ESC)_2
PDB -> ESC_5
HWCI
Electronic Speed
Controller (ESC)_1
HWCI
COMP.4.1.15
COMP.4.1.18
Electronic Speed
Controller (ESC)_8
HWCI
HWCI
Date:
December 4, 2015
543
Table 11. COMP.4.3 ARV Power Subsystem Functional Traceability Matrix
Number
Name
Type
Performs
COMP.4.3
Power Subsystem
Subsystem
COMP.4.3.1
Power Distribution Board

(PDB)
HWCI
COMP.4.3.2
Battery
HWCI
COMP.4.3.3
Voltage Regulator
HWCI
Function F.4.3
Provide ARV
Electrical Power
Function F.4.3.9
Provide Power to
ESC_1
Function F.4.3.10
Provide Power to
ESC_2
Function F.4.3.11
Provide Power to
ESC_3
Function F.4.3.12
Provide Power to
ESC_4
Function F.4.3.13
Provide Power to
ESC_5
Function F.4.3.14
Provide Power to
ESC_6
Function F.4.3.15
Provide Power to
ESC_7
Function F.4.3.16
Provide Power to
ESC_8
Function F.4.3.1
Provide Stored
Electricity to ARV
Function F.4.3.2
Regulate NAV
Subsystem Voltage
Function F.4.3.3
Regulate
Movement and
Control Subsystem
Voltage
544
Function F.4.3.4
Regulate Retrieval
Subsystem Voltage
Table 12. COMP.3.2 ARV Power Subsystem Interface Descriptions
Number Name
Transfers
Connects to
L.4.3.1
Item XX Volts DC
Regulated
Movement and
Control Subsystem
Component
COMP.4.1
Movement and
Control Subsystem
L.4.3.2
L.4.3.3
L.4.3.4
L.4.3.5
VR - > AHRS
VR ->ARV Command and NAV

Subsystem
VR -> Retrieval Subsystem
BATT -> VR
BATT -> PDB
Item XX Volts DC
Regulated NAV
Subsystem Voltage
Component
COMP.4.3.3
Voltage Regulator
Component
COMP.4.2 ARV
Navigation
Subsystem
Item XX Volts DC
Regulated Retrieval
Subsystem Voltage
Component
COMP.4.3.3
Voltage Regulator
Component
COMP.4.3.3
Voltage Regulator
Item Electrical
Energy from Battery
Component
COMP.4.4 Retrieval
Subsystem
Component
COMP.4.3.2 Battery
Item Electrical
Energy from Battery
Component
COMP.4.3.3
Voltage Regulator
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.3.2 Battery
545
L.4.3.6
L.4.3.7
L.4.3.8
L.4.3.9
L.4.3.10
PDB -> ESC_1
PDB -> ESC_2
PDB-> ESC_3
PDB -> ESC_4
PDB -> ESC_8
Item XX Volts DC
to ESC_1
Item XX Volts DC
to ESC_2
Item XX Volts DC
to ESC_3
Item XX Volts DC
to ESC_4
Item XX Volts DC
to ESC_8
Component
COMP.4.1.11
Electronic Speed
Controller (ESC)_1
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.12
Electronic Speed
Controller (ESC)_2
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.13
Electronic Speed
Controller (ESC)_3
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.14
Electronic Speed
Controller (ESC)_4
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.18
Electronic Speed
Controller (ESC)_8
Component
COMP.4.3.1 Power
546
L.4.3.11
L.4.3.12
L.4.3.13
L.5.5.1
PDB -> ESC_6
PDB -> ESC_7
PDB -> ESC_5
Item XX Volts DC
to ESC_6
Item XX Volts DC
to ESC_7
Item XX Volts DC
to ESC_5
Item Electrical
Energy from
Charger
Distribution Board
(PDB)
Component
COMP.4.1.16
Electronic Speed
Controller (ESC)_6
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.17
Electronic Speed
Controller (ESC)_7
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.1.15
Electronic Speed
Controller (ESC)_5
Component
COMP.4.3.1 Power
Distribution Board
(PDB)
Component
COMP.4.3.2 Battery
Component
COMP.5.5 Battery
Charger
547
COMP.4.4 ARV Retrieval Subsystem
ARV to perform the Grasp FOD and Release FOD Functions. In order to perform
these functions, the camera unit will allow the ARV to maneuver to the precise location
of the FOD, while the Weight Sensor and Telemetry Radio will weigh and notify
personnel of FOD that cannot be retrieved due to its weight.
**The Versaball Gripper is a COTS component that was selected to perform the as the result of
an informal trade study**
Figure 18. COMP.4.4 ARV Retrieval Subsystem Physical Tree
548
Figure 19. COMP.4.4 ARV Retrieval Subsystem Physical Block Diagram

pbd Retrieval Subsystem
COMP.1.6
(CCR) Command and

Control Radio
HWCI
COMP.4.4.4
Weight Sensor
Weight Sensor -> Retrieval Telemetry Radio
COMP.4.2.4
NAV GPS
ENV.5
HWCI
FOD
VERSABALL System <->

FOD
External System
Weight Sensor <-> VERSABALL System
HWCI
COMP.4.4.1
COMP.4.2.1
HWCI
HWCI
NAV Computer
HWCI
COMP.4.4.2
VERSABALL System
Retrieval Telemetry
Radio
COMP.4.4.3
FOD Camera Unit
FOD Camera Unit -> Retrieval Telemetry Radio
NAV Computer -> VERSABALL Sys...
HWCI
Date:
December 4, 2015
549
Table 13. COMP.4.4 Retrieval Subsystem Functional Traceability Matrix
Number
Name
Type
Performs
COMP.4.4
Retrieval Subsystem
Subsystem
COMP.4.4.1
Retrieval Telemetry Radio
HWCI
COMP.4.4.2
VERSABALL System
HWCI
COMP.4.4.3
FOD Camera Unit
HWCI
COMP.4.4.4
Weight Sensor
HWCI
Function F.4.4
Retrieve FOD
Function F.4.4.3
Notify Personnel of
Object too Large
for Retrieval
Function F.4.4.6
Notify Personnel of
Overweight
Objects
Function F.4.4.4
Grasp FOD
Function F.4.4.7
Release FOD
Function F.4.4.1
Determine FOD
Characteristics
Function F.4.4.5
Determine FOD
weight
Table 14. COMP.4.4 Retrieval Subsystem Interface Descriptions
Number
Name
Transfers
Connects to
L.4.4.1

Computer
Item Transport to
Disposal Location
Signal
Component
COMP.4.2.1 NAV
Computer
L.4.4.2
Weight Sensor -> Retrieval

Telemetry Radio
Item Overweight
Signal
Component
COMP.4.4.4 Weight
Sensor
Component
COMP.4.4.1
Retrieval Telemetry
Radio
550
L.4.4.3
L.4.4.4
L.4.4.5
L.4.4.6
L.4.4.7
L.4.2.5
Weight Sensor <-> VERSABALL

System
VERSABALL System <-> FOD
FOD Camera Unit -> Retrieval

Telemetry Radio
Retrieval Telemetry Radio ->

CCR
Item Grasped
FOD's Weight
Item FOD
Item FOD
Identification from
FOD
Item FOD too

Large Signal
Item Unsuitable
FOD Location Data
Item At FOD
Location Signal
Component
COMP.4.4.4 Weight
Sensor
Component
COMP.4.4.2
VERSABALL System
Component
COMP.4.4.4 Weight
Sensor
Component
COMP.4.4.2
VERSABALL System
Component
ENV.5 FOD
Component
COMP.4.4.3 FOD
Camera Unit
Component
ENV.5 FOD
Component
COMP.4.4.1
Retrieval Telemetry
Radio
Component
COMP.4.4.3 FOD
Camera Unit
Component
COMP.1.6 (CCR)
Command and
Control Radio
Component
COMP.4.4.1
Retrieval Telemetry
Radio
Component
COMP.4.2.4 NAV
GPS
551
L.4.2.10

System
Item At Disposal
Location Signal
Component
COMP.4.4.3 FOD
Camera Unit
Component
COMP.4.2.1 NAV
Computer
Component
COMP.4.4.2
VERSABALL System
552
553
Figure 21. COMP.5 Power and Housing Segment Physical Tree
Figure 22. COMP.5 Power and Housing Physical Block Diagram

pbd Power and AV Housing Segment
ENV.8
Power
External System
COMP.6

COMP.1
HWCI
Command and
Control Segment
Segment
Power - > FOD Analysis Segment
COMP.3
Detection Segment
(EXT) Environment - > AV Housing Unit
Power -> Command and Control Segment
External System
COMP.5.1
Power Transfer Panel
HWCI
HWCI
COMP.5.3
HWCI
Power Transfer Panel - > AV Housing Unit
Generator
Generator -> Power Transfer Panel
HWCI
COMP.5.6
COMP.5.4
AV Housing Unit
Transfer Switch
Environment
COMP.5.2
Transfer Switch - > Power Transfer Panel
ENV.4
Segment
AV Housing Unit -> Charging Receptacle
Charging Receptacle
HWCI
COMP.4.3.2
COMP.5.5
Charging Receptacle -> Battery Char...
Battery Charger
HWCI
Date:
Battery
HWCI
December 4, 2015
554
Table 15. COMP.5 Power and Housing Segment Functional Traceability Matrix
Number
Name
Type
Performs
COMP.5
Power and AV
Housing Segment
Subsystem
COMP.5.1
HWCI
COMP.5.2
Power Transfer
Panel
Transfer Switch
COMP.5.3
Generator
HWCI
COMP.5.4
AV Housing Unit
HWCI
COMP.5.5
Battery Charger
HWCI
COMP.5.6
Charging
Receptacle
HWCI
Function F.5
Provide AV Housing
and System Power
Function F.5.4
Transfer Power
Function F.5.1
Accept External
Power
Function F.5.2
Detect External
Power Failure
Function F.5.3
Generate
Emergency Power
Function F.5.5
Provide Air Vehicle
Housing
Function F.5.6
Secure AV
Function F.5.8
Recharge Air
Vehicle
Function F.5.7
Make Charging
Connection
HWCI
Table 16. COMP.5 Power and Housing Segment Interface Descriptions
Number
Name
Transfers
Connects to
L.5.1
(EXT) Environment - > AV

Housing Unit
Item (Ext) Rain

Item (Ext) Snow
Item (Ext) Wind
Component
COMP.5.4 AV
Housing Unit
Item Electricity
Component
ENV.4 Environment
Component
COMP.5.1 Power
Transfer Panel
L.5.2
Power Transfer Panel - > AV

Housing Unit
555
L.5.3
L.5.4
L.5.5
L.5.6
L.5.7
L.5.8
Power -> Command and

Control Segment
Power - > FOD Analysis

Segment
Transfer Switch - > Power

Transfer Panel
Generator -> Power Transfer

Panel
Charging Receptacle ->

Battery Charger
Item Electricity
Item Electricity
Item Electricity
Item Electricity
Item Generator
Power
Item Electricity
Component
COMP.5.4 AV
Housing Unit
Component
COMP.3 Detection
Segment
Component
COMP.5.1 Power
Transfer Panel
Component
COMP.1 Command
and Control
Segment
Component
COMP.5.1 Power
Transfer Panel
Component
COMP.5.1 Power
Transfer Panel
Component
COMP.6 FOD
Analysis Segment
Component
COMP.5.1 Power
Transfer Panel
Component
COMP.5.2 Transfer
Switch
Component
COMP.5.1 Power
Transfer Panel
Component
COMP.5.3
Generator
Component
COMP.5.5 Battery
Charger
556
L.5.9
L.5.10
L.5.11
L.5.12
AV Housing Unit -> Charging

Receptacle
Item (Ext)
Electrical Energy
from Power
Component
COMP.5.6
Charging
Receptacle
Component
COMP.5.2 Transfer
Switch
Item Power
Failure Signal from
Power
Component
ENV.8 Power
Component
COMP.5.2 Transfer
Switch
Item Electrical
Energy from
Charger
Item Electrical
Energy from
Charger
Component
COMP.5.3
Generator
Component
COMP.4.3.2 Battery
Component
COMP.5.5 Battery
Charger
Component
COMP.5.4 AV
Housing Unit
Component
COMP.5.6
Charging
Receptacle
557
Figure 23. COMP.6 FOD Analysis Segment Physical Tree
Figure 24. COMP.6 Power and Housing Segment Physical Block Diagram
558
pbd FOD Analysis Segment
IFerret TM &
AFDIRTS Interface
Unit
COMP.4.2.5
COMP.4.2.4
NAV Radio
HWCI
Subsystem
COMP.1.1
NAV GPS
Airport Management
Display Unit (AMDU)
HWCI
Subsystem
COMP.6.2
COMP.6.1
COMP.3.1
Analysis Radio
Analysis Computer
HWCI
HWCI
Analysis Radio -> Analysis Computer

Date:
December 4, 2015
Table17. COMP.6 FOD Analysis Segment Functional Traceability Matrix
Number
Name
Type
Performs
COMP.6
HWCI
COMP.6.1
Analysis Computer
HWCI
Function F.6
Analyze FOD Trends
Function F.6.2
Perform Trend
Analysis
Function F.6.3
Retain Data
Function F.6.4
Export FOD Reports
559
COMP.6.1.1
Analysis Software
SWCI
COMP.6.2
Analysis Radio
HWCI
Function Carry
Out Operating
Instructions
Function F.6.1
Accept FOD alert
time and date,
location
coordinates and
FOD image data
Table 18. COMP.6 Analysis Segment Interface Descriptions
Number Name
Transfers
Connects to
L.1.13
Item Reports to
Airport Managers
Component
COMP.1.1 Airport
Management
Display Unit (AMDU)
L.3.2
L.4.2.4
L.4.2.13

Item FOD
Characteristics
Item Suitability
Data
Item At FOD
Location Signal
Item FOD Data
Component
COMP.6.1 Analysis
Computer
Component
COMP.3.1 IFerret
TM & AFDIRTS
Interface Unit
Component
COMP.6.2 Analysis
Radio
Component
COMP.4.2.4 NAV
GPS
Component
COMP.6.1 Analysis
Computer
Component
COMP.4.2.5 NAV
Radio
Component
COMP.6.2 Analysis
Radio
560
L.6.1

Computer
Item Raw FOD

Data
Component
COMP.6.1 Analysis
Computer
Component
COMP.6.2 Analysis
Radio
561
Appendix E
AFDIRTS Trade Study Report
562
Table of Contents
Overview... 564
Battery Alternatives . 565
Nickel Cadmium (NiCd).. 565
Nickel-Metal Hydride (NiMH).. 566
Lead Acid 567
Lithium-ion (Li-Ion).
568
Lithium-Polymer (LiPo).. 569

Selection Criteria.... 570
Gravimetric Energy Density (Wh/kg) 570
Fast Charge Time 571
Maintenance Requirement. 571
Operating Temperature (discharge only) 571
Weightings.. 572
Utility Functions.. 574
Rankings. 578
Sensitivity Analysis. 580
Selection with rational 581
References.. 582
563
Overview
This trade study was performed to make certain that the best type of battery was
selected for the Air Retrieval Vehicle (ARV) Subsystem. The battery criteria selected for
this study was based upon the characteristics ability to help best meet AFDIRTS
requirements. The selection criteria were battery gravimetric energy density (Wh/kg),
Fast Charge Time, Maintenance Requirements, and Operating Temperature Range.
While cost was not calculated into operational utility functions, cost was a factor for
selection and taken into consideration upon ARV battery type selection.
564

The NiCd battery was the preferred choice for industrial electronics for many years.
Then in the late 1980s the ultra-high-capacity NiCd was released that gave industry a
battery that was able to hold a 60 percent higher charge than the standard NiCd
battery (Battery University, 2015). The tradeoff for this higher capacity was higher
internal resistance and a reduced cycle count (Battery University, 2015). The standard
NiCd is one of the most rugged and forgiving batteries to this day; however, it needs
appropriate maintenance to achieve a long life (Battery University, 2015). NiCd
batteries have a memory effect that causes a capacity reduction over time if the
battery is not given a full discharge cycle periodically (Battery University, 2015).
Table 1. Nickel Cadmium (NiCd) battery specifications.
Nickel Cadmium (NiCd) Battery Specifications

Internal Resistance
Fast Charge Time
Load Current Peak
Cost per Cycle(US$)
45-80
100 to 200 (6V pack)
1500
1h typical
moderate
20%
1.25V6
20C
1C
-40 to 60C
30 to 60 days
$50
(7.2V)
$0.04
1950
565
The Nickel-Metal Hydride (NiMH) battery was improved in the 1980s when new hydride
alloys improved past stability issues (Battery University, 2015). Today the NiMH battery
provides 40 percent higher specific energy than the standard NiCd with the absence of
toxic metals. The NiMH battery does have its disadvantages (Battery University, 2015). It
is more delicate and complicated to charge than NiCd batteries; additionally the
battery self-discharges 20 percent or more in the first 24 hours after charge (Battery
University, 2015). The NiMH battery is one of the lowest costing and most readily
available and batteries for portable devices (Battery University, 2015).
Table 2. Nickel-Metal Hydride (NiMH) battery specifications.
Nickel-Metal Hydride (NiMH) Battery Specifications

Internal Resistance
Fast Charge Time
Load Current Peak
Cost per Cycle(US$)
60-120
200 to 300 (6V pack)
300 to 500
2-4h
low
30%
1.25V6
5C
0.5C or lower
-20 to 60C
60 to 90 days
$60
(7.2V)
$0.12
1990
566
Lead Acid
Lead acid batteries are heavy and is less durable than nickel- and lithium-based
systems when deep-cycled (Battery University, 2015). When the battery is fully
discharged, it causes strain on the battery and subsequently robs the battery of a small
amount of storage capacity (Battery University, 2015). While this loss is small, the weardown characteristic eventually effects the battery that its performance drops to half
the nominal capacity. Depending this depth of discharge, lead acid for deep-cycle
applications provides 200 to 300 discharge/charge cycles (Battery University, 2015).
Lead acid batteries do not charge fast. Most types can take, a full charge can take 8
to16 hours to receive a full charge. Additionally, Lead Acid batteries must always be
stored at full state-of-charge.
Table 3. Lead Acid battery specification
Lead Acid Battery Specifications

Internal Resistance
Fast Charge Time
Load Current Peak
Cost per Cycle(US$)
30-50
<100 (12V pack)
200 to 300
8-16h
high
5%
2V
5C
0.2C
-20 to 60C
3 to 6 months
$25
(6V)
$0.10
1970
567
Lithium is the lightest of all metals and as such it provides the greatest electrochemical
potential providing the greatest specific energy per weight (Battery University, 2015).
However, it was discovered that cycling had the potential to causing thermal runaway
in the battery released flaming gases potentially causing fires or inflicting burns (Battery
University, 2015). This inherent instability, especially while charging, forced researchers to
search for a non-metallic solution (Battery University, 2015). This solution came by utilizing
lithium ions and while lower in specific energy than lithium-metal, Li ion proved to be a
safer alternative (Battery University, 2015). Today the Lithium-ion battery is the most
promising and fastest growing battery on the market (Battery University, 2015). In
addition, Li-ion is a low-maintenance battery, has no memory and does not need to be
fully discharged to maintain good health (Battery University, 2015).
Table 4. Lithium-ion (Li-ion) Battery Specifications
Lithium-ion (Li-ion) Battery Specifications

Internal Resistance
Fast Charge Time
Load Current Peak
Cost per Cycle(US$)
110-160
150 to 250 (7.2V pack)
500 to 1000
2-4h
very low
10%
3.6V
>2C
1C or lower
-20 to 60C
not req.
$100
(7.2V)
$0.14
1991
568
Lithium-Polymer (LiPo)
Lithium polymer batteries are similar to lithium-ion batteries (Battery University, 2015).
Both use the same cathode and anode material and consist of a similar amount of
electrolyte (Battery University, 2015). Lithium polymer is distinctive from lithium-ion in that
a micro porous electrolyte replaces the traditional porous separator (Battery University,
2015). Lithium polymer batteries have a higher specific energy (only slightly) but can be
made thinner than conventional lithium-ion cells (Battery University, 2015). Lithium
polymer cells and can be made into a flexible foil-type case, while lithium-ion batteries
need a rigid case to press their electrodes together (Battery University, 2015). This type
of rigid case can increase battery weight by 25% (Battery University, 2015). In addition to
being lighter Lithium-Polymer batteries can be made into any shape including
extremely slim designs resembling a credit card (Battery University, 2015).
Table 5. Lithium-Polymer (LiPo) Battery Specifications
Lithium-Polymer (LiPo) Battery Specifications

Internal Resistance
Fast Charge Time
Load Current Peak
Cost per Cycle(US$)
Data retrieved from (Battery University, 2015
100-130
200 to 300 (7.2V pack)
300 to 500
2-4h
low
~10%
3.6V
>2C
1C or lower
0 to 60C
not req.
$100
(7.2V)
$0.29
1999
569
Selection Criteria
Selection criteria for the Air Retrieval Vehicle battery type was based upon the
characteristics ability to better meet AFDIRTS system performance requirements. The
selection criteria, and their relation to system requirements have been discussed in
further detail below.
Table 6. Battery Alternatives Selection Criteria Values
Gravimetric Energy
Density(Wh/kg)
Fast Charge Time
Nickel
Cadmium
(NiCd)
Nickel-Metal
Hydride
(NiMH)
Lead Acid
Lithium-ion
LiPo
(LithiumPolymer)
62.5
90
40
135
115
Maintenance
Requirement
1h
3h
12H
3H
2.5h
45 days
75 days
135 Days
Operating
Temperature
Range
100 C
80 C
80 C
80 C
60 C

Also known as Specific Energy, defines the batteries capacity in terms of Watt Hour per
Kilogram. A lower weight battery per watt hour is advantageous to the Air Retrieval
Vehicle in many ways. A higher What Hour to Kilogram battery capacity ratio could
help attain many performance requirements. First, and foremost high specific energy
would allow the vehicle to utilize this extra lifting capacity to help achieve requirement
R.5.2 The system shall be capable of retrieving FOD weighing up to 1 pound or
.45359237 kilograms However, the higher specific energy could also be utilized to
enable the ARV to carry more robust and heavier subsystem components.
570
Selection Criteria
Fast Charge Time

The longer it takes the ARV to charge the more time Air Retrieval Vehicles are
unavailable for FOD retrieval and disposal. This can have an adverse impact on
requirement R.11 The system should have an Operational Availability (AO) of 99.9%
Not only does more maintenance increase Operations & Maintenance (O&M) Costs;
but it decreases the amount of time the system is available again adversely affecting
R.11 Operational Availability.

While the system is only required to meet weather conditions for airfields local region as
specified in CLIM 20, Climatology of the United States No. 20 (as per requirement R.12
Operate in Adverse Weather Conditions) it is advantageous for the batteries to have a
large temperature range so that they may operate in a broad range of locations.
571
Weightings
The Analytical Hierarchy Process was utilized to develop weightings for selection criteria.
A pairwise comparison was performed on the battery criteria listed above and has
been listed in the chart below.
Table 7. Numerical criteria importance values
1 Means that criteria A and B are equally Important

3 means that A is thought to be moderately more important than B
5 means that A is thought to be strongly More important than B
7 means that A is thought to be, or has been demonstrated to be, much more
important than B
9 means A has been demonstrated to have much more importance than B
Table 8. Pairwise Comparison Chart
Gravimetric
Energy Density
(Wh/kg)
Operating
Temperature
Range
Fast Charge
Time
Maintenance
Requirement
Criteria Comparison Matrix
0.33333
0.2
0.33333
0.11111
0.2
0.33333
Sum
1.64444
4.53333
9.33333
18

Fast Charge Time
572
Weightings
Table 9. Normalized Criteria Comparison Matrix
Gravimetric
Energy Density
(Wh/kg)
Operating
Temperature
Range
Fast Charge
Time
Maintenance
Requirement
Normalized Criteria Comparison Matrix
0.60811
0.66176
0.53571
0.5
0.2027
0.22059
0.32143
0.27778
Fast Charge Time
0.12162
0.07353
0.10714
0.16667
0.06757
0.04412
0.03571
0.05556
Sum
Table 10. Normalized Criteria Comparison Matrix with Weights
Operating
Temperature
Range
Fast Charge
Time
0.60811
0.66176
0.53571
0.5
0.5763968
0.2027
0.22059
0.32143
0.27778
0.2556238
Fast Charge Time
0.12162
0.07353
0.10714
0.16667
0.11724
0.06757
0.04412
0.03571
0.05556
0.0507385
Gravimetric Energy
Density(Wh/kg)
Operating Temperature
Range
Sum
Maintenance
Requirement
Gravimetric
Energy Density
(Wh/kg)
Normalized Criteria Comparison Matrix with Weights
Criteria Weights
(W)
573
Utility Functions
Table 11. Gravimetric Energy Density Utility Function Curve
Table 12. Gravimetric Energy Density Utility Values
Gravimetric Energy Density Utility Values

Nickel
Nickel-Metal Lead Acid
LithiumCadmium
Hydride
ion
(NiCd)
(NiMH)
LiPo
(LithiumPolymer)
Gravimetric Energy
Density(Wh/kg)
62.5
90
40
135
115
Utility Value
0.462
0.666
0.296
0.851
574
Utility Functions
Table 13. Operating Temperature Range Utility Function Curve
Table 14. Operating Temperature Range Utility Values
Operating Temperature Range Utility Values

Nickel
Cadmium
(NiCd)
Nickel-Metal
Hydride
(NiMH)
Lead Acid
Lithiumion
LiPo
(LithiumPolymer)
Operating
Temperature
Range C
100 C
80 C
80 C
80 C
60 C
Utility Value
.8
.8
.8
.6
575
Utility Functions
Table 15. Fast Charge Time Utility Function Curve
Table 16. Fast Charge Time Utility Values
Fast Charge Time Utility Values

Nickel
Cadmium
(NiCd)
Fast Charge Time
Utility Value
Nickel-Metal
Hydride
(NiMH)
Lead Acid
Lithiumion
LiPo
(LithiumPolymer)
1 Hour
3 Hour
12 Hour
3 Hour
2.5 Hour
.833
.0833
.833
.875
576
Utility Functions
Table 17. Maintenance Requirement Utility Function Curve
Table 18. Maintenance Requirement Utility Values
Maintenance Requirement Utility Values

Nickel
Cadmium
(NiCd)
Nickel-Metal
Hydride (NiMH)
Lead Acid
Lithiumion
LiPo
(LithiumPolymer)
Maintenance
Requirement
(in Days)
45
75
135
Utility Value
.3
.5
.9
577
Rankings
(NiMH)
Lead Acid
Table 19. Weighted Utility Score Matrix
0.576
0.266112
0.3836
0.1705
0.576
0.49
0.255
0.255
0.204
0.204
0.204
0.153
0.117
0.117
0.0975
0.00975
0.097
0.102
0.0507
0.01521
0.0254
0.04563
0.051
0.051
Weighted SUM
0.653322
0.7105
0.42988
0.928
0.796
Cost Per Cycle
$0.04
$0.12
$0.10
$0.14
$0.29
Weighted Utility
Scores
Weight
Gravimetric Energy
Density(Wh/kg)
Operating
Temperature Range
Fast Charge Time
Maintenance
Requirement

Lead Acid
$0.04
$0.12
$0.1
$0.14
$0.29
function/Cost Per Cycle)
0.65332
0.71043
0.42987
0.92816
0.79625
Cost Effectiveness
Function (Operational Utility
Cost Per Cycle
Effectiveness Matrix
Operational Utility
Function
Table 20. Effectiveness Scores
16.3331
5.92023
4.29872
6.62972
2.74569
578
Rankings
Table 21. Effectiveness Rankings
Effectiveness Rankings
1 Lithium-ion (Li-ion)
2
3
4
5
Cost Effectiveness Rankings

0.9282
0.7963
0.7104
0.6533
Lead Acid
0.4299
1
2
3
5
4
Nickel Cadmium
(NiCd)
16.3331
6.62972
(NiMH)
5.92023
Lead Acid
4.29872
LiPo (LithiumPolymer)
2.74569
579
Sensitivity Analysis
Gravimetric Energy
Density(Wh/kg)
Operating
Temperature Range
Fast Charge Time
Maintenance
Requirement
Lead Acid
(NiMH)
Utility Scores
Varied by 10%
0.508
0.733
0.325
1.1
0.936
1.1
0.88
0.88
0.88
0.66
0.833
0.0833
0.833
0.875
0.3
0.5
0.9
Maintenance
Requirement
Varied Weighted SUM
Original Weighted Sum
Lead Acid
Fast Charge Time
(NiMH)
0.576
0.292608
0.422208
0.1872
0.6336
0.53914
0.255
0.2805
0.2244
0.2244
0.2244
0.1683
0.117
0.117
0.097461
0.0097461
0.097461
0.10238
0.0507
0.01521
0.02535
0.04563
0.0507
0.0507
0.705318
0.769419
0.4669761
1.006161
0.86051
0.653322
0.710427
0.4298721
0.928161
0.79625
Weighted Utility Scores

Sensitivity Check
Gravimetric Energy
Density(Wh/kg)
Operating
Temperature Range
Weight
580
Selection
The Lithium-ion (Li-ion) battery ranked the highest in effectiveness and second in cost
effectiveness. The lithium-ion battery has the highest power output per kilogram, the
second greatest in operational temperature Range -20 to 60C (-4 to 140F) and
requires zero maintenance. In addition, the Lithium-ion (Li-ion) battery ranked second in
cost effectiveness with an operating cost of 0.14 cents per cycle and has a cycle life
between 500 and1000 cycles.
A sensitivity analysis was performed by varying Gravimetric Energy Density (Wh/kg) and
Operating Temperature Range; the results did not change. The Lithium-ion (Li-ion)
battery is recommended as the battery to provide power to the ARV.
581
References
Battery University. (2015, December). Learn About Batteries. Retrieved from Battery
University: http://batteryuniversity.com/learn/article/whats_the_best_battery
582
Appendix F
583
Table of Contents
Introduction
586
System Description
587
Summary of Requirements
590
Key Performance Parameters (KPP)
592
AFDIRTS System 593

AFDIRTS System Requirements 593
AFDIRTS System Requirement Origin Map 596
AFDIRTS External Interface Specifications. 597
COMP.1 Command and Control Segment.............................. 599
Command and Control Segment Requirements 599
Command and Control Segment Requirement Origin Map 600
Command and Control Subsystem Specifications .. 601
Command and Control Internal Interfaces. 603
COMP.2 System Health and Monitoring Segment
604
System Health and Monitoring Segment Requirements 604

System Health and Monitoring Segment Requirement Origin Map 605
System Health and Monitoring Subsystem Specifications . 606
System Health and Monitoring Internal Interfaces .. 608
COMP.3 FOD Detection Segment.. 609
FOD Detection Segment Requirements 609
FOD Detection Segment Requirement Origin Map 611
FOD Detection Subsystem Specifications ....
612
FOD Detection Subsystem Internal Interfaces .. 612

COMP.4 Air Retrieval Vehicle (ARV).. 613
ARV Segment Requirements .. 613
ARV Segment Requirement Origin Map.. 614
ARV Subsystem Specifications .. 615
COMP.4.1 ARV Movement and Control Subsystem
617
ARV Movement and Control Subsystem Requirements .. 617

ARV Movement and Control Subsystem Requirement Origin Map... 617
584
ARV Movement and Control Subsystem Specifications..
618
ARV Movement and Control Subsystem Internal Interfaces. 620

COMP4.2 ARV Navigation Subsystem.. 621
ARV Navigation Subsystem Requirements ... 622
ARV Navigation Subsystem Requirement Origin Map... ....... 622
ARV Navigation Subsystem Specifications... 623
ARV Navigation Subsystem Internal Interfaces. 625
COMP.4.3 ARV Power Subsystem.. 626
ARV Power Subsystem Requirements . 626
ARV Power Subsystem Requirement Origin Map. ....... 626
ARV Power Subsystem Specifications.. 627
ARV Power Subsystem Internal Interfaces... 628
COMP.4.3 ARV Retrieval (Gripping) Subsystem.
629
ARV Retrieval Subsystem Requirements . 629

ARV Retrieval Subsystem Requirement Origin Map........ 630
ARV Retrieval Subsystem Specifications 631
ARV Retrieval Subsystem Internal Interfaces.. 632
633
ARV Power and Housing Segment Requirements. 633

ARV Power and Housing Segment Requirement Origin Map........ 634
ARV Power and Housing Segment Specifications 634
ARV Power and Housing Internal Interfaces 635
COMP.6 FOD Analysis Segment... 636
FOD Analysis Segment Requirements .. 636
FOD Analysis Segment Requirement Origin Map........................ 637
FOD Analysis Segment Specifications .. 637
FOD Analysis Segment Internal Interfaces 638
585
Introduction
The A-Spec is a result of Concept Development Stage of the Systems Engineering

method. It is meant to be utilized by a developer as an input to the Engineering
Development Stage. Due to resource constraints, this project does not go into the
depth necessary of a real-world project. Additionally, specifications for all AFDIRTS
interfaces have not been listed. Interfaces listed in this report are 2 external interfaces
and an internal interface for each subsystem/segment (11 total).
The Requirements Analysis Report (RAR) was completed after the Concept Exploration
phase. At that time, the requirements document contained 77 requirements. After the
completion of the Concept Definition phase, the A-Spec grew 62% to 124 requirements.
586
System Description
The AFDIRTS consists of six major segments; The Command and Control Segment, the
System Health and Monitoring Segment, the FOD Detection Segment, the Air Retrieval
Vehicle (ARV), the Power and Housing Segment and the FOD analysis segment.
The Command and Control Segment is made up of 7 Hardware Configuration Items
(HWCI) and 1 Software Configuration Item (SWCI) integrated to perform function F.1
Command and Control the System. In addition to command and control the Segment
allows users to interface with the AFDIRTS.
The Air Retrieval Vehicle (ARV) (shown below in figure 1) is designed to transport the
Retrieval Subsystem System to the FODs location on the airfield and grasp it with a COTS
gripper. The ARV consists of four Subsystems; the Movement and Control Subsystem, the
Navigation Subsystem, ARV Power Subsystem, and the Retrieval Subsystem.
587
System Description
The ARV Movement and Control Subsystem has been designed to facilitate movement
and stability of the ARV while maneuvering to waypoints. It consists of an Attitude and
Heading Reference System (AHARS), Barometric Altimeter, GPS Unit, Movement and
Control Computer, 8 Propellers, 8 Electric Motors and 8 Electronic Speed Controllers.
Lithium-Ion Battery, a Power Distribution Board, and a Voltage Regulator.
ARV to perform the Grasp FOD and Release FOD Functions. It utilizes the COTS
VERSABALL Gripper manufactured by Empire Robotics and shown below in figure 2. To
perform these functions, the camera unit will allow the ARV to maneuver to the precise
location of the FOD, while the Weight Sensor and Telemetry Radio will weigh and notify
personnel of FOD that cannot be retrieved due to its weight of physical characteristics.
588
System Description
589
Table 1. Requirements
Type
Number
Composite
Functional
18
Performance
93
Programmatic
Total
124
Figure 1. Requirements Pie Chart
Programmatic, 7
Composite, 6
Functional, 18
Performance, 93
590
Table 2. Quantitative vs Qualitative
Type
Number
Qualitative
Binary
19
Quantitative
96
Total
124
Figure 2. Requirement Type Pie Chart
Qualitative
7%
Binary
15%
Quantitative
78%
591
Key Performance Parameters
R.3.1 ATC Emergency Control

Air Traffic Control shall be capable of initiating an emergency mode of
operation that removes all Air Retrieval Vehicles from airfield operating
R.2.1 Power Failure
In the event of a power failure, the AFDIRTS system must have the
capability to automatically power-up and operate in the condition and
settings that were available just prior to the power failure.
R.5.4.3 FOD Max Weight
The AFDIRTS system shall be capable of retrieving FOD weighing up to 1
pound (.453 kilograms)
Air Retrieval Vehicles shall be capable of retrieving FOD with dimensions
of up to 12 inches in length 12 Inches in width and 12 inches in height.
The AFDIRTS system shall be capable of detecting, anticipating movement
and avoiding all airport traffic without input from air traffic control.
592
AFDIRTS Summary of Requirements
Table 3. AFDIRTS System Requirements

Number Name
Type
Description
Metric
Verified By
R.1.1
Reliability
Composite

its intended functions with a reliability of 99.0%
over its total life The total life of the AFDIRTS
system shall be a minimum of 20 years (excluding
consumable parts).
Quantitative
Analysis
R.1.2
System Availability
Performance
The AFDIRTS System should have an Operational

Availability (AO) of 99.7% over its 20 Year life.
Quantitative
Analysis
R.1.3
System
Maintainability
Performance

its intended functions for its total life (20 Years)
when maintained according to the
manufacturers instructions.
Quantitative
Analysis
R.1.4
Electromagnetic
Interference
Performance
The AFDIRTS must meet the current issues of radio

suppression specification MIL-STD-461, Class 3D,
Interference Emissions and Susceptibility. It must
range of 75 MHz 136 MHzs.
Quantitative
Test
R.1.5
Equipment Located
Outside of Paved
Surfaces
Programmatic
AFDIRTS equipment located outside of paved

surfaces shall be designed and built so
maintenance personnel can still access them.
Binary
Demonstration
593
Number Name
Type
Description
Metric
Verified By
R.1.6
Installation and
Acceptance
Standards
Composite
The AFDIRTS system shall conform to applicable

airport obstruction criteria, marking and lighting,
and equipment design and installation standards.
Binary
Inspection
R.1.7
Breakaway
Connector
Constraint
AFDIRTS elements located near the runway and

within the runway safety area shall be connected
through a connector that will disconnect upon
impact with the system.
Binary
Inspection
R.1.8
Wind Loading
Constraint
AFDIRTS elements located near the runway shall

withstand a wind loading of 300 mph. (483 km/h)
Quantitative
Test
R.1.9
Performance in
Rain
Performance

objects under rainfall conditions having a specific
20).
Quantitative
Test
R.1.10
Performance in
Snow
Performance

objects under snow conditions having a specific
20).
Quantitative
Test
R.1.11
Performance in
Wind
Performance
The AFDIRTS shall be capable of operating in

wind conditions up to 25 MPH with gusts up to
30MPH.
Quantitative
Test
R.1.12
Maintenance
Procedures
Programmatic
An operators handbook, illustrated parts

breakdown and preventive maintenance
schedule shall be developed and included with
the AFDIRTS system.
Quantitative
Analysis
594
Number Name
Type
Description
Metric
Verified By
R.1.13
Cleaning
Procedures
Programmatic

cleaning procedures, including solvent types and
tools shall be developed.
Qualitative
Analysis
R.1.14
Preventative
Maintenance
Procedures
Programmatic

preventive maintenance actions shall be
developed.
Qualitative
Analysis
R.1.15
Recalibration Plan
Programmatic
Written calibration and recalibration procedures

shall be developed so that FOD detection and
retrieval performance specifications can be
maintained for 20 Years.
Quantitative
Analysis
R.1.16
Scheduled
Component
Removals
Programmatic
Written documentation on scheduled

component removal timelines shall be
developed.
Qualitative
Analysis
R.1.17
Call Center
Programmatic
Quantitative
Demonstration
595
FAA AC 150/5210-24
Debris (FOD)
Management
FAA AC 150/5220-24
Equipment
User Interviews
Requirements
User Surveys
Table 4. AFDIRTS System Requirement Origin Map
R.1.1 Reliability
R.1.4 Electromagnetic Interference
R.1.5 Equipment Located Outside of Paved Surfaces
R.1.6 Installation and Acceptance Standards
R.1.7 Breakaway Connector
R.1.8 Wind Loading
R.1.13 Cleaning Procedures
R.1.14 Preventative Maintenance Procedures
596
FAA AC 150/5220-24
Equipment
FAA AC 150/5210-24
Debris (FOD)
Management
Type
Basis of
Description
Metric
Verified By
R.1.18
LINK.1.2
ATC -> AUI
Performance
F.1.9 Interface
with Air Traffic
Control
The ATC -> AUI Human Machine

Interface shall allow Air Traffic Controllers
to select Normal or Emergency Modes of
operation as well as advising ATC of
AFDIRTS system health. The AIU shall be
evaluated utilizing Usability Heuristics for
User Interface Design developed by
Jakob Nielsen and zero usability
problems shall be discovered.
Quantitative
Analysis
R.1.19
LINK.5.9
External
Power ->
Power
Performance
F.5.4 Transfer
Power
The External Power -> Power Transfer

Panel external interface shall be
capable of transferring 120/240V singlephase AC power from the external
source to the transfer panel. The wire
Quantitative
Test
User Interviews
Name
User Surveys
Number
Requirements
R.1.15 Recalibration Plan
R.1.16 Scheduled Component Removals
R.1.17 Call Center
Table 5. AFDIRTS External Interface Specifications
597
Transfer
Panel
gauge utilized will be dependent upon

total system current.
598
Command and Control Segment
Table 6. Command and Control Segment Requirements

Number
Name
Type
Basis of
Description
Metric
Verified By
R.2
AFDIRTS
Command and
Control
Functional
F.1 Command and

Control System

of centralized command and
control of all system elements.
Qualitative
Test
R.2.1
Power Failure
Performance
F.1.11 Restore
System
In the event of a power

failure, AFDIRTS must have the
capability to automatically
power-up and operate in the
condition and settings that
were available just prior to the
power failure.
Binary
Test
R.2.2
Navigation Data
Functional
F.1.7 Transmit
Inbound Aircraft
Data to System
Elements

of transmitting inbound
aircraft data to the Air
Retrieval Vehicle (ARV) with
100% accuracy.
Quantitative
Test
R.2.3
Navigation Modes
Functional
F.1.2 Initiate System

Modes
F.1.3 Transmit
Normal Operation
Command F.1.4
Transmit Emergency
Command

subsystem shall be capable of
transmitting the normal
operation command to the
Air Retrieval Vehicle (ARV).
Binary
Test
R.2.4
AFDIRTS
Communication
Composite

ATC
Airport Managers
The Command and Control

Subsystem shall provide a
method of interfacing with Air
Traffic Control, Airport
Qualitative
Demonstration
599
Number
R.2.5
Name
Command and
Control Segment
Specification
Type
Performance
Basis of
Description

Maintenance
Personnel
Management, and System

Maintainers.
F.1 Command and

Control System

segment shall be capable of
transmitting data to system
elements with 99.9% reliability.
Metric
Verified By
Quantitative
Test
FAA AC 150/5210-24
Debris (FOD)
Management
FAA AC 150/5220-24
Equipment
User Interviews
Requirements
User Surveys
Table 7. Command and Control Segment Requirement Origin Map
R.2 AFDIRTS Command and Control

R.2.1 Power Failure
R.2.4 AFDIRTS Communication
R.2.5 Command and Control Segment Specification
600
Table 8. Command and Control Subsystem Specifications

Number
Name
Type
Basis of
Description
Metric
Verified By
R.2.5.1
COMP.1.2
ATC Interface
Unit (AIU)
Specification
Performance
F.1.1
Interface
with ATC
The ATC Interface Unit (AIU) shall be

capable of allowing ATC to select Normal
or Emergency Modes of operation as well
as advising ATC of AFDIRTS system health.
The AIU shall be evaluated utilizing the
heuristic evaluation developed by Jakob
Nielsen. If usability problems are
discovered they shall not receive a
usability severity rating of greater than 1.
Quantitative
Demonstration
R.2.5.2
COMP.1.1
Airport
Management
Display Unit
(AMDU)
Specification
Performance
F.1.9
Interface
with Airport
Managers
The Airport Management Display Unit

(AMDU) shall be capable of notifying
airport personnel of unsuitable FOD
location data and AFDIRTS system health
data. The AMDU shall be evaluated
utilizing the heuristic evaluation
greater than 1.
Quantitative
Demonstration
R.2.5.3
COMP.1.3
Command
and Control
CPU
Specification
Performance
F.1.2 Initiate
System
Modes
The Command and Control Computer

shall be capable of performing at a
minimum of 700,000,000 clock cycles per
second (700Mhz)
Quantitative
Test
R.2.5.4
COMP.1.6
Command
and Control
Data Link
Specification
Performance
F.1.7 Transmit
Inbound
Aircraft Data
to System
Elements
The command and control data link shall

comply with WP-2, Command and
Control (C2) Data Link White Paper Issued
03-18-14 that contains Minimum
Operational Performance Standards
Quantitative
Test
601
Number
Name
Type
Basis of
Description
(MOPS) for Unmanned Aircraft System
(UAS) Command and Control Data Links.
The MIU shall be capable of accepting
self-test commands from maintenance
personnel as well as displaying self-test
results and faults in critical/non-critical
subsystems. The MIU shall be evaluated
utilizing the usability heuristic evaluation
greater than 1.
Metric
Verified By
Quantitative
Test
R.2.5.5
COMP.1.7
Maintenance
User Interface
(MIU)
Specification
Performance
F.1.10.2
Display
Maintenance
Data
R.2.5.6
COMP.1.4
Backup CPU
Specification
Performance
F.1.11 Restore
System
The back-up command and control

computer shall be capable taking over in
the event of main computer failure. The
back-up command and control
computer shall be capable of performing
a minimum of 700,000,000 clock cycles
per second (700Mhz).
Quantitative
Test
R.2.5.7
COMP.1.3.1
Command
and Control
Software
Specification
Performance
F.1
Command
and Control
System
The Command and Control software shall

AFDIRTS to command and control AFDIRTS
system elements as per AFDIRTS system
requirements. Command and Control
Assurance Level (DAL) of A IAW DO178C, Software Considerations in Airborne
Systems and Equipment Certification from
RTCA Inc.
Quantitative
Test
602
Table 9. Command and Control Internal Interfaces

Number
Name
Type
Basis of
Description
Metric
Verified By
R.2.6
LINK.1.5
Iferret ->
AMDU Link
Specification
Performance
F.1.9
Interface
with Airport
Managers
The Iferret -> AMDU Data Link shall meet

the current issues of radio suppression
and Susceptibility. It must be capable of
operating through the entire amplitude
modulated aircraft radio frequency range
of 75 MHz 136 MHzs
Quantitative
Demonstration
603
System Health and Monitoring Segment
Table 10. System Health and Monitoring Segment Requirements

Number
Name
Type
Basis of
Description
Metric
Verified By
R.3
Safe
Operation
Composite
F.2 Operate Safely
The system shall not cause

damage to airport personal or
property; nor shall it become a
distraction to operations or
support personnel.
Qualitative
Demonstration
R.3.1
ATC
Emergency
Control
Performance
F.4.2 Navigate Airfield
Air Traffic Control shall be

capable of initiating an
emergency mode of operation
that removes all Air Retrieval
Vehicles from airfield operating
Quantitative
Test
R.3.2
Self-Test
Functional

self-testing non-critical
subsystems.
Binary
Demonstration
R.3.3
Self-Test
Duration
Performance
The self-test duration on mobile

system elements should not
exceed 30 seconds.
Quantitative
Test
R.3.4
Maintainer
Self-Test
Functional
System maintenance personnel

shall be capable of initiating a
self-test on both stationary and
mobile system elements.
Binary
Test
R.3.5
System
Health
Specification
Functional

of Stationary Element
Critical Subsystems
The AFDIRTS shall be capable of

automatically detecting faults in
critical subsystems, provide users
with data regarding faults in
Binary
Demonstration
Test
604

of Mobile Element
Critical Components
F.2.5 Compensate for
Critical Components
F.2.6 Provide Airport
Health Data
F.2.7 Provide ATC with
System Health Data
F.2.8 Provide
with System Health
Data
non-critical subsystems, and

compensate for failures in ARV
critical subsystems until the ARV
can navigate to designated
emergency landing areas.
FAA AC 150/5210-24
Debris (FOD)
Management
FAA AC 150/5220-24
Equipment
User Interviews
Requirements
User Surveys
Table 11. System Health and Monitoring Segment Requirement Origin Map
R.3 Safe Operation

R.3.1 Emergency
R.3.2 Self-Test
R.3.3 Self-Test Duration
605
FAA AC 150/5210-24
Debris (FOD)
Management
FAA AC 150/5220-24
Equipment
User Interviews
User Surveys
Requirements
R.3.4 Maintainer Self-Test
R.3.5 System Health
Table 12. System Health and Monitoring Segment Subsystem Specifications

Number
Name
Type
Basis of
Description
Metric
Verified By
R.3.5.1
COMP.2.4
Command and
Control
Interface Unit
(CCIU)
specification
Performance
F.2.6 Provide
Airport
Managers with
System Health
Data
F.3.2 Determine
FOD Suitability
from a
Distance
F.4.3.2 Notify
Personnel of
Object too
Large for
Retrieval
F.4.3.5 Notify
Personnel of
The CCIU shall be capable of

providing airport managers with
AFDIRTS system health data as well as
the location of FOD Irretrievable by
automated system elements. The
AMDU shall be evaluated utilizing the
heuristic evaluation developed by
Jakob Nielsen and receive no
usability severity rating greater than
1.
Quantitative
Analysis
606
Number
Name
Type
Basis of
Description
Metric
Verified By
Overweight
Objects
R.3.5.2
COMP.2.2
System Health
Computer
(SHC)
Specification
Performance
F.2.2 Monitor
the Health of
Stationary
Element
Critical
Subsystems
The system health computer shall be

capable of performing at a minimum
of 700,000,000 clock cycles per
second (700Mhz)
Quantitative
Test
R.3.5.3
COMP.2.1
System Health
Data Link (SHR)
Specification
Performance
F.2.1 Receive
Telemetry
Signal From
Stationary
Elements
F.2.3 Receive
Telemetry Data
from Mobile
Elements
The System Health Data Link shall

operate on a frequency that does
not interfere with airport operations
and shall perform at a level greater
than or equal to 99.8% reliability at 10
years of its service life.
Quantitative
Demonstration
R.3.5.4
COMP.2.2.1
System Health
Software
Specification
Performance
F.2.4.1 Direct
SHC operation
The System Health Software shall

AFDIRTS to monitor system health and
execute self-test instructions as per
system requirements. System Health
DO-178C, Software Considerations in
Airborne Systems and Equipment
Quantitative
Test
607
Table 13. System Health and Monitoring Segment Internal Interfaces

Number
Name
Type
Description
Metric
Verified By
R.3.5.5
L.INK.2.2
SHR -> SHC
Internal Interface
Requirement
Performance
The SHR -> SHC interface shall be

capable of transferring data at
minimum of 1 gigabit per second
(Gbps).
Quantitative
Test
608
FOD Detection Segment
Table 14. FOD Detection Segment Requirements

Number Name
Type
Basis of
Description
Metric
Verified By
R.4
FOD
Detection
Segment
Composite
F.3 Scan
Airfield for
FOD
The FOD Detection segment shall be

capable of detecting FOD items on the
airfield and reporting its location to
system elements.
Binary
Demonstration
R.4.1.1
FOD
Location
Reporting
Performance
Location reporting shall be accurate to

within 16 ft. (5.0 m) of the actual FOD
object location.
Quantitative
Test
R.4.1.2
Suitability
Reporting
Performance
F.3.3
Determine
Location of
FOD
F.4.3.2 Notify
Personnel of
Object too
Large for
Retrieval
The system shall be capable of notifying

airport personnel of FOD unsuitable for
carcasses) with GPS coordinates
accurate to within 16 ft. (5.0 m) of the
actual FOD location.
Quantitative
Demonstration
R.4.1.3
FOD
Detection
Performance
F.3.1 Detect
FOD

single and multiple FOD items on the
AOA.
Binary
Test
R.4.1.4
Group
Object
Detection
Performance
F.3.1 Detect
FOD

detect 90 percent of the following group
of objects when placed within a 100 ft.
by 100 ft. (30 m by 30 m) square in the
desired coverage area. One item from
each category must be included in the
group and each item must measure no
larger than 4 in (10 cm) in any dimension
unless otherwise specified: A chunk of
asphalt or concrete, Any portion of a
Quantitative
Test
609
Number Name
Type
Basis of
Description
runway light fixture (in-pavement or
edge light), An adjustable crescent
wrench up to 8 in. (20 cm) in length), A
deep socket (at least 2 in. (5 cm) in
length), A piece of rubber from an
aircraft tire, A distorted metal strip (up to
8 in. (20 cm) in length), Fuel cap (aircraft
or automotive), Lug nut, Hydraulic line
(from aircraft or GSE, up to 8 in. (20 cm)
in length).
detect an unpainted, metal cylinder,
measuring 1.2 in (3.1 cm) high and 1.5 in
(3.8 cm) in diameter.
Metric
Verified By
Quantitative
Test
R.4.1.5
Metal
Cylinder
Detection
Performance
F.3.1 Detect
FOD
R.4.1.6
Sphere
Detection
Performance
F.3.1 Detect
FOD

detect a white, grey, or black sphere,
Quantitative
Test
R.4.1.7
Lighting
Conditions
Performance
F.3.1 Detect
FOD
The system shall demonstrate detection

performance during daylight, nighttime,
Qualitative
Test
R.4.1.8
Automated
Retrieval
Suitability
Functional
F.3.2
Determine
FOD Suitability
from a
Distance

determining items unsuitable for
carcasses) based upon physical
characteristics.
Qualitative
Test
R.4.1.9
Detection
Time
Performance
F.3.1 Detect
FOD

FOD within 4 minutes of a FOD
occurrence.
Quantitative
Demonstration
610
FAA AC 150/5210-24
Debris (FOD)
Management
FAA AC 150/5220-24
Equipment
User Interviews
Requirements
User Surveys
Table 15. FOD Detection Segment Requirement Origin Map
R.4.1.1 FOD Location Reporting

R.4.1.3 FOD Detection
611
Table 16. FOD Detection Segment Subsystem Specifications

Number
Name
Type
Basis of
Description
Metric
Verified By
R.4.1.10
COMP.3.1
IFerret
Specification
&AFDIRTS
Interface
Unit
Performance
F.3 Scan
Airfield for
FOD
The IFerret system is a COTS subsystem that shall

be capable of interfacing with the AFDIRTS.
Binary
Demonstration
Table 17. FOD Detection Segment Internal Interface Specifications

Number
Name
Type
R.4.1.11
LINK.3.1
IFerret &
AFDIRTS
Interface
Unit <-> NAV
Radio
Internal
Interface
Specification
Performance
Basis of
Description
Metric
The IFerret & AFDIRTS Interface Unit <-> NAV

Radio Internal Interface shall comply with
Emissions and Susceptibility. The interface must
range of 75 MHz 136 MHzs and have the
ability to transfer data a minimum of 3 miles.
Quantitative
Verified
By
Test
612
Air Retrieval Vehicle (ARV) Segment
Table 18. Air Retrieval Vehicle (ARV) Segment Requirements

Number
Name
Type
Description
Metric
R.5.1.1

Dimensions
Performance
The air vehicle subsystem shall be no larger than (L x W x

H): 38L x 38.5W x 22H (excluding VERSABALL Gripper).
Quantitative
Verified
By
Analysis
*Units in inches
R.5.1.2
Maximum All-Up
Weight (AUW)
Performance
The ARV subsystem shall weigh no more than 39lbs.
Quantitative
Analysis
R.5.1.3
MAX Operational
Flight Time
Performance
The ARV subsystem shall have a MAX Operational flight

time of at least 10 min.
Quantitative
Test
R.5.1.4
MAX Forward Speed
Performance
The ARV subsystem shall have a MAX forward speed of

at least 45 MPH.
Quantitative
Test
R.5.1.5
MAX Operating
Wind Speed
Performance
The ARV Subsystem MAX Operating Wind Speed 30MPH.
Quantitative
Test
613
FAA AC 150/5210-24
FAA AC 150/5220-24
Equipment
SME Interviews
User Surveys
Requirements
Table 19. Air Retrieval Vehicle (ARV) Segment Requirement Origin Map
R.5.1.1 Air Retrieval Vehicle Dimensions

R.5.1.2 Maximum All-Up Weight (AUW)
R.5.1.3 MAX Operational Flight Time
R.5.1.4 MAX Forward Speed
R.5.1.5 MAX Operating Wind Speed
614
Table 20. Air Retrieval Vehicle (ARV) Subsystem Specifications

Number
Name
Type
Basis of
Description
Metric
Verified By
R.5.1
COMP.4
Air Retrieval
Vehicle
Composite
F.4 Transport
Retrieval
Subsystem (ARV)
The air vehicle subsystem shall

provide a method of lift that is
capable of lifting one pound of FOD
(.7 Kilograms) moving at 20mph (30
km/h) with 1 motor not spinning.
Quantitative
R.5.2
COMP.4.1
Movement
and Control
Subsystem
Specification
Performance
F.4.1 Move and

Control ARV
The Movement and Control

Subsystem shall be capable of
providing a minimum of 80 pounds
of thrust with the ability to keep the
ARV stable in 30MPH winds and
have a reliability of 99.8% over 5000
hours of use. If the Movement and
Control Subsystem should fail it shall
fail in a manner that allows the ARV
to reach designated emergency
areas.
Quantitative
Demonstration
Test
R.5.3
COMP.4.2
Navigation
Subsystem
Functional
F.4.2 Navigate
Airfield
F.4.2.2 Process
Navigation
Commands
F.4.2.3 Detect
Obstacles
F.4.2.5 Receive
Aircraft
Trajectory Data
from ATC F.4.2.6
Anticipate
Obstacle
Movement
Mobile system elements shall be

capable of navigating the airfield
with 0 input from humans.
Quantitative
Demonstration
Test
615
Number
Name
Type
R.5.4
COMP.4.3
Power
Subsystem
Performance
R.5.5
COMP.4.4
FOD Retrieval
Subsystem
Functional
Basis of
F.4.2.7 Determine
Path Around
Obstacles
F.4.2.8 Determine
Location
F.4.4 Provide ARV
Electrical Power
F.4.3 Retrieve
FOD
F.4.3.5 Notify
Personnel of
Overweight
Objects
Description
Metric
Verified By
The Power Subsystem shall be

capable of storing a minimum 40Ah
of electric charge and be capable
of delivering a minimum of 500
Amps of continuous discharge to
the electronic speed controllers
whom shall be capable of receiving
a minimum of 500 Amps @ 18.5 volts
from the battery. All subsystems
receiving electricity from the battery
shall have zero noise induced into
the subsystems as a result of electric
motor operation.
Quantitative
Test

autonomously retrieving FOD from
paved surfaces.
Binary
Demonstration
616
Air Retrieval Vehicle (ARV) Movement and Control Subsystem
Table 21. Air Retrieval Vehicle (ARV) Movement and Control Subsystem Requirements
Number Name
Type
Description
Metric
Verified By
R.5.2
Performance
The Movement and Control Subsystem shall be

capable of providing a minimum of 80 pounds
of thrust with the ability to keep the ARV stable
in 30MPH winds and have a reliability of 99.8%
over 5000 hours of use. If the Movement and
Control Subsystem should fail it shall fail in a
manner that allows the ARV to reach
designated emergency areas.
Quantitative
Demonstration
Test
Movement
and Control
Subsystem
Specification
FAA AC 150/5210-24
FAA AC 150/5220-24
Equipment
SME Interviews
User Surveys
Requirements
Table 22. Air Retrieval Vehicle (ARV) Movement and Control Subsystem Requirement Origin Map
R.5.1.1 Movement and Control Subsystem Specification
617
Table 23. Air Retrieval Vehicle (ARV) Movement and Control Subsystem Specifications
Number
Name
Type
Basis of
Description
Metric
R.5.1.1
COMP.4.1.3
COMP.4.1.4
COMP.4.1.5
COMP.4.1.6
COMP.4.1.7
COMP.4.1.8
COMP.4.1.9
COMP.4.1.10
Electric Motor
Specification
Performance

F.4.1.12 Spin #4
Propeller
F.4.1.15 Spin #5
Propeller
F.4.1.17 Spin #6
Propeller
F.4.1.20 Spin #7
Propeller
F.4.1.23 Spin #8
Propeller
The ARV electric motor electric

shall weigh no more than 9 oz.
and be capable of spinning a
26x8.5 prop at 1850 RPM at 18.5
volts +/- 10%. The motor shall
have an operating power rating
of at least 750W for 3 minutes.
Quantitative
Verified
By
Test
R.5.1.2
COMP.4.1.11
COMP.4.1.12
COMP.4.1.13
COMP.4.1.14
COMP.4.1.15
COMP.4.1.16
COMP.4.1.17
COMP.4.1.18
Electronic
Speed
Controller
Specification
Performance
F.4.1.2 Control #1
Motor Speed
F.4.1.5 Control #2
Motor Speed
F.4.1.8 Control #3
Motor Speed
F.4.1.11 Control #4
Motor Speed
F.4.1.14 Control #5
Motor Speed
F.4.1.17 Control #6
Motor Speed
F.4.1.20 Control #7
Motor Speed
F.4.1.23 Control #8
Motor Speed
The electronic speed controllers

shall be capable of providing a
minimum of 18.5 volts @ 40 Amps
to the electric motors and weigh
no more than 1.5 oz.
Quantitative
Test
618
Number
Name
Type
Basis of
Description
Metric
R.5.1.3
COMP.4.1.19.1
MCCOMP
Software
Specification
Performance
F.4.1.1 Carry out

Instructions
The MCCOMP Software shall

contain the instructions that allow
the movement and control
subsystem to best meet system
requirements. The MCCOMP
software shall achieve a Design
DO-178C, Software
Considerations in Airborne
Systems and Equipment
Quantitative
Verified
By
Test
R.5.1.4
COMP.4.1.25
COMP.4.1.25
COMP.4.1.25
COMP.4.1.25
Propeller
Specification
Performance
Motor Thrust
Motor Thrust
Motor Thrust
Motor Thrust
The ARV counter spinning

propeller shall be made of
carbon fiber, have a length
degrees.
Quantitative
Inspection
R.5.1.5
COMP.4.1.21
COMP.4.1.22
COMP.4.1.23
COMP.4.1.24
Pusher
Propeller
Specification
Performance
F.4.1.4 Generate #1
Motor Thrust
F.4.1.7 Generate #2
Motor Thrust
Motor Thrust
Motor Thrust
The ARV clockwise spinning

propeller (Pusher) shall be made
of carbon fiber, have a length
degrees.
Quantitative
Inspection
R.5.1.7
COMP.4.1.19
Movement
and Control
Computer
Performance
F.4.1.1 Carry out

Instructions
The movement and control

computer shall be capable of
700,000,000 clock cycles per
second (700Mhz).
Quantitative
Test
619
Number
R.5.1.8
Name
(MCCOMP)
Specification
COMP.4.1.20
Movement
and Control
GPS Unit
(MCGPS)
Specification
Type
Basis of
Description
Metric
Verified
By
Performance
F.4.1.26 Determine GPS

Location
The movement and control GPS

shall provide horizontal and
vertical coordinates to the
movement and control
subsystem. It shall comply with all
specifications listed in RTCA Inc.
Performance Standards for
Global Positioning System/Aircraft
Base Augmentation Systems. The
Movement and Control GPS shall
achieve a minimum of 7.8 meter
accuracy at a 95% confidence
interval.
Quantitative
Test
Table 24. Air Retrieval Vehicle (ARV) Movement and Control Subsystem Internal Interface Specification
Number
Name
Type
Description
Metric
R.5.1.6
LINK.4.1.18
ESC1 -> EM1 Internal
Interface Requirement
Performance
The ESC1 -> EM1 interface shall carry up to 18.5

Volts DC at a maximum of 40 amps equating. To
safely accommodate this amperage the wire
length shall be no longer than 4 feet with a wire
gauge of no less than 8 AWG.
Quantitative
Verified
By
Inspection
620
Air Retrieval Vehicle (ARV) Navigation Subsystem
Table 25. Air Retrieval Vehicle (ARV) Navigation Subsystem Requirements

Number
Name
Type
Description
Metric
Verified By
R.5.2
Mobile Unit
Navigation
Functional

navigating the airfield with no input from humans.
Binary
Demonstration
R.5.2.1
Mobile Unit Speed
Performance

operating on the AOA at a speed of no less than 20
mph (30 km/h).
Quantitative
Demonstration
R.5.2.2
Mobile Unit
Movement
Clearance
Performance
The system shall be capable of detecting,

anticipating movement and avoiding all airport
traffic with 0 input from air traffic control.
Quantitative
Demonstration
R.5.2.2.1
Separation from
Obstacles
Performance

ten foot (3.05 meters) separation from all obstacles.
Quantitative
Test
R.5.2.2.2
Separation from
Aircraft
Performance

a minimum of fifty feet (15.24 meter) separation from
all aircraft and remain clear of jet blast.
Quantitative
Test
R.5.2.2.3
Separation from
Personnel
Performance

fifty foot (15.24 meter) separation from all personnel.
Quantitative
Test
R.5.2.2.4
Separation from
Vehicles
Performance
Mobile system elements shall maintain a minimum 25

foot (7.6 meter) separation from all support vehicles.
Quantitative
Test
R.5.2.3
Emergency
Posture
Functional

navigating to predefined emergency locations
defined by airport managers.
Binary
Demonstration
621
Number
Name
Type
Description
Metric
Verified By
R.5.2.4
FOD Location
Functional

navigating to detected FOD location.
Binary
Demonstration
R.5.2.5
Navigation
Commands
Functional
The Navigation subsystem shall be capable of

receiving and processing navigation commands
from air traffic control.
Binary
Demonstration
R.5.2.6
Disposal Area
Functional
The navigation subsystem shall be capable of

navigating to FOD disposal areas.
Binary
Test

Management

Detection Equipment
User Interviews
Requirements
User Surveys
Table 26. Air Retrieval Vehicle (ARV) Navigation Subsystem Requirement Origin Map

R.5.2.1 Mobile Unit Speed
R.5.2.2.1 Separation from Obstacles
R.5.2.2.2 Separation from Aircraft
R.5.2.2.3 Separation from Personnel
R.5.2.2.4 Separation from Vehicles
622

Management

Detection Equipment
User Interviews
User Surveys
Requirements
R.5.2.5 Navigation Commands
R.5.2.6 Disposal Area
Table 27. Air Retrieval Vehicle (ARV) Navigation Subsystem Specifications

Number
Name
Type
Basis of
Description
Metric
R.5.2.8
COMP.4.2.1
NAV Computer
Specification
Performance
F.4.2.2 Process
Navigation
Commands
The NAV computer shall be capable of

700,000,000 clock cycles per second
(700Mhz).
Quantitative
Verified
By
Test
R.5.2.9
COMP.4.2.4
NAV GPS
Specification
Performance
F.4.2.8 Determine
Location

compiling with all specifications listed in
RTCA Inc. DO-316 Minimum
Operational Performance Standards for
Global Positioning System/Aircraft Base
Augmentation Systems. The NAV GPS
shall achieve a minimum of 7.8
horizontal meter accuracy at a 95%
confidence interval.
Quantitative
Test
623
Number
Name
Type
Basis of
Description
Metric
R.5.2.10
COMP.4.2.3
NAV RADAR Unit
Specification
Performance
F.4.2.4 Determine
Obstacle
Location
The ARV NAV RADAR Unit shall operate

between 110 and 300 Ghz (millimeterband) a resolution capable of
detecting aircraft, obstacles, humans,
and animals in the vicinity (100 feet) of
the ARV. The ARV NAV RADAR Unit shall
not interfere with any existing airport or
aircraft avionic systems.
Quantitative
Verified
By
Test
R.5.2.11
COMP.4.2.5
NAV Radio
Specification
Performance
F.4.2.1 Receive
Navigation
Command
F.4.2.5 Receive
Aircraft Trajectory
Data from ATC
The ARV NAV Radio shall meet the

current issues of radio suppression
and Susceptibility. It must be capable
of operating through the entire
amplitude modulated aircraft radio
frequency range of 75 MHz 136 MHzs
Quantitative
Test
R.5.2.12
COMP.4.1.1
Attitude and
Heading
Reference
Systems (AHRS)
Performance
F.4.1.27 Determine
Position in Space
The ARV AHARS shall be capable of

determining acceleration, angular
rate, magnetic field, ambient pressure,
DeltaTheta and DeltaVelocity. The
AHARS shall be capable of performing
these measurements with a minimum
of 99.9% accuracy.
Quantitative
Test
R.5.2.13
COMP.4.1.2
Barometric
Altimeter Unit
Specification
Performance
F.4.1.28 Determine
Barometric
Pressure
The Barometric Altimeter Unit shall be

capable of calculating the current
barometric pressure reading at the
units resting altitude to determine the
ARVs Altitude Above Sea Level during
flight. The Barometric altimeter shall be
accurate to + or - .25 Feet.
Quantitative
Test
624
Table 28. Air Retrieval Vehicle (ARV) Navigation Subsystem Internal Interface Specification
Number
Name
Type
Description
Metric
R.5.2.14
LINK.4.2.6
Internal Interface Requirement
Performance

interfacing with the NAV computer
at a data rate of no less than 1
gigabit per second and comply with
all specifications listed in RTCA Inc.
Performance Standards for Global
Positioning System/Aircraft Base
Augmentation Systems.
Quantitative
Verified
By
Inspection
Test
625
Air Retrieval Vehicle (ARV) Power Subsystem
Table 29. Air Retrieval Vehicle (ARV) Power Subsystem Requirements

Number
Name
Type
Basis of
Description
Metric
R.5.3
Power Subsystem
Specification
Performance
F.4.4 Provide
ARV
Electrical
Power
The Power Subsystem shall be capable of

storing a minimum 40Ah of electric charge
and be capable of delivering a minimum of
500 Amps of continuous discharge to the
electronic speed controllers which shall be
capable of receiving a minimum of 500
Amps @ 18.5 volts from the battery. All
subsystems receiving electricity from the
battery shall have zero noise induced into
the subsystems as a result of electric motor
operation.
Quantitative
Verifi
ed By
Test
FAA AC 150/5210-24
FAA AC 150/5220-24
Equipment
SME Interviews
User Surveys
Requirements
Table 30. Air Retrieval Vehicle (ARV) Power Subsystem Requirement Origin Map
R.5.3 Power Subsystem Specification
626
Table 31. Air Retrieval Vehicle (ARV) Power Subsystem Specifications

Number
Name
Type
Basis of
Description
Metric
R.5.3.1
COMP.4.3.2
Battery
Specification
Performance
F.4.4.1 Provide
Stored Electricity
to ARV
The ARV Battery shall be capable of

storing a minimum 40Ah of electric
charge and be capable of at least 500
Amps of continuous discharge.
Quantitative
Verified
By
Test
R.5.3.2
COMP.4.3.1
Power Distribution
Board (PDB)
Specification
Performance
F.4.4.5 Provide
Power to ESC_1
F.4.4.6 Provide
Power to ESC_2
F.4.4.7 Provide
Power to ESC_3
F.4.4.8 Provide
Power to ESC_4
F.4.4.9 Provide
Power to ESC_5
F.4.4.10 Provide
Power to ESC_6
F.4.4.11 Provide
Power to ESC_7
F.4.4.12 Provide
Power to ESC_8
The power distribution board shall be

made of copper and be capable of
conducting a minimum of 500 Amps @
18.5 volts from the battery to the
electronic speed controllers.
Quantitative
Test
R.5.3.3
COMP.4.3.3
Voltage
Regulator
Specification
Performance
F.4.4.2 Regulate
NAV Subsystem
Voltage
The voltage regulator shall be capable

of regulating 18.5 volt supply voltage to
provide the necessary fixed DC voltage
to ARV subsystems (accurate to +/- 3%)
without inducing any noise into the
subsystem.
Quantitative
Test
627
Table 32. Air Retrieval Vehicle (ARV) Power Subsystem Internal Interface Specifications
Number
Name
Type
Description
Metric
R.5.3.4
LINK.4.3.4
BATT -> VR
Internal Interface
Specification
Performance
The battery BATT -> VR interface shall be capable of

transferring 18.5 volts at a minimum of 100 amps. This will
require a 1AWG copper wire as per FAA AC 21-99 Aircraft
Wiring and Bonding.
Quantitative
Verified
By
Test
628
Air Retrieval Vehicle (ARV) FOD Retrieval Subsystem
Table 33. Air Retrieval Vehicle (ARV) FOD Gripping Subsystem Requirements
Number
Name
Type
Basis of
Description
Metric
Verified By
R.5.4
FOD
Retrieval
Functional
F.4.3 Retrieve FOD

of Overweight Objects

from paved surfaces.
Binary
Demonstration
R.5.4.2
FOD
Weighing
Functional
F.4.3.4 Determine the

weight of FOD
The ARV Subsystem shall be

capable of determining when
objects are weigh greater than 1
lb.
Quantitative
Test
R.5.4.3
FOD Max
Weight
Performance
F.4.3 Retrieve FOD

weighing up to 1 pound (.453
kilograms)
Quantitative
Test
R.5.4.4
FOD
location
Performance

of Object too Large for
Retrieval F.4.3.5 Notify
Personnel of
Overweight Objects

shall be capable of notifying
airport personnel of objects that
are over 1 pound or .45359237
kilograms or over 12 inches in
length 12 Inches in width and 12
inches in height so that they may
be retrieved manually.
Quantitative
Test
R.5.4.5
FOD
Dimensions
Performance
F.4.3.1 Determine FOD

Characteristics

with dimensions of up to 12 inches
in length 12 Inches in width and 12
inches in height.
Quantitative
Test
629
Number
Name
Type
Basis of
Description
Metric
Verified By
R.5.4.6
FOD
Grasping
Performance
F.4.3.3 Grasp FOD

F.4.3.6 Release FOD

shall be capable of grasping FOD
12 inches in length 12 Inches in
width and 12 inches in height for
transport to the disposal areas.
Quantitative
Test
FAA AC 150/5210-24
Debris (FOD)
Management
FAA AC 150/5220-24
Debris (FOD)
Detection Equipment
User Interviews
Requirements
User Surveys
Table 34. Air Retrieval Vehicle (ARV) FOD Gripping Subsystem Requirement Origin Map
R.5.4 FOD Retrieval

R.5.4.2 FOD Weight Determination
R.5.4.3 FOD Weight
R.5.4.4 FOD location
R.5.4.6 FOD Grasping
630
Table 35. Air Retrieval Vehicle (ARV) FOD Retrieval Subsystem Specifications
Number
Name
Type
Basis of
Description
Metric
R.5.4.1.1
COMP.4.4.3
FOD
Camera Unit
Specification
Performance
F.4.3.1
Determine
FOD
Characteristics
The FOD camera unit shall be capable of

imaging the FOD at a distance of 3 feet with a
resolution of 16 MP minimum. The FOD camera
unit shall be capable of determining FOD
characteristics and suitability of retrieval. The
FOD camera unit shall be capable of
determining the exact direction and distance to
the FOD and communicating this data to the
ARV Navigation Subsystem.
Quantitative
Verified
By
Test
R.5.4.1.2
COMP.4.4.4
Weight
Sensor
Specification
COMP.4.4.2
VERSABALL
System
Specification
Performance
F.4.3.4
Determine
FOD weight
The weight sensor shall be able to determine the

weight of items grasped by the VERSABALL
Gripper with an accuracy of (+or- .05 lb.)
Quantitative
Test
The Gripper shall have the ability to grasp an

unpainted, metal cylinder, measuring 1.2 in (3.1
cm) high and 1.5 in (3.8 cm) in diameter. The
Gripper shall have the ability grasp a sphere,
measuring 1.7 in (4.3 cm) or less in diameter A
chunk of asphalt or concrete weighing less
than 1 pound, any portion of a runway light
fixture (in-pavement or edge light), An
adjustable crescent wrench up to 8 in. (20 cm)
in length), A deep socket (at least 2 in. (5 cm) in
length), A piece of rubber from an aircraft tire, A
distorted metal strip (up to 8 in. (20 cm) in
length), Fuel cap (aircraft or automotive), Lug
nut, Hydraulic line (from aircraft or GSE, up to 8
in. (20 cm) in length).
Quantitative
Test
COMP.4.4.1
Retrieval
Telemetry
Performance
The Retrieval Telemetry Radio shall meet the

Quantitative
Test
R.5.4.6.1
R.5.4.7
Performance
F.4.3.2 Notify
Personnel of
Object too
631
Radio
Specification
Large for
Retrieval
Emissions and Susceptibility. It must be capable

of operating through the entire amplitude
modulated aircraft radio frequency range of 75
MHz 136 MHzs.
Table 36. Air Retrieval Vehicle (ARV) FOD Retrieval Subsystem Internal Interface Specifications
Number
Name
Type
Description
Metric
R.5.4.8
LINK.4.4.3
Weight Sensor <-> Versaball System
Internal Interface Specification
Performance
The Weight Sensor <-> Versaball

System Internal Interface shall be
capable of transferring the physical
weight of grasped objects to the
weight sensor for measurement. It
shall minimize aircraft vibration by at
least 80% by incorporating a
vibration absorber into the design.
Quantitative
Verified
By
Test
632
ARV Housing and System Power Segment
Table 37. ARV Housing and System Power Segment Requirements

Number
Name
Type
Description
Metric
Verified By
R.6
AV Housing
and Power
Specification
Performance
The AFDIRTS system shall be capable of receiving

120/240V single-phase AC external power and
transferring this power to AFDIRTS system elements.
Quantitative
Test
R.6.1
Back-Up
Power
Performance
The system shall be capable of generating back-up

120/240V single-phase AC power that will provide 10
minutes of emergency power that will give mobile
system elements enough time to navigate to emergency
standby locations.
Quantitative
Test
R.6.2
Loss of
External
Power
Performance
The back-up power subsystem shall be capable of

sensing low phase-to-ground voltage and when voltage
or frequency drops to 95% of nominal the relay shall
activate the generator.
Quantitative
Test
633
FAA AC 150/5210-24
Debris (FOD)
Management
FAA AC 150/5220-24
Equipment
Requirements
User Interviews
User Surveys
Table 38. ARV Housing and Power Segment Requirement Origin Map
R.6 AV Housing and Power Specification

R.6.1 Back-Up Power
Table 39. ARV Housing and Power Segment Subsystem Specifications

Number
Name
Type
Basis of
Description
Metric
R.6.3
COMP.5.4
ARV housing
Specification
Performance
F.5 Provide
AV Housing
F.5.6
Secure ARV
The ARV housing unit shall be capable of securing

and sheltering the ARV from the elements The
ARV housing unit shall be fireproof and provide a
method of dehumidifying the unit when relative
humidity exceeds 30%.
Quantitative
Verified
By
Test
R.6.4
COMP.5.5
Battery
Charger
Specification
Performance
F.5.8
Recharge
Air Vehicle
The ARV battery charger shall be capable of

providing an 18.5 volt 40 AMP charge to the
ARVs batteries. (1C of 40,000 mAh)
Quantitative
Test
R.6.5
COMP.5.3
Generator
Specification
Performance
F.5.3
Generate
The AFDIRTS generator shall be capable of

delivering 120/240V single-phase AC power to
provide 10 minutes of emergency power that will
Quantitative
Test
634
Number
Name
Type
Basis of
Description
Emergency
Power
give mobile system elements enough time to

navigate to emergency standby locations.
Metric
Verified
By
R.6.6
COMP.5.1
Power
Transfer
Panel
Specification
Performance
F.5.1
Accept
External
Power
F.5.4
Transfer
Power
The Power Transfer Panel shall be capable of

accepting 120/240V single-phase AC power and
transferring this power to system elements. The
Power Transfer Panel shall be capable of circuit
protection when system elements begin to pull
excessive current.
Quantitative
Test
R.6.7
COMP.5.2
Transfer
Switch
Specification
Performance
F.5.2
Detect
External
Power
Failure
The Transfer Switch shall be capable of detecting

loss of external power and automatically starting
the emergency generator when external power is
absent for 1 second.
Quantitative
Test
R.6.8
COMP.5.6
Charging
Receptacle
Specification
Performance
F.5.7
Make
Charging
Connection
The charging receptacle shall be capable of

transferring 18.5 volts @ 40 Amps from the ARV
Battery Charger to the ARV battery. It shall be
designed so that when the ARV is secured to the
housing unit the charging receptacle shall make
contact.
Quantitative
Test
Verified
By
Test
Table 40. ARV Housing and Power Segment Internal Interface Specification
Number
Name
Type
Description
Metric
R.6.9
LINK.5.7
Gen -> PWR
Transfer PNL
Int. Interface
Spec
Performance
The Generator -> Power Transfer Panel Internal Interface shall

be capable of transferring 120/240V single-phase AC power
from the generator to the transfer panel. The wire gauge
utilized will be dependent upon total system current.
Quantitative
635
Table 41. FOD Analysis Segment Requirements

Number
Name
Type
Basis of
Description
Metric
Verified By
R.7
FOD Analysis
Segment
Functional
F.6 Analyze
FOD Trends
F.6.2 Perform
Trend Analysis
F.6.4 Export
FOD Reports
The FOD analysis segment shall

provide a method of trend
analysis that will be utilized to
improve foreign objects left on
the airfield.
Qualitative
R.7.1
Types of Data
Functional

receiving and storing FOD alert
time and date, location
coordinates and FOD image
data.
Binary
Test
R.7.1.1
Storage of
Data
Performance
F.6.1 Accept
FOD alert time
and date,
location
coordinates
and FOD
image data
F.6.3 Retain
Data
Data collected in the FOD

detection process shall be
recorded and stored for at
least 2 years after the
detection event.
Quantitative
Test
Demonstration
636
FAA AC 150/5210-24
FAA AC 150/5220-24
Equipment
Requirements
User Interviews
User Surveys
Table 42. FOD Analysis Segment Requirement Origin Map
R.7 FOD Analysis Segment

R.7.1 Types of Data
Table 43. FOD Analysis Segment Subsystem Specifications

Number
Name
Type
R.7.2
COMP.6.1
Analysis
Computer
Specification
Performance
R.7.3
COMP.6.2
Analysis Radio
Specification
Performance
Basis
of
Description
Metric
The FOD analysis computer shall be capable of

performing at a minimum of 700,000,000 clock cycles
per second (700Mhz)
Quantitative
Verified
By
Test
The Analysis Radio shall meet the current issues of

radio suppression specification MIL-STD-461, Class 3D,
Interference Emissions and Susceptibility. It must be
capable of operating through the entire amplitude
modulated aircraft radio frequency range of 75 MHz
136 MHzs.
Quantitative
Test
637
Number
Name
Type
R.7.4
COMP.6.1.1
Analysis
Software
Specification
Performance
Basis
of
Description
Metric
The Analysis Computer Software shall enable the

AFDRTS Computer to retain and export upon user
request; FOD Location, FOD alert time, date of
occurrence, location coordinates, and FOD Image
data for at least two years following the FOD event.
Quantitative
Verified
By
Test
Table 44. FOD Analysis Segment Internal Interface Specifications

Number
Name
Type
Description
Metric
R.7.5
LINK.6.1
Computer Internal
Interface Specification
Performance
The Analysis Radio -> Analysis Computer Internal

Interface shall be capable of transferring data at
minimum of 1 gigabit per second (Gbps).
Quantitative
Verified
By
Test
638
Appendix G
AFDIRTS Risk Management Report
639
Table of Contents
Introduction
641
Risk Cube Definitions
642
Risk # R.1 Worksheet.. 643

Risk # R.5 Waterfall..
648
640
Introduction
At the beginning of the SM4 Project, 5 risks were identified and subsequently tracked
throughout AFDIRTS development. Initial risks have been listed below:
1. If stakeholder interviews do not uncover all potential problems; or gather
enough information about the operating environment then these issues will
become more expensive to solve in the latter stages of AFDIRTS development;
because the design will be more complex and difficult to change.
2. If care is not taken to ensure traceability throughout system development,
then system architectural questions may go unanswered during the SM4
presentation; because a traceability matrix was unavailable.
3. If the triumvirate of conceptual design; as described by Kossiakoff et al. (2011,
p.175) is not applied to requirements analysis, then system requirements may be
developed as ambiguous and difficult to decompose into subordinate
requirements,; or just not make sense; because requirements analysis was not
properly performed.
4. If lessons learned are not documented as the project progresses, then they
may become difficult to recall during development of the final report; because
a lessons learned document was not available.
5. If the ATC interface requires too much of the controllers attention, it may
hinder their ability to control air/ground traffic; because they will be overtasked.
Risk Worksheets were developed along with one risk waterfall chart to aid in tracking
and documenting these initial risks.
641
Level
Likelihood
Probability of
Occurrence
Not Likely
~10%
Low likelihood
~30%
likely
~50
Highly Likely
~70
Near Certainty
~90
Consequence of Failure (C f )
Table 1. Risk Cube Definitions

5
4
3
2
1
1
Likelihood of Failure(L f )
Level
Performance/Technical
Schedule
Cost
Minor
shortfall

Slip < 1 week

Moderate
shortfall

Slip < 2 week

Major
shortfall

Slip > 2 weeks

Cannot meet Key

Performance Parameters
Will not be able to finish on

schedule

increase of >10% of Budget
642
Table 2. Design Flaw Risk Worksheet

Risk Number: R.1
Type:
Risk Title:
Design Flaws
Cost
Schedule
Performance
The AFDIRTS system concept does not address all
operational objectives; or some operational objectives
required to meet users needs go undocumented.
The systems specification could be submitted to
developers without necessary system specifications. This
can become an expensive fix later in system
development.

Action/Event
Success Criteria
Risk Level if
Successful
Cf
Lf
Design and implement a user survey to poll

users, SMEs and stakeholders to elicit system
requirements.
Publish a survey on the Survey Monkey

Website and obtain at least 25
responses from users, SMEs and
stakeholders
Make contact with users and stakeholders and

keep in contact throughout the systems
engineering process.
Obtain at least 3 contacts that can be

reached at any time during concept
development for questions
643
Table 3. Traceability Risk Worksheet

Risk Number: R.2
Type:
Risk Title:
Need -> Objective ->
Requirement -> Function ->
Component Traceability
Cost
Schedule
Performance
Traceability is not maintained throughout concept
development.
The project schedule may be threatened because it will
require extra resources to incorporate tractability in the
end.

Action/Event
Learn to use CORE.
Save a different copy of CORE after
each day of work on the SM4 project
Success Criteria
All CORE videos developed by
Christopher Olson have been
watched.
At the end of each workday, the
project has been exported under
the filename date_Roig.
Risk Level if
Successful
Cf
Lf
644
Table 4. ATC Interface Risk Worksheet

Risk Number: R.3
Type:
Risk Title:
ATC interface
Cost
Schedule
Performance
The ATC interface is designed to be too complex and
requires too much of the controllers attention.
The complexity of the ATC interface may hinder Air Traffic
Controllers ability to control air/ground traffic because
they will be distracted. This could lead to ground or air
incursions.

Action/Event
The ATC interface shall be designed with
simplicity in mind; giving ATC the option of
normal or emergency operation only.
Success Criteria
The ATC interface design shall
provide only two options for ATC
to select. Additionally, the
interface shall be evaluated
utilizing Usability Heuristics for
User Interface Design developed
by Jakob Nielsen and zero
usability problems shall be
discovered.
Risk Level if
Successful
Cf
Lf
645
Table 5. Lessons Learned Risk Worksheet

Risk Number: R.4
Type:
Risk Title:
Cost
Schedule
Performance
Lessons learned are not documented as the project
progresses.
They may become difficult to recall during development
of the final report.

Action/Event
Date
Scheduled
Success Criteria
Actual
Risk Level if
Successful
Cf
Lf
Risk was accepted.
646
Table 6. Substandard Requirements Risk Worksheet

Risk Number: R.5
Type:
Risk Title:
Cost
Schedule
Performance
Substandard Requirements
System requirements are ambiguous, difficult to
understand or difficult to decompose into subordinate
requirements.
The development of inadequate requirements may lead
to a system that does not meet users needs.

Risk Level if
Successful
Cf
Lf
3
4
Action/Event
Success Criteria
Contact SMEs, Users and Stakeholders to

vet initial Operational Objectives.
Contact at least 5 SMEs, Users and

Stakeholders to discuss initial
Operational Objectives.
Apply the triumvirate of conceptual

design to Operational Requirements to
ensure that the Why interrogative is
accurately applied and incorporated into
initial Operational Requirements.
All Operational Requirements

answer the why question.
Develop a survey to poll Users, SMEs and

Stakeholders.
A survey is developed on
SurveyMonkey and at least 25
Users, SMEs and Stakeholders
participate.
2.5
Analyze performance requirements to

ensure they are implementation free as
well as answer the how much question.
All performance requirements have

the ability to be verified by analysis
or testing and they answer the how
much question.
Functional and Physical diagrams are

developed to assist in the development of
system specifications.
Functional and Physical diagrams

are documented in CORE.
647
Table 6. AFDIRTS Substandard/Inaccurate Requirements Risk Waterfall Worksheet

Risk# R.5
Title: Inadequate Requirements
Mitigation Strategies
1. Made contact with potential users to

define operational objectives and
developed potential system concepts.
Likelihood of Failure (L f )
2
3
4
5
6
2. Initial Operational Requirements were

derived from Operational Objectives.
SMEs, Users and Stakeholders were
contacted to vet initial Operational
Requirements.
Conceptual Design Report

A-Spec
Final Report
Oral Report
4. A survey was developed on the

SurveyMonkey web platform that
polled 28 Users, SMEs and Stakeholders
to obtain accurate and attainable
performance requirements.
5. Performance requirements were
reviewed that they could be verified by
analysis or testing and they answered
the how much question.
6. Functional and Physical diagrams
were developed which were utilized to
help develop system specifications.
Concept
Validation
Functional Analysis Report

Trade Study
Concept
Selection
Functional
Analysis and
Formulation
Performance
Requirements
Analysis
Performance
Requirements
Validation
Implementation
Concept
Exploration
Performance
Requirements
Formulation
Operational
Requirements
Analysis
Needs Validation
Feasibility
Definition
Functional
Analysis
Operational
Analysis
Project Proposal
Requirements Analysis Report
3. The triumvirate of conceptual design

was applied to the Operational
Requirements to ensure that the Why
interrogative was accurately applied
and incorporated into initial Operational
Requirements.
648

Roig Final Report v1

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Roig Final Report v1

Enviado por

Direitos autorais:

Formatos disponíveis

Systems Engineering Masters

Airfield FOD Detection, Identification, Removal and

Submitted for review:

AFDIRTS System Description

Key Performance Parameters... 6

AFDIRTS Context Diagram.

Initial Requirements Document.. 15

COMP.3 FOD Detection Segment .163

AFDIRTS System Requirements 236

Subsystem Specifications... 274

Project Objectives and Approach

Original Operational Objectives

5. Facilitate Inclement Weather Operation

Provide a High Level of Reliability, Availability and Maintainability

Provide FOD Trend Analysis

guidance published in Advisory Circular 150/5220-24 and FOD Management guidance

Different operational scenarios were evaluated which helped translate operational

Specification (A-Spec) captured component and interface specifications and these

Key Performance Parameters

R.5.4.3 FOD Max Weight

COMP.1 Command and Control Segment

COMP.2 System Health and Monitoring Segment

system health of critical subsystems therefore, COMP.2.3 Components Defined as

COMP.3 FOD Detection Segment

Figure 1. IFerret CONOPS

COMP.4 Air Retrieval Vehicle (ARV)

Figure 2. COMP.4 Air Retrieval Vehicle (ARV) Conceptual Image

COMP 4.1 Movement and Control Subsystem

COMP 4.2 ARV Navigation Subsystem

COMP 4.3 ARV Power Subsystem

COMP 4.4 Retrieval Subsystem

COMP.5 Power and Housing Segment

Figure 4. COMP.5 Power and Housing Segment Conceptual Image

COMP.6 FOD analysis segment

Figure 5. AFDIRTS Context Diagram

System Health (D)

Aircraft Location (D)

Obstacle Illumination (E)

Obstacle Location (E)

ATC Command (D)

Aircraft Illumination (E)

Electrical Energy (E)

FOD Location (E)

R.1 Safe Operation

University Edition - For Academic Use Only

R.2 System Command and Control

University Edition - For Academic Use Only

R.3 FOD Scanning and Detection

University Edition - For Academic Use Only

University Edition - For Academic Use Only

R.5 FOD Retrieval

University Edition - For Academic Use Only

R.6 Mobile Unit Locomotion

Mobile Unit Speed

University Edition - For Academic Use Only

R.7 Provide FOD Trend Analysis

University Edition - For Academic Use Only

R.8 System Communication

University Edition - For Academic Use Only

R.9 Technical Support

University Edition - For Academic Use Only

R.10 Installation and Acceptance Standards

Figure 16. Installation and Acceptance Standards Requirements Hierarchy Diagram