Attachment 0009 SEP Design ES 110521.pdf

CUI

SUAS-0001

Soldier Unmanned Aircraft Systems (SUAS) ACAT Level III

Systems Engineering Plan (SEP)

5 November 2021

DISTRIBUTION STATEMENT D.

Distribution Authorized to Department of Defense and U.S. DoD Contractors only; In Accordance With (IAW) U.S. Army Family of Small Unmanned Aircraft Systems (FoS UAS) Security Classification Guide (SCG), 22 November 2017.

Other requests shall be referred to the UAS Project Office, ATTN: SFAE-AV-UAS-SUAS, Redstone, AL 35898

Controlled by: SFAE-AV-UAS-SU CUI Categories: CUI//SP-CTI Distribution/Dissemination Control: D POC: Ottis Airhart, 256-690-1468 (cell)

CUI ii

SYSTEMS ENGINEERING PLAN (SEP)

FOR THE

Soldier Unmanned Aircraft Systems (SUAS)

Prepared:

Amy W. Harding

Lead Systems Engineer Soldier UAS

Submitted:

OTTIS L. AIRHART

Chief Engineer

CARSON L. WAKEFIELD

Product Lead

Concurrence:

SEAN D. TOWNSEND

Chief Engineer Technical Management Division

Unmanned Aircraft Systems

JOSEPH S. ANDERSON

COL, IN

Project Manager

Unmanned Aircraft Systems

LARS D. ERICSSON

Assistant PEO Engineering & Technology

MDA

Approval:

ROBERT L. BARRIE

Brigadier General, USA PEO, Aviation

HARDING.A

MY.WILSON

.1407106560

Digitally signed by

HARDING.AMY.WIL

SON.1407106560

Date: 2021.11.08 14:13:17 -06'00'

AIRHART.O

TTIS.LEE.1

294322481

2021.11.08 14:27:40 -06'00'

WAKEFIELD.C

ARSON.LADO

NA.128376894

Digitally signed by

WAKEFIELD.CARSON

.LADONA.1283768941

Date: 2021.11.08 14:34:45 -06'00'

CUI iii

TABLE OF CONTENTS

1 INTRODUCTION

1.1 PROGRAM DESCRIPTION

1.2 APPROACH FOR UPDATES AND APPLICABLE DOCUMENTS

1.3 PROGRAM BACKGROUND

2 PROGRAM TECHNICAL REQUIREMENTS

2.1 ARCHITECTURES AND INTERFACE CONTROL

Architecture

2.2 TECHNICAL CERTIFICATIONS

3 ENGINEERING RESOURCES AND MANAGEMENT

3.1 TECHNICAL SCHEDULE AND SCHEDULE RISK ASSESSMENT

Relationships with External Technical Organizations

3.2 RISK, ISSUE, AND OPPORTUNITY MANAGEMENT

Issue and Opportunity Management

3.3 TECHNICAL STRUCTURE AND ORGANIZATION

Government Program Office Organization Program Office Technical Staffing Levels Engineering Team Organization and Staffing

3.4 TECHNICAL PERFORMANCE MEASURES (TPM) AND METRICS

4 TECHNICAL ACTIVITIES AND PRODUCTS

4.1 PLANNED SE ACTIVITIES FOR THE NEXT PHASE

SRR

MRR

LRR

Cybersecurity

4.2 REQUIREMENTS DEVELOPMENT AND CHANGE PROCESS

4.3 TECHNICAL REVIEWS AND TEST EVENTS

Development Effort Process Technical Interchange Meetings (TIMs) System Requirements Review (SRR) Preliminary Design Review (PDR) Critical Design Review (CDR) Test Readiness Review (TRR)

4.4 CONFIGURATION AND CHANGE MANAGEMENT

4.5 DESIGN CONSIDERATIONS

Near Term Short Term

4.6 ENGINEERING TOOLS

5 ACRONYMS

CUI iv

TABLES

Table 1.2-1 SEP Update Record Table 1.2-2 Applicable Documents Table 2.2-1 Technical Certifications Table 3.4-1 Key Performance Parameters (KPPs) Table 3.4-2 Key System Attributes (KSAs) Table 3.4-3 Additional Performance Attributes (APAs) Table 4.3-1 SRR Criteria Table 4.3-2 PDR Criteria Table 4.3-3 CDR Criteria Table 4.3-4 TRR Criteria

FIGURES

Figure 2.1-1 SUAS Architecture Diagram Figure 2.1-2 H-GCS FACE Architecture Figure 2.1-3 SUAS Internal Interface Figure 2.1-4 SRR System Configuration Figure 2.1-5 MRR System Configuration Figure 3.2-1 Risk Assessment Process Figure 3.3-1 Product Office Organization Figure 3.3-2 SUAS IPT/WG Hierarchy Figure 4.0-1 SUAS Schedule

CUI 1

1 Introduction

1.1 Program Description

The Soldier Unmanned Aircraft Systems (SUAS) Systems Engineering Plan (SEP) provides the top-level SUAS systems engineering process and technical management approach for developing and integrating the Rucksack Portable Unmanned Aircraft System Family of Small (RPUAS FoS) UAS in accordance with (IAW) the desired capabilities specified in the Capability Production Document (CPD) for RPUAS. This SEP is written IAW the Office of the Deputy Assistant Secretary of Defense for Systems Engineering (ODASD (SE)) Systems Engineering Plan (SEP) Outline, and is tailored to support the capability-based development of RPUAS FoS and ensures implementation of a multi-tiered risk management process to protect the operational capabilities of the RPUAS FoS.

This Family of Systems includes requirements for three mission specific configurations, which are Short Range Reconnaissance (SRR) Unmanned Aircraft (UA), Medium Range Reconnaissance (MRR) UA, and Long Range Reconnaissance (LRR) UA, and includes the Tactical Open Government-owned Architecture (TOGA) Handheld-Ground Control Station (H-GCS).

The SEP serves as a detailed method for planning and executing all technical activities required for transforming the user needs, requirements, and constraints into acceptable system solutions. The SEP provides the framework for performing engineering tasks in developing the SUAS system that satisfies joint warfighter operational needs. The overall technical approach is primarily driven by applying systems engineering principles via engineering service contracts to achieve incremental performance improvements and to maintain interoperability, airworthiness, safety, and cybersecurity.

The SUAS SEP is the capstone document that captures the SUAS systems engineering processes that support efficient delivery of an RPUAS FoS to the Warfighter and intends to guide specific FoS UA programs and Systems Engineering Management Plans (SEMPs). In the event of a conflict between the text of the SUAS SEP and the applicable engineering process documents cited herein, the text of the SUAS SEP will take precedence. When SEMPs update, Systems Engineers will identify conflicts between the SEP or SEMPs and the SUAS SEP for resolution. In cases where conflicts between the SUAS SEP and SEMPs cannot be resolved, the SUAS Systems Engineering Working Groups and Councils will reach resolution at the lowest possible level before the SUAS Technical Chief approves them.

CUI 2

1.2 Approach for Updates and Applicable Documents

The SUAS Lead Systems Engineer directs updates to the SUAS SEP to capture changes resulting from systems engineering process improvements and/or organizational updates. Table 1.2-1 documents the SUAS SEP revision history.

This revision history shall show only signed official releases of the SUAS SEP.

Table 1.2-2 documents other applicable documents referenced in this SEP.

Table 1.2-1 SEP Update Record

Revision Date Change Log and Reason

- 4 June 2021 Initial Document Draft

1 1 October 2021

Initial Document Release

• Update MBSE details

• Add DIU and G2 external entities

• Discuss sustainment and trade study analysis

• Update cybersecurity section with OSCR and

SCRM

Table 1.2-2 Applicable Documents

# Document Document Number Date

1 Mission Needs Statement JROC Memo 003-90 5 January 1990

2 Rucksack Portable Unmanned Aerial Vehicle (RPUAV), Operational Requirements Document

(ORD)

24 August 2004

3 Department of the Army, Deputy Chief of Staff, G-3 Memorandum; Army Adoption of the United States Special Operations Command (USSOCOM) Rucksack Portable Unmanned Aerial Vehicle (RPUAV) Operational Requirements Document

(ORD)

7 January 2005

4 Office of the Deputy Assistant Secretary of Defense for Systems Engineering (ODASD SE) Systems Engineering Plan (SEP) Outline

Version 3.0 12 May 2017

5 SRR Simplified Acquisition Management Plan (SAMP) Version 1.2 13 February 2019

MRR Test and Evaluation Master Plan (TEMP) Version 1.0 28 July 2020

7 Acquisition Strategy Report (ASR) 8 March 2005 8 C4I Support Plan (C4ISP) 22 April 2005 9 Capability Production Document (CPD) for the

Rucksack Portable Unmanned Aircraft System (RPUAS) Increment II

23 November

10 Rucksack Portable Unmanned Aircraft Systems Capability Production Document Basis of Issue Guidance Change Memorandum

28 August 2015

CUI 3

# Document Document Number Date

11 Acquisition Strategy for Rucksack Portable Unmanned Aircraft Systems (RPUAS) Family of Small Unmanned Aircraft Systems (FoS)

Version 1.0 20 May 2016

12 SUAS Configuration Management Plan (CMP) SUAS-0002 4 December 2020 13 Department of Defense Risk, Issue, and Opportunity

Management Guide for Defense Acquisition Programs

9 January 2017

14 DoD IPPD Handbook August 1998 15 PEO Aviation

Modular Open Systems Approach (MOSA) Implementation Guide

Version 1.0 14 May 2021

16 Technical Standard for the Future Airborne Capability Environment (FACE) Edition 2.1 24 Jun 2014

17 DoD Cybersecurity Test and Evaluation Guidebook Version 2.0, Change 1 10 Feb 2020

18 PEO Aviation Operational Survivability through Cyber Resilience (OSCR) Cyber Integration Handbook

Draft 01 Sep 2020

19 NIST SP 800-160 - Systems Security Engineering:

Systems Security Engineering - An Integrated Approach to Building Trustworthy Resilient Systems

Volume 1 21 Mar 2018

20 Army Materiel Maintenance Policy AR 750-1 28 Oct 2019

1.3 Program Background

The development of initial requirements for the Rucksack Portable Unmanned Air Vehicle (RPUAV) Raven Operational Requirements Document (ORD) were adopted from a United States Special Operations Command (USSOCOM) ORD by Department of the Army-Capabilities Integration Center (DAMO-CIC) in Fiscal Year 2005 (FY05), providing battalion commanders Reconnaissance, Surveillance, and Target Acquisition (RSTA) and force protection during both day and nighttime operations. RPUAV Raven became a Program of Record (PoR) in FY06. This program transitioned from the initial RPUAV Increment I, titled RQ- 11B Raven Program, to RPUAS FoSUAS Increment 2, titled Family of Small Unmanned Aircraft Systems (FoSUAS) as per Acquisition Decision Memorandum (ADM) dated 22 February 2016.

The Tactical UAS Product Office managed the SUAS product line within PM UAS and became its own product office as of November 2019. The user representative was originally the Army’s Training and Doctrine Command (TRADOC) Capability Manager (TCM) at Fort Rucker for the RPUAS and is now the Robotics Requirements Division (RRD) of the Maneuver Center of Excellence (MCoE) at Fort Benning, GA.

The SUAS program is executing requirements contained in the Increment 2, Block I Capability Production Document (CPD) dated November 2013. A PoR decision for RPUAS FoS was completed 2QFY16. These requirements will be fulfilled with a Category 1 Modification to the RQ-11B UA, the addition of a new

CUI 4

Ground Segment product, and a new SRR quadcopter UAS. The LRR system efforts will begin in FY23-24.

2 Program Technical Requirements

The SUAS systems provide RSTA support to the ground maneuver commander.

The system additionally provides cooperative engagement and communications relay mission support. The primary mission of Near Real Time (NRT) intelligence support includes the following tasks:

• Named Area of Interest (NAI) and Targeted Area of Interest (TAI) surveillance

• Route, area, and zone reconnaissance support

• Intelligence Preparation of the Battlefield (IPB) support

• Situational development support

• Target acquisition support

• Indirect fire, Close Air Support (CAS), and close-in fire support

• Rear area security support

• Combat search and rescue support

• Battle Damage Assessment (BDA) support

2.1 Architectures and Interface Control

The following figures and narrative describe the SUAS architecture. This subject divides into three categories: functional, physical, and interface discussion.

Architecture

The SUAS architecture allows the SE team to show the structure of system components, their relationships to one another, as well as the principles and guidelines governing their design and evolution throughout the design process.

Planning, designing, maintaining control as well as updating the architecture are critical activities for the SE team. This is important to meet product and platform performance objectives as well as meeting higher-level Army and DoD objectives such as compliance with safety and airworthiness requirements and meeting the Modular Open Systems Approach (MOSA) objectives placed on the SUAS

CUI 5

Product Office. The SE Lead maintains the primary responsibility for ensuring that SUAS product architectures go through design, delivery, and maintenance for each product’s development cycle.

SUAS is implementing Model-Based Systems Engineering (MBSE) using the Cameo Enterprise Architecture (Cameo EA) software suite. Cameo EA enables SUAS to develop and manage requirements, support system design and modeling, as well as verification and validation analysis activities. The SUAS MBSE effort began with modeling the CPD requirements and tracing them to the SRR Tranche 1 effort. The effort further continued in to capturing the SRR tranche 1 system design and physical configuration for production. This enables SUAS to trace CPD-level requirements down to the SRR design level and down to the SRR Tranche 1 implementation level.

As a continuation of this MBSE effort, the SUAS team has developed the SRR Tranche 2 requirements in the model. This enables the SUAS team to see how the requirements have developed from Tranche 1 to Tranche 2 as well as implementing suggestions and refinements in Tranche 2 that were discovered during Tranche 1 development. Cameo EA enables the SUAS team to export diagrams and reports from the developed model to support analysis and review activities and events respectively. This ability to generate documents from the model enables the SUAS team to support required reviews that are document-centric and compare how the model and its data have changed over time. This particular ability will allow one to see how the SRR Tranche 2 effort has expanded or changed with respect to the Tranche 1 requirement set and design.

In the future, SUAS is exploring options for integrating Cameo EA with other software tools to expand the Digital Engineering (DE) suite of tools available to the SUAS team. In particular, investigating integration between Cameo EA and Windchill to capture tracing linkage from the system design to the configuration-managed documentation. This would help the SUAS team in meeting the DoD’s challenge to implement DE tools and processes.

CUI 6

The following Figure depicts the SUAS architecture.

Figure 2.1-1 SUAS Architecture Diagram

A major activity within architecture development is defining Major System Components (MSC) and subsystem interfaces. This is a critical activity for ensuring integration success later as well as meeting MOSA objectives. Initial SUAS MSCs consist of the Aircraft, the H-GCS, payloads and the radio. SUAS plans to control MSC interfaces through the SUAS Engineering Working Group and as such, create opportunities for potential reuse of these components across the enterprise pending SWaP and cost effectiveness.

SUAS has designed the H-GCS architecture to conform with the Future Airborne Capability Environment (FACE) 2.1 Technical Standard. The SE team wrote FACE requirements that trace to the developer requirements, the code, and tests. Interchanging software applications and radios developed by two different developers proves the modular and open architecture of the system. The following Figure depicts the H-GCS FACE Architecture.

Field Repair Kit (FRK)

CUI 7

Figure 2.1-2 H-GCS FACE Architecture

The following Figure depicts the SUAS Internal interface diagram.

Figure 2.1-3 SUAS Internal Interface

While the above diagram is not exhaustive, capturing the interfaces within a system is a critical activity as part of the architecture development and analysis.

A list of interfaces within SUAS contains items such as:

• Data link communications between the UA and GCS aligning to MOSA objectives

• Environmental between system components and the surrounding environment

• Human to system interfaces (HSI) present between the system and the operator, maintainer, and soldier

• Potential future communications from the system to rear-echelon HQs or Tactical Operations Center (TOC)

CUI 8

• Payload interface to include mechanical/physical, electrical, and data exchange for MOSA objectives

• Other component modularity and interchangeability objectives to include Interface Control Documents (ICD) capturing mechanical/physical, electrical, data, and software exchanges and interfaces

The SRR system is comprised of two (2) complete quad-rotor UAs with combined gimbaled High Definition (HD) Electro Optical (EO) camera and Infrared (IR) camera sensor payloads. A Ground / Support Segment containing an H-GCS and Universal Battery Charging Station supports the system. The SRR provides real time Full Motion Video (FMV) and multi-sensor sending data to the operator’s H-GCS. The SRR is organic to the maneuver and maneuver support platoons. The small unit will employ the SRR to support a wide variety of short-range mission sets by performing tactical Reconnaissance, Security, and Surveillance (RSS), Battle Damage Assessment (BDA), Force Protection, and Chemical, Biological, Radiological, and Nuclear (CBRN) detection. Field units will employ the SRR while at mounted or dismounted locations and is capable of recovery within confined areas. The SRR system, packaged with the H-GCS for field operations, weighs less than 20 pounds and fits into or affixes to the standard Soldier rucksack system. The UA, configured for flight, weighs approximately 5 pounds with payload, has a range of 3 km electronic line-of-sight, and flight time endurance of approximately 30 minutes. Optimal altitude for operations is 250 feet above ground level. Figure 2.1-1 shows the SRR system configuration.

CUI 9

Figure 2.1-4 SRR System Configuration

The MRR System consists of one UA with sensor payload, supported by a Ground / Support Segment containing an H-GCS and Universal Battery Charging Station. The MRR payload consists of a combined gimbaled HD EO/IR camera, and LASER Illuminator (LI). The MRR version recapitalizes the current RQ-11B Raven Pathfinder UAS. The MRR provides real time FMV and multi-sensor sending data to the operator’s H-GCS and other One Station Remote Video Terminals (OSRVT). Units will employ the MRR to support a wide variety of mission sets by performing tactical RSS, BDA, Force Protection, CBRN detection, and LASER Illumination. The MRR is organic to the maneuver and maneuver support company units and CBRN battalion assets. The system provides the small unit commander with improved real time situational awareness day and night and in adverse weather conditions. Field units will employ the MRR in locations both mounted and dismounted. The MRR system, packaged with the H-GCS for field operations, weighs less than 20 pounds and fits into or affixes to the standard Soldier rucksack system. The UA, configured for flight, weighs approximately 5 pounds with payload, has a range of 10 km electronic line-of-sight, and flight time endurance of approximately 90 minutes. Optimal altitude for operations is 350 feet above ground level. Figure 2.1-2 shows the MRR system configuration.

Aircraft

H-GCS

Universal Battery Charging Station

CUI 10

Figure 2.1-5 MRR System Configuration

2.2 Technical Certifications

Table 2.2-1 summarizes certification requirements below.

Table 2.2-1 Technical Certifications

Certification POC Certification Authority Certification Date

Army Interoperability PM UAS CIO G-6 November 2020 Risk Management Framework (RMF)/

Cybersecurity PMO IASO CIO G-6 SRR ATO: July 2020

MRR ATO: May 2020

Airworthiness AvMC SRD SRD Recurring Safety AMCOM Safety AMCOM Recurring

Aircraft

Universal Battery Charging Station

H-GCS

CUI 11

3 Engineering Resources and Management

3.1 Technical Schedule and Schedule Risk Assessment

This section describes the organizations and implementation approach for controlling the overall technical schedule of the program. SUAS Product Lead (PdL) utilizes Integrated Product and Process Development (IPPD) principles to guide technical planning and control based on the framework outlined in the DoD IPPD Handbook. Integrated Product Teams (IPT) comprised of varying functional disciplines to produce an effective product that meets the needed capabilities, achieve this IPPD objective. IPTs manage objectives and tasks with affiliated suspense dates and action officers. The business management group, as members of these teams, then tracks these tasks through use of an Integrated Master Schedule (IMS).

The current SUAS schedule seeks to offer flexibility in addressing program changes due to either changing needs, sudden budget shortfalls, or development delays. It has taken into account the realities of yearly funding availability and has attempted to avoid fourth quarter contract awards that put funding at risk.

Further, it acknowledges the investment and momentum already established with early deployments, strives to protect that investment and avoid substantial cost increases by ensuring the minimization of production gaps, associated costs, and workforce interruptions.

SUAS developed the current schedule and strategy to achieve technical realism, schedule stability, and the balancing of program risk across the aspects of resources, technology, testing and training. Each IPT/ Working Groups (WG) will routinely conduct a critical path analysis to identify and plan for critical events to include any risk mitigating steps that may be necessary.

Relationships with External Technical Organizations

The Robotics Requirements Division (RRD) of the Maneuver Center of Excellence (MCoE) is the user representative for SUAS. The RRD of MCoE is the principle external organization participating in our IPTs. Requirements reviews include RRD of MCoE involvement and participation.

The TEMP documents the methodology by which SUAS ensures Army Test and Evaluation Command (ATEC) independent evaluation for efforts.

The Joint System Integration Laboratory (JSIL) provides support for the Army Interoperability Certification (AIC), Interoperability Profile (IOP) certifications, and post-production software updates.

CUI 12

The Defense Innovation Unit (DIU) has assisted the SRR tranche efforts by developing an SRR Other Transaction Agreement program strategy that emphasizes competition by maintaining a competitive environment throughout the Tranche prototyping phases. DIU and PM UAS began Tranche 1 prototyping with identification of the Area of Interest, continued market research, and performance of trade studies on the payload and radio candidates.

The G-2 documents the Validated On-Line Lifecycle Threat Report (VOLT) for SUAS. SUAS meets with G-2 on a quarterly basis to help monitor, track, and forecast known and unknown threats and vulnerabilities to generate requirements that make the systems maintain sufficient resilience, survivability, and effectiveness.

The Systems Readiness Directorate (SRD) provides Air Worthiness Releases (AWRs) for the SUAS systems to fly at all test events and in the field.

The Software, Simulation, Systems Engineering and Integration (S3I) Directorate within the US Army Aviation & Missile Command (AMCOM) Safety provide support and approval for Materiel Release of the SUAS systems.

3.2 Risk, Issue, and Opportunity Management

The SUAS program utilizes a risk management approach as defined by the Department of Defense Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs. The IPTs identify specific risks and rate on Likelihood and Consequence of occurrence in the areas of Cost, Schedule and Performance. Figure 3.2-1 defines the ratings below.

The Risk Review Board (RRB) reviews all proposed Program Risks for acceptance as well as updates to open items to approve proposed changes.

SUAS has defined specific risk acceptance criteria for the RRB to track.

Stakeholder participants will include those within SUAS, contractors and subcontractors. SUAS utilizes a Program Risk Management Tool held on SharePoint within the SUAS Portal, which functions as a repository for all open, closed, and rejected Program Risks.

Risk Acceptance Criteria:

1. future root cause

2. risk cube values for likelihood and consequence

3. feasible mitigation(s)

4. action officer assigned for mitigation plan development

CUI 13

Figure 3.2-1 Risk Assessment Process

Once the RRB accepts a risk, a plan for management—usually entailing mitigation—is developed. This mitigation plan functions as a burn down plan, outlining what level the risk is through the mitigation process and the point at which it becomes a low risk. An SUAS team member takes on each accepted risk as the action officer IAW their area of expertise and stakeholder position to propose further inputs and updates into the risk tool for the RRB to approve.

At each RRB, the team discusses the risk burn down plans of active risks.

Issue and Opportunity Management

Once a team member realizes the consequence of a risk and it becomes an issue, the PM IPT properly tracks and addresses it at that level.

The SUAS product office periodically identifies initiatives for continuous improvement within the organization. These initiatives represent opportunity to improve cost, schedule, or performance through some reallocation of resources.

The PM IPT identifies tracks and monitors opportunities to fruition.

Risk Assessment Process Rating Likelihood 5

5 Near Certainty (~90%) 4

4 Highly Likely (~70%) 3

3 Likely (~50%) 2

2 Low Likelihood (~30%) 1

1 Not Likely (~10%) 1 2 3 4 5

Cost

5 > $5M

4 $1M - $5M

3 $250K - $1M

2 $50K - $250K

1 < $50KMinimal or no consequence to technical performance.

Minor reduction in technical performance or supportability;

can be tolerated with little or no impact on program.

Moderate reduction in technical performance or supportability with limited impact on program objectives.

Significant degradation in technical performance or major shortfall in supportability; may jeopardize program success.

Severe degradation in technical performance; cannot meet KPP or key technical/supportability threshold; will jeopardize program success.

Rating

Minimal or no impact.

Able to meet key dates.

Minor schedule slip. Able to meet key milestones with no schedule float.

Program critical path affected.

Cannot meet key program milestones.

Schedule

Assessment

Consequence

Unacceptable. Major disruption likely. Different approach required.

Priority management attention required.

Some Disruption. Different approach may be required.

Additional management attention may be needed.

Minimum impact. Minimum oversight needed to ensure risk remains low.

Technical Performance

Low

Moderate

High

Consequence Li ke lih oo d

CUI 14

3.3 Technical Structure and Organization

Government Program Office Organization

The organization of the SUAS program consists of a Product Lead who reports to the UAS Project Office, which is subordinate to Program Executive Office (PEO) Aviation. Both PEO Aviation and PM UAS are located on Redstone Arsenal in Huntsville, AL. The key acquisition functional groups support the SUAS Product Lead: technical, logistics, and business and the product groups: SRR, MRR, and LRR. Figure 3.3-1 depicts the product office organization.

The technical staffing of SUAS is composed of a Chief Engineer that reports directly to the Deputy Product Lead (DPdL) and the PdL. The Chief Engineer oversees functional leads in the areas of Systems Engineering, Product Engineering, and Test. The functional leads are responsible for their area of expertise and the technical Subject Matter Experts (SMEs).

Figure 3.3-1 Product Office Organization

The SE Lead will provide leadership and oversight to the technical team for incorporating objectives within SE. These will include, but are not limited to, ensuring architecture design and development progress, satisfaction of requirements outside of performance or functional requirement sets, and meeting MOSA objectives set forth by DoD, the Army, and PEO Aviation. Implementing and meeting MOSA objectives will be an interdisciplinary approach across SE and technical team.

CUI 15

The SE and technical team will use an interdisciplinary approach to implement and meet MOSA objectives.

Program Office Technical Staffing Levels

The SUAS systems are at different phases of acquisition and therefore leadership staffs discretely for development, integration, and sustainment support and expertise, IAW their state of the acquisition life cycle.

Engineering Team Organization and Staffing

SUAS utilizes Integrated Product Teams (IPT) to manage its program. IPTs, by definition, make up of a myriad of stakeholders, and at a minimum, include a representative from each area of engineering, logistics, and business. IPTs are typically set with a recurring frequency for meeting whereas WGs are more informal, ad hoc, and seasonal. Each IPT is an empowered body whose responsibility is to manage and make decisions on a specific product, process, and resource. The organization assigns the appropriate elements of responsibility for planning, integrating, and controlling engineering activities.

Each engineering activity defines the technical objective, organization responsibility, timespan, planned resources, discrete work packages, and technical performance standards. IPT charters define the IPT objectives, along with the roles, responsibilities and authority for each IPT. The IPT members represent stakeholders of the government, contractor, subcontractor and independent entities. Each representative serves as a regular, active, productive IPT member with full rights and privileges to participate in all IPT activities and with full access to all engineering work products as defined in the respective IPT charter. The representatives all share responsibility for identification of emerging issues and for proper interpretation of management indicators and their implications in execution. IPTs/WGs may each hold different schedules and practices in regards to meeting frequency and whether meeting in person, virtually, via telecon or other means as technology and participant’s’ availability allows. Each IPT/WG will function and coordinate, as it deems necessary and appropriate to meet its unique goals and objectives. IPTs/WG can and will originate and dissolve in accordance with the demands of the program.

CUI 16

The following chart depicts the hierarchy of SUAS IPTs and WG within SUAS.

Figure 3.3-2 SUAS IPT/WG Hierarchy

It is not the intent of this SEP to provide a comprehensive list of all possible IPTs and WGs, nor to mandate the presence of every possible stakeholder. The intent is to provide a guide depicting the general hierarchy and structure of communication and controls for routine programmatic and engineering efforts within SUAS. SUAS leadership may stand up new IPTs and WGs as needed and may be temporary (e.g. a new tiger team to address a unique technical issue, etc.). Each IPT/WG may issue charters defining its goals and objectives, and identifying its chairperson and its specific list of stakeholder participants.

Participants may and will routinely include stakeholders outside of SUAS to include but not limited to AMCOM Safety, SRD for Airworthiness support, ATEC, as well as prime contractors and subcontractors affiliated with the production and sustainment of SUAS Products.

3.3.3.1 Products

The Product IPTs manage cost, schedule and performance of their specific product. The SRR, MRR, and LRR IPTs are each lead by a designated Assistant Product Manager (APM). These meetings occur on a weekly or bi-weekly basis or as determined appropriate by the APM. A team of SUAS staff including a Technical Lead, Systems Engineer (SE), Program Integrator (PI), and Logistician supports each APM. H-GCS is a major subsystem to each of those aforementioned UASs, and therefore does not have a designated APM. The H- GCS SME leads the H-GCS IPT within the Product Engineering Team. Software (SW) is a developed product that applies to all subsystems so it has its own IPT on this level. The SW SME leads the SW IPT within the Systems Engineering

CUI 17

Team. Any desired change to requirements or configuration, whether hardware or software, flow into the TIMs for consideration by the relevant Engineering and Test WG.

3.3.3.2 Technical Interchange Meetings (TIM)

TIMs include the Engineering WG and the Test WG. The Engineering WG initiates and addresses technical issues that need resolution. This could be a reliability shortcoming with a current configuration or a modernization agenda to achieve a new capability. The appropriate SMEs from the WGs for the addressed topic and are typically lead by the SE assigned to that specific product. WGs consider all aspects of the life cycle including design, development, prototyping, qualification, production, fielding, sustainment, and retirement. The Test IPT is led by the SUAS Test Lead and addresses the specific methods to show compliance for a new requirement or to qualify a new configuration and in the most expedient and affordable manner possible, whether by analysis, inspection, demonstration, or test. Once a proposed change has matured by gaining adequate data and defining the desired course of action (COA) and gained a level of confidence by the WG, it is then flowed to the appropriate Change Management Board.

3.3.3.3 Change Management

Change Management boards consist of the Requirements Change Board (RCB) and the Configuration Control Board (CCB). These are technical boards held to approve proposed changes. Voting members include the Tech Lead of the affiliated Product IPT, the SE Lead, the Test Lead, and the Airworthiness representative. The Tech Chief will approve/disapprove based on members’ votes and at the Tech Chief’s discretion.

RCBs address proposed requirement changes to existing System and Subsystem Specifications generated by SUAS and the final approval of a newly generated specification. Final signature approvals for SUAS developed Specifications are as follows:

• Prepared: SUAS Lead SE

• Concurrence:

o SUAS Product IPT Tech Lead o SUAS Test Lead

• Approval: SUAS Tech Chief

The product office processes the Engineering Change Proposals (ECP) via the CCB with final signature approvals required by the SUAS Tech Chief followed by

CUI 18

the SUAS PdL (or Deputy PdL if so delegated). For detailed processes and practices within the CCB, see the SUAS Configuration Management Plan (CMP).

3.3.3.4 Controls

Controls are set in place to ensure the team identifies all program risks and safety hazards. The Risk Review Board (RRB) typically meets monthly to review newly proposed risks and updates to existing risks for approval. APMs, with the assistance of selected action officer SMEs, will brief the risk status and updates affiliated with their products to the RRB.

The RRB will consist of the following:

1. SUAS PdL

2. SUAS Deputy PdL

3. SUAS Tech Chief

4. SUAS Log Chief

5. SUAS Business Chief

6. SUAS Lead SE

The SUAS safety program operates in accordance with PEO Aviation Policy 18-

20. The System Safety Working Group (SSWG) typically meets twice per calendar year and ad hoc to ensure appropriate coordination of the System Safety concerns and to assist in identification, coordination, tracking, and correction of any System Safety hazards. The SUAS Safety Engineer leads the

SSWG.

3.3.3.5 Governance

The Program Management (PM) IPT, led by the SUAS PdL, manages, integrates, and controls SE products and processes across the subordinate IPTs.

In order to adjudicate disagreements within and across IPTs, the PM IPT presents trade-off decisions to the PdL and delegates action to sub IPTs. The PM IPT tracks and manages open actions at this forum on a weekly basis to ensure optimal execution of the program. By virtue of cross-functional membership, the PM IPT and all sub IPTs seek to involve every stakeholder in each action’s consideration. As issues arise, IPTs may assign tasks to individual WGs. If an IPT cannot come to a unified solution on an issue, or if a high-profile issue requires PM input, IPTs may raise the issues to the SUAS PM IPT for tracking and direction. The PM IPT is the top-level IPT for the SUAS Product Office.

CUI 19

3.4 Technical Performance Measures (TPM) and Metrics

SUAS identified TPMs for the program early in the lifecycle to help the system achieve the Key Performance Parameters (KPPs) identified in the Capability Production Document (CPD). Table 3.4-1 lists the KPPs, Table 3.4-2 lists the Key System Attributes (KSAs), and Table 3.4-3 lists the Additional Performance Attributes (APAs).

Table 3.4-1 Key Performance Parameters (KPPs) Characteristic Threshold (THD) Objective (OBJ)

Force Protection Detect targets, develop information, create maneuver space, and engage the enemy on favorable terrain

OBJ=THD

Net Ready

25m TLE 10m TLE

<5 minutes <1 minute

AES 128 Encryption FIPS 140-2 Encryption

External Reporting Displayed on COP

Flight Capability LRR = 2 hours and 10km

MRR = 1.5 hours and 10km SRR = 0.5 hours and 3km

LRR = 8 hours and 30km MRR = 3.5 hours and 20km SRR = 0.75 hours and 5km

Payload Capability

MRR / LRR @ 500ft AGL MRR / LRR @ 750ft AGL 90% PD Man Sized Target 95% PD Man Sized Target Day = 550m, Night = 350m Day = 900m, Night = 700m MRR / LRR @ 500ft AGL

90% PD Vehicle MRR / LRR @ 750ft AGL

95% PD Vehicle Day = 700m, Night = 550m Day = 1100m, Night = 900m MRR / LRR @ 500ft AGL

90% PR Vehicle MRR / LRR @ 750ft AGL

95% PR Vehicle Day = 600m, Night = 450m Day = 1000m, Night = 800m

SRR @ 200ft AGL SRR @ 500ft AGL 90% PD Man Sized Target 95% PD Man Sized Target Day = 300m, Night = 200m Day = 600m, Night = 450m

SRR @ 200ft AGL 90% PD Vehicle

SRR @ 500ft AGL 95% PD Vehicle

Day = 400m, Night = 300m Day = 800m, Night = 600m SRR @ 200ft AGL 90% PR Vehicle

SRR @ 500ft AGL 95% PR Vehicle

Day = 250m, Night = 150m Day = 600m, Night = 450m

Weight / Transportability (System)

LRR = ≤32lbs MRR = ≤21lbs SRR = ≤19lbs

LRR = ≤20lbs MRR = ≤12lbs SRR = ≤8lbs

Operational Availability 85% 90%

CUI 20

Table 3.4-2 Key System Attributes (KSAs)

Center Field of View Target Location Error

LRR / MRR = 25m between 250m and 400m slant range

SRR = 25m between 0m and 250m slant range

LRR / MRR = 10m between 250m and 400m slant range

SRR = 10m between 0m and 350m slant range

Data Link

Omni Directional Antenna Omni Directional Antenna NLOS = 2km within 7m of opening

LRR / MRR = 5km SRR = 3km

LRR / MRR = 10km SRR = 5km

AES-128 Encryption FIPS 140-2 Encryption

16 DDL Channels 32 DDL Channels

UA Position Information Transmit location for display Transmit location, heading, altitude, and airspeed to update the COP

Acoustic Signature LRR / MRR @ 500ft AGL = Inaudible with 65dBA noise SRR @ 200ft AGL = Inaudible with 65dBA noise

LRR / MRR @ 400ft AGL = Inaudible with 35dBA noise

SRR @ 100ft AGL = Inaudible with 35dBA noise

Payloads

FMV containing day, night (passive infrared) and laser illuminator OBJ=THD +

LRR/ MRR / SRR

Moving target indicator

LRR/ MRR / SRR

CBRN detection

Multispectral

SIGINT / MASINT

LRR / MRR

Still image > image from FMV

Illuminate ~25ft dia area @ 200m slant range

LRR / MRR

Illuminate ~10ft dia area @ 600m slant range

Laser Target Marker

SRR

FMV ≥ 20/20 Vision @ 3ft away

View underside of object with a 30 degree FOV

SRR

Optical Zoom

System Training Operated and field level maintained by trained and certified operators OBJ=THD

CUI 21

Table 3.4-3 Additional Performance Attributes (APAs)

CBR Contamination Survivability

Operate in MOPP IV gear OBJ=THD

LRR = survive non-destructive decontamination MRR and SRR = N/A

LRR = OBJ= THD

MRR and SRR survive non-destructive decontamination

Conduct an 8 hour mission without failure due to contamination OBJ=THD

UA Locator NA

Transmit encrypted beacon up to 24 hours at 5km using standard MGRS format

Strobe / flashing lights operational up to 24 hours after UA loss

Mission Altitude LRR / MRR = 500ft AGL ± 50ft SRR = 200ft AGL ± 50ft

LRR / MRR = 750ft AGL ± 50ft SRR = 500ft AGL ± 50ft

Mission Planning

Program mission parameters OBJ=THD +

Establish Waypoints, 5 minimum Establish Waypoints, 25 min

(Launch point, In-route, Objective, Sensor) Avoid Waypoints, 25 min

Create new mission in air OBJ=THD

Store at least 3 missions Store at least 8 missions

Load a mission from external storage OBJ=THD

Allow the operator to change the map coordinate format OBJ=THD

H-GCS Display

Daylight readable without the use of sunshield OBJ=THD +

Display real time FMV / sensor / telemetry data Tactile / verbal feedback

NVG compatible Multi display manipulation

Brightness / contract control Rapid brightness / contrast control

Connect to external monitor OBJ=THD

CUI 22

Another activity within TPM is identifying the metrics for assessing the progress of development of critical interfaces and meeting MOSA objectives for those interfaces. The SE team will implement metrics through the MBSE environment (Cameo EA) that is resident on the PEO Aviation Enterprise network. These metrics will measure aspects of the architecture and interfaces to comply with MOSA objectives and provide quantitative measures of progress towards those objectives. The SE team will be responsible for developing those measures and metrics in coordination with the PM UAS Technical Management Division and PEO Aviation MOSA Transformation Office (MOSA TO). These measures would include the use of open standards on interfaces in the system. The SE team would work within the appropriate WG or IPT to implement these measures with the contractor and other supporting vendors developing or working on SUAS products.

One of these open standards utilized is the FACE Technical Standard for SUAS software products. In order to meet MOSA objectives, the measures would focus on openness and modularity aspects of the items in development. These aspects focus on loose coupling and tight cohesion of the individual items or products in order to achieve the modularity objectives of MOSA. H-GCS software products currently implement appropriate FACE requirements.

4 Technical Activities and Products

Figure 4.0-1 SUAS Schedule

CUI 23

4.1 Planned SE Activities for the Next Phase

SRR

SUAS plans to undergo an iterative development cycle for SRR of three (3) Tranches to achieve the full SRR capability as specified in the RPUAS CPD. The SRR IPT initiated Tranche 1 as a minimal viable capability using a relatively short list of twenty-two (22) select requirements. Tranche 2 will be extensively more comprehensive and will pursue all threshold requirements from the CPD. Tranche 3 will pursue all objective requirements from the CPD. The SRR IPT will evaluate new features and capabilities to enhance performance to determine trade space of each effort against programmatic constraints. SUAS awarded the Tranche 1 down select to Skydio for RQ-28A with production decision 3QFY21 and Materiel Release targeted for 4QFY21. The Tranche 2 System Specification is underway with its down-select process beginning with DIU 3QFY21.

Sustainment of SRR T1 will include monitoring mishaps and analyzing failure rates to verify this configuration is affordable and reliable. If the monitoring requires a change, the ECP process, detailed in the SUAS Configuration Management Plan, ensures approval of required changes to make the system more reliable in conjunction with the Life Cycle Sustainment Plan (LCSP). In addition, the SRR program complies with the Army’s two-level maintenance concept in accordance with AR 750-1 (Army Materiel Maintenance policy). The Field Maintenance concept consists of Non-specific Military Occupation Specialty (MOS) Soldiers as Unmanned Aircraft Systems Crew/Operators of the system to perform all of the Field Level maintenance requirements. The SRR sustainment support concept provides reparable exchange, consumable repair parts, off-system component repair, and return-to-supply through the Army Field Maintenance Directorate (AFMD) Inventory Control Point (ICP). SUAS has identified, planned, and executed actions to manage and acquire repair and spare parts. The SUAS Product Office has established AFMD as the ICP for all SUAS products. As the ICP, AFMD performs issuance, receiving, disposal, and inventory management of parts. SUAS procures spare components and repair parts through the appropriate Original Equipment Manufacturer (OEM) on an Indefinite Delivery/Indefinite Quantity (IDIQ) contract.

MRR

The RQ-11B Raven is being modified by Modification Work Order (MWO) to become the RQ-11C MRR. The MWO reflects the replacement of the RQ-11B radio and avionics module and requires a new antenna incorporated in a new tail boom that has a slightly taller vertical stabilizer and rudder. Aerovironment is developing ECPs to reflect the drawing and part number changes from RQ-11B to RQ-11C MRR. The engineering team is monitoring the progress of these ECPs and teaming with the logistics team in developing and verifying the MWO. As a

CUI 24

part of the RQ-11C MRR development, the engineering team is working with the test team to complete ground and flight testing to verify the performance, integration, and backwards compatibility of the new hardware and software IAW the MRR Test and Evaluation Master Plan (TEMP).

LRR

The Robotics Requirements Division (RRD) of the Maneuver Center of Excellence (MCoE) is the new user representative for SUAS. RRD is in the process of developing the LRR CPD Annex. Additionally, initial market research has taken place and will continue to take place while expected funding for LRR is in FY23 with fielding anticipated in FY26-27.

Cybersecurity

SUAS will continue to include and add cybersecurity into all SUAS systems.

The SUAS program employs a tailored Risk Management Framework (RMF) process IAW NIST SP 800-37 to track Cybersecurity issues. RMF describes the DoD process for identifying, implementing, assessing, and managing cybersecurity capabilities and services, expressed as security controls, and authorizing the operation of Information Systems (IS) and Platform Information Technology (PIT) systems.

RMF brings a risk-based approach to the implementation of cybersecurity, supports cybersecurity integration early, throughout the system lifecycle, promotes reciprocity to the maximum extent possible, and stresses continuous monitoring IAW NIST SP 800-137. RMF replaces the DoD Information Assurance Certification and Accreditation Process (DIACAP) and adopts the term cybersecurity in place of information assurance.

The RMF process is a United States federal government policy providing standards to help secure information systems. SUAS will secure and configure all systems IAW applicable DoD policies and security controls and properly documented in the authorization package. The UAS Organization-Information System Security Manager, under the direction of the Authorizing Official, will review the authorization package for acceptance or connection into an authorized computing environment.

The RMF process consists of six steps:

1. Categorize System.

2. Select Security Controls.

3. Implement Security Controls.

CUI 25

4. Assess Security Controls.

5. Authorize System.

6. Monitor Security Controls.

This process parallels the system life cycle, with the initiation of the RMF activities at program or system inception (e.g., documented during capabilities identification or at the implementation of a major system modification).

In addition to the RMF process, Soldier UAS will secure systems using system security practices defined in the (1) DoD Cybersecurity Test and Evaluation Guidebook, the (2) PEO Aviation Operational Survivability through Cyber Resilience (OSCR) Cyber Integration Handbook and (3) NIST SP 800-160 Systems Security Engineering - An Integrated Approach to Building Trustworthy Resilient Systems.

Systems Security Engineering (SSE) is a specialty discipline of systems engineering comprised of hardware/software assurance, anti-tamper, and supply chain risk management (SCRM). SCRM applies strategies to manage risks along the supply chain, which reduce vulnerabilities and ensure continuity. The SRR OEM provided a Bill of Materials (BOM) that included all parts, manufacturers, and where OEMs/subs build the parts. The SUAS Program Protection Plan (PPP) supports SSE by providing an engineering risk/cost trade-off analysis that aids in the determination of security requirements.

Cyber Table Top Assessments (CTTAs) are an effective way to assess the resilience of system designs in all phases of development and deployment. SRR Tranche 1 went through a CTTA in which Redstone Test Center provided valuable feedback that aided in creating requirements for SRR Tranche 2.

4.2 Requirements Development and Change Process

SUAS tracks all performance requirements through a database. This allows for ease of tracking changes and monitoring traceability of these requirements back to their sources. The specification tree for SUAS systems follows the architecture diagram depicted in Figure 2.1-3 SUAS Architecture Diagram where system specifications then branch out into subsystems specifications. SUAS is currently transitioning requirements from a Cradle database to the Cameo MBSE software suite for management. Nonetheless, SUAS models all requirements for the SRR T1 and T2 in-house by utilizing Cameo.

The SW IPT assesses Software Change Requests (SCRs) and any Problem Change Requests (PCRs) impacting SW. The team aligns all proposed changes with either existing contract scope or prioritizes for new funding and scope within a

CUI 26

new contract, as appropriate. During the assessment process, the team conducts a change impact analysis to determine impact on airworthiness and safety.

The SW IPT assigns a Category Level to each SCR/PCR to determine priority for corrective action, as follows:

• Level 1: Safety/Flight critical

• Level 2: Mission Critical

• Level 3: Mission Critical with approved work around

• Level 4: Non-critical

• Level 5: Administrative

The CCB maintains technical authority over the approved product baseline and is responsible for merging new capability and/or improvements (configuration changes) into the product baseline using SE and CM methodology, processes, and procedures.

4.3 Technical Reviews and Test Events

SUAS holds Technical reviews to review and approve requirements and designs for systems. The team may hold these reviews in parallel with or following their associated development/ integration efforts. Reviews are to be event-driven, thus each review is held only when its prerequisite entry criteria is complete. The intent is to use systems engineering technical processes to evolve the new functionality and security into system level designs and then preliminary designs into detailed designs.

SUAS will hold technical reviews after each level of development to check design maturity, review technical risk, security risk, and determine whether to transition…