Section_J _Atch_I _Tech_Svs_Draft_SEP_2015_-_Rev_10.pdf

UNCLASSIFIED

UAS-00004

Shadow RQ-7B Tactical Unmanned Air System (TUAS)

ACAT Level IC

Production and Deployment

System Engineering Plan (SEP), R1 (ASA(AL&T) Coordination Draft)

Supporting the Operations, and Sustainment Program

TBD November 2015

SEP DECISION APPROVAL:

Hon. Heidi Shyu DATE

ASA(AL&T)

DISTRIBUTION STATEMENT D. Distribution Authorized to Department of Defense and U.S. DoD Contractors only; IAW U.S. Army Shadow 200 Tactical Unmanned Aircraft System (UAS) Security Classification Guide, 17 May 11. Other requests shall be referred to the UAVS Project Office, ATTN: SFAE-AV-UAV, Redstone, AL 35898 ii

(This page intentionally left blank) iii

SYSTEM ENGINEERING PLAN (SEP), R1

FOR THE

SHADOW RQ-7B PRODUCTION PROGRAM

TBD 2015

SUBMITTED BY:

JASON P. LUCAS DATE JAMES T. BURGESS DATE

Chief Engineer, Shadow Lieutenant Colonel, AV Shadow TUAS Program Manager Ground Maneuver

CONCURRENCE:

MR. LARS ERICSSON DATE COURTNEY P. COTE DATE

Chief Colonel, AV Tech Management Division, UAS Project Manager, UAS

MR. RAY K. SELLERS DATE BG ROBERT L. MARION DATE

Assistant PEO for Engineering and Technology Program Executive Officer PEO Aviation PEO Aviation iv v

TABLE OF CONTENTS:

1 INTRODUCTION 1

1.1 Program Description & Applicable Documents 1

1.2 Applicable Documents 2

1.3 PROGRAM BACKGROUND 3

2 PROGRAM TECHNICAL REQUIREMENTS 7

2.1 Architectures and Interface Control 7

2.1.1 Architectures 7

2.1.2 Interface Control 10

2.2 Technical Certifications 12

3 ENGINEERING RESOURCES AND MANAGEMENT 13

3.1 TECHNICAL SCHEDULE AND SCHEDULE RISK ASSESSMENT 13

3.2 ENGINEERING RESOURCES AND COST/SCHEDULE REPORTING 15

3.3 ENGINEERING AND INTEGRATION RISK MANAGEMENT 15

3.4 TECHNICAL ORGANIZATION 17

3.4.1 Government Program Office Organization 17

3.4.2 Program Office Technical Staffing Levels 18

3.4.3 Contractor Program Office Organization 18

3.4.4 Engineering Team Organization and Staffing 19

3.5 RELATIONSHIPS WITH EXTERNAL TECHNICAL ORGANIZATIONS 23

3.6 TECHNICAL PERFORMANCE MEASURES AND METRICS 23

4 TECHNICAL ACTIVITIES AND PRODUCTS 27

4.1 PREVIOUS PHASE SYSTEM ENGINEERING ACTIVITIES 27

4.2 NEXT PHASE SYSTEM ENGINEERING ACTIVITIES 27

4.3 REQUIREMENTS DEVELOPMENT AND CHANGE PROCESS 28

4.3.1 Analysis and Decomposition 29

4.3.2 Requirements Management and Change Process 33

4.4 TECHNICAL REVIEWS 38

4.5 CONFIGURATION AND CHANGE MANAGEMENT PROCESS 40

4.6 DESIGN CONSIDERATIONS 42

4.7 ENGINEERING TOOLS 43

vi

ANNEX A - ACRONYMS 45

Appendix A - Work Breakdown Structure 51 Appendix B - Technical Readiness Review Products and Criteria 57 vii

Mandated Tables and Figures

Tables Table 1.1-1 SEP Update Record 1 Table 1.1-2 Applicable Documents 2 Table 2.1-1 Required Interface Memoranda of Agreement 3 Table 2.2-1 Technical Certifications 12 Table 3.4.4-1 Engineering Team Details 19 Table 3.4.4-2 IPT Team Details 21 Table 3.6-1 Technical Performance Measures and Metrics 25 Table 4.3-1 JCCB Baseline Controls 30 Table 4.4-1 Technical Review Details 39 Table 4.6-1 Design Considerations 42 Table 4.6-2 R&M Activity Planning and Timing 42 Table 4.7-1 Engineering Tools 43

Figure 1.1 Program Background 4 Figure 1.2 System Description 5 Figure 2.1-1 Functional Architecture 8 Figure 2.1-2 UGCS/UGDT Physical Architecture 9 Figure 2.1-3 PGCS/PGDT Physical Architecture 10 Figure 2.1.2-1 External Interfaces 11 Figure 2.1.2-2 Subsystem Interfaces 12 Figure 3.1-1 System Technical Schedule 13 Figure 3.1-2 Example Engineering Release Schedule 14 Figure 3.3-1 Risk Management Process Diagram 16 Figure 3.3-2 Risk Cube 16 Figure 3.4.1-1 Product Office Organization 17 Figure 3.4.3-1 Contractor Functional Organization 18 Figure 3.4.4-1 IPT/WG Team Hierarchy 19 Figure 4.3.1 Cybersecurity and Systems Engineering Integration 29 Figure 4.3.1-1 Requirements Decomposition and Control 31 Figure 4.3.1-2A RQ-7B Specification Tree 32 Figure 4.3.1-2B RQ-7BV2 Specification Tree 32 Figure 4.3.2A IJCCB Process 34 Figure 4.3.2B System Engineering Process 36 Figure 4.3.2C Development and Verification Process Relationship 37 Figure 4.5-1 Configuration Management Process Diagram 41 viii

1 Introduction

1.1 Program Description

The prior approved System Engineering Plan (SEP) dated 23 February 2007 supported the final production phase. This System Engineering Plan (SEP) continues the overall technical approach to manage system engineering activities for the Shadow RQ-7B Tactical Unmanned Air System (TUAS) Program. The program is post Milestone C and in its sustainment phase. There are no future milestones that this SEP supports. The Army placed the last of its authorized 102 systems under contract during 2009. This SEP focuses on operations, sustainment, and the modifications program documented in the approved Acquisition Strategy dated 20 February 2013. The overall technical approach is primarily driven by applying these systems engineering principles via engineering service contracts to achieve incremental performance improvements and to maintain interoperability and cybersecurity.

This SEP revision has three goals:

First, this SEP supports the approved Acquisition Strategy.

Second, this SEP is the blueprint to conduct, manage, and control the technical aspects of the acquisition program.

Third, this SEP provides the guidelines for the contractors and the Joint Systems

Integration Laboratory (JSIL) to use when developing and implementing the supporting System Engineering Management Plans (SEMPs).

This SEP will be updated, as needed, to reflect acquisition policy changes, decision memoranda, and to ensure compliance with the latest policy and regulatory changes.

Table 1.1-1 SEP Update Record

Revision Date Change Log and Reason

Approved By

Basic 5 March 2007 Implement OSD and DA policy

PEO Aviation

(ACAT II

Milestone Authority)

1.0 TBD November

Support 7BV2 material release and align with new acquisition strategy.

PEO Aviation

1.2 Applicable Documents

This SEP is used in conjunction with the following technical documents:

Table 1.1-2 Applicable Documents (Specifications per JCCB ECP approval baseline.)

Document Document Number Date TUAV Operational Requirements Document (ORD)

N/A 29 August 2003

TUAV Performance Specification

R38431-00003G March 2009

TCDL (RQ-7BV2) Performance Specification

R39489-00064A October 2012

IRS External Interfaces for the TCDL Tactical Unmanned Aerial Vehicle

R39489-00065A November 2012

IRS Subsystem Interfaces for the TCDL Tactical Unmanned Aerial Vehicle

R39489-00066B April 2014

Performance Specification for the TCDL Air Vehicle (AV) Subsystem

R39489-00115C April 2014

Performance Specification for the TCDL Portable Ground Control Station (PGCS) Subsystem

R39489-00116C June 2014

Performance Specification for the TCDL Portable Ground Data Terminal (PGDT) Subsystem

R39489-10001G June 2014

Performance Specification for the Universal Ground Control Station (UGCS)

R39593-00036E February 2011

Performance Specification for the Universal Ground Data Terminal (UGDT) Subsystem

R39278-30003C April 2010

Performance Specification for the TCDL Launcher (LAU) Recovery (REC) Subsystem

R39489-00434B May 2014

Overarching IOP Version 1.5.5 October 2008 Common Data Link (CDL) IOP Version 2.0 October 2010 Performance Specifications for the Standard Common Data Link (Std-CDL) Waveform

PRF 7681990G Nov 2007

TUAS Acquisition Strategy Report

N/A February 2013

UAS IJCCB Charter UAS-MISC-001C April 2014 JCCB Charter UAS-GM-001 December 2012

1.3 Program Background

The Tactical Unmanned Aircraft Systems Product Office within the Unmanned Aircraft Systems (UAS) Project Office (PO) is responsible all RQ-7B system acquisition, systems engineering, and sustainment.

The RQ-7B Tactical Unmanned Aircraft System (TUAS) provides superior situational awareness, wide-area target acquisition, and high value target (HVT) tracking to conduct both shaping and decisive operations. A complete TUAS consists of Ground Control Stations, Ground Data Terminals, Aircraft, Launch/Recovery Equipment and Mobile Maintenance Facilities. The RQ-7B provides near real-time responsive Reconnaissance, Surveillance, and Target Acquisition (RSTA) capability against defended areas in close proximity to friendly forces.

The original acquisition strategy, consistent with guidance at the time, emphasized Commercial-off-the-Shelf (COTS) technology and a rapid fielding at a minimum cost.

This strategy resulted in successful fielding three years after system selection with a successful Systems Capability Demonstration in November 1999 and Initial Operating Capability in October 2002. The Joint Requirements Oversight Council (JROC) approved the Brigade/Unit of Action Tactical Unmanned Aircraft Vehicle (TUAS) Operational Requirements Document (ORD) in June 2003. The ORD specified a blocking concept with Thresholds required for Production and Objective requirements for three Block Upgrades, (1) Tactical Common Data Link (TCDL) Modifications, (2) Payload Modifications, and (3) System Modifications.

The Army deployed Shadow systems in support of Operation Iraqi Freedom (OIF) beginning in March 2003. Shadow systems also supported Operation Enduring Freedom (OEF) with over twenty systems deployed in Afghanistan. During these operations, the Product Office focused on Engineering Change Proposals designed to meet Urgent Operational Requirements as well as software and hardware fault resolution. The result is a robust system that has flown over 900,000 hours – 90% in combat.

In 2009, the Product Office placed the last of the authorized 104 systems on contract, ending the Production phase of the acquisition. In 2010, the Army G8 established a RQ- 7B UAS MODS Aircraft Procurement Exhibit approving several modifications for development and production. These modifications will be incrementally integrated, tested, and fielded in accordance with the technology readiness and funding profile. The major modifications are grouped as follows: (1) v2 Modifications (include TCDL and Encryption), (2) Payload Modifications, and (3) System Modifications.

The original RQ-7A system completed Initial Operational Test and Evaluation (IOT&E) during May 2002, supporting a full-rate production (FRP) decision in September 2002.

The baseline RQ-7B system provides 12 hours of continuous operations on station within a 24-hour period, with a capability to operate any 12 hours (non-continuous) within a 24-hour period if required by the commander. The system has the capability of surge operations for 18 hours within a 24-hour period for three consecutive days, with the following day being limited to eight hours of operations. Rapid set-up and tear-down times and transfer of air vehicle control between ground stations supports ground maneuver brigade movement and fire support during movement.

A limited customer or user test conducted by ATEC during May 2004 evaluated target location error improvements. A Limited User Test (LUT) during June 2010 evaluated laser designator, range finder, and communications relay improvements.

The system was re-qualified and then evaluated during a May 2014 Follow-On Operational Test (FOT) to assess Tactical Common Data Link (TCDL), Universal Ground Control Station (UGCS), Universal Ground Data Terminal (UGDT), larger wing, and electronic fuel injection engine improvements. These improvements are being fielded as part of a retrofit program.

The 7BV2 system and aircraft increases endurance to 7 hours on station at 50 km and increases the maximum take-off weight when configured with the 20.2 foot wing. It also provides Ku Band Type 1 command/control and payload video encryption and implements the Tactical Common Data Link (TCDL) messaging and waveform.

The program background and timeline is summarized in Figure 1.1 below.

Figure 1.1 Program Background

The system is depicted in Figure 1.2.

Figure 1.2 System Description

The Ground Maneuver Product Office also acquires products through the JSIL. The following products are developed, produced, and sustained as described in this SEP:

1) Universal Mission Simulator (UMS). Simulates the physical and functional Universal Ground Control System (UGCS) characteristics to enable operator flight currency proficiency training.

2) Commander’s Work Station (CWS). Implements a network based open architecture approach to enable applications to access a ground control station and securely distribute aircraft and payload operator information and payload products.

3) Multiple Unified Simulation Environment (MUSE). Stimulates tactical software to enable UAV flight in a simulation environment for training purposes.

4) Shadow Interactive Multimedia Instruction Suite (SIMIS). High fidelity graphic and virtual environment training application that runs on multiple operating systems including Windows, MAC, Web, Android, and iOS devices.

5) Data Acquisition System (DAS). The DAS is a mobile test monitoring, data acquisition, archival, and reporting system that captures Shadow aircraft operator and payload operator displays, payload video, message traffic, and meteorological data.

6) Open Architecture for Telemetry and Instrumentation Systems (OATIS).

Aircraft instrumentation capturing digital and analog flight test data.

7) Hardware in the Loop Simulator (HILSIM). The HILSIM provides a high fidelity 6 degree freedom (6-DOF) aircraft aeronautical model and enables system interconnections to evaluate tactical hardware and software in a ground test environment.

8) Post Production Software Support (PPSS). PPSS programs helps sustain fielded tactical software by addressing obsolescence, information assurance, and corrections necessary for continued fleet operations.

2 Program Technical Requirements The TUAV System provides Reconnaissance, Surveillance, and Target Acquisition (RSTA) support to the ground maneuver commander. The system additionally provides cooperative engagement, remote designation, 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 charts and narrative describe our RQ-7Bv2 architecture. This subject is divided into functional, physical, and external interface discussion.

2.1.1 Architecture.

The system functional architecture is depicted in Figure 2.1-1 below. The former RQ-7A and RQ-7B legacy functional architecture is largely the same, but the RQ-7Bv2 system features digital communications for aircraft command and control. The launch and recovery subsystem, the weather station, and the external pilot box (engineering special test equipment) are unchanged and require an analog to digital communications conversion to communicate with the Universal Ground Control Station (UGCS) and new Portable Ground Control Station (PGCS). The aircraft uses a primary and secondary data link for two-way communications with the ground. The primary data link utilizes the Mini-C and Mini-T modems for Ku band communications with messages in STANAG 4586 format. The Ultra High Frequency (UHF) secondary data link, used as a backup for primary link loss and for launch and recovery operations, uses the same UHF modem utilized by legacy AVs. The data is in the legacy 52-byte format for the Command and Control (C2) messages.

Figure 2.1-1: System Functional Architecture

Figure 2.1-2 depicts the UGCS/UGDT physical architecture. The Shadow v2 Vehicle Specific Module (VSM) architecture splits into two separate VSMs: the Ground VSM (GVSM) and the Air vehicle VSM (AVSM). The GVSM is a software module that resides on the ground and interfaces with the:

Common User Control System (CUCS)

Display VSM

Tactical Automatic Landing System (TALS)

Pilot Box

Weather Station

UGDT (Primary Data Link)

Shadow 200 UHF Modem (Secondary Data Link)

The AVSM is a software module that resides in the ASIM on the Shadow 200 AV and interfaces with the:

Airborne Computer Equipment (ACE) Mission Processor

Mini-C Airborne Data Terminal (ADT) (Video Encoder)

Mini-T ADT (Primary Data Link)

The AV ACE box consists of a Payload Processor, Mission Processor, and Flight Processor. The diagrams below show the architecture of the RQ-7Bv2 system.

Figure 2.1-2: UGCS/UGDT Physical Architecture

Figure 2.1-3: PGCS/PGDT Physical Architecture

2.1.2 Interface Control.

External interfaces are under configuration control through the External Interfaces Specification R39489-00065 and are depicted in Figure 2.1.2-1. UAS Inter-Operability Profiles (IOP) are also implemented as coordinated with the Integrating Joint Configuration Control Board (IJCCB). These are represented as “EI-15” in Figure 2.1.2- 1.

Figure 2.1.2-1 External Interfaces

Internal interfaces are under configuration control through the Subsystem Interfaces Specification R39489-00066 and are depicted in Figure 2.1.2-2.

Figure 2.1.2-2 Subsystem Interfaces

2.2 Technical Certifications

Certification requirements are summarized in Table 2.1 below.

Table 2.2-1 Technical Certifications Certification POC Certification

Authority Certification

Date Clinger-Cohen PMO IASO CIO G-6

18 Dec 2014 Army Interoperability

PMO C4I POC

CIO G-6

Spectrum Supportability

PMO Spectrum Manager

ASMO

Multiple:

correlates to RFE

RMF/Information Assurance

PMO IASO

CIO G-6

Multiple: varies by accreditation boundary Future Airborne

Capability Environment

(FACE)

PMO P3I POC

TBD

None: future intent

3 Engineering Resources and Management

3.1 Technical Schedule and Schedule Risk Assessment

The Product Management Integrated Product Team (PM IPT) performs schedule planning, resourcing, and execution. Strategic tasks trace to approved strategy, acquisition, and funding documentation. Functional tasks are carried out by functional IPTs – the System Engineering IPT is one of five. The other IPTs cover logistics, contracts, production, system safety, and test. Section 3.4 discusses the organization and IPTs that participate in SEP implementation.

Program planning and integrated schedule management is implemented by the PM IPT.

Critical path analysis techniques are used to manage predecessor and successor events to completion based on resource prioritization and management attention.

Figure 3.1-1 presents the over-arching technical schedule. In general, legacy and 7BV2 common subsystems (the engine is an example) will both benefit from capability improvements. Additionally, the legacy system will address obsolescence and interoperability improvements to ensure its continued mission effectiveness and sustainment until it is retired. Problems identified via field surveillance will also be addressed. New payloads and unique capability improvements will be integrated into the 7BV2 system using system engineering practices as documented in this plan.

Figure 3.1-1 System Technical Schedule (as of Feb 2015)

PREDECISIONAL – FOR OFFICIAL USE ONLY – Exemption 5

POM 16-20

Shadow RQ-7B 30-Year Plan

UNCLASSIFIED / FOUO

FY15 – FY24

A

Decision Points

Milestones

New Start

Production to Sustainment Transition Point

Divestment (Div)

System Acquisition Framework

Shadow v1 Legacy

DEMIL

Legacy Sustainment (20yr Life)

Legacy Reliability Improvements

Begins FY22, Ends FY28

DEMIL

OSGCS,PGCS,GDT, Generators

Capabilities

• Reduced acoustic signature

Shadow v2 Modifications

Begins FY32, Ends FY40

DEMIL

Shadow v2 Sustainment (20yr Life)

Shadow v2 Modifications

Engine Fielding

SOF AV Mod SOF Fielding

Army AV Mod Army Fielding

Capabilities

• Increased Automation (reduced manpower)

• Increased Survivability

• Improved payloads

Future Group III

UAS

FY 28 FY 32 FY 40

Future UAS Sustainment Future UAS Dev

Future UAS Proc

Material Solution Analysis

Technology Development

Engineering and Manufacturing Development

Production and Deployment

A B C

IOC

FOC

Operation and

Support

Capabilities

• Increased autonomy

• Increased endurance

• Dual payload capability

FY25 – FY34 FY35 – FY45PROGRAM

As stated earlier in SEP section 1.1: the overall technical approach is primarily driven by applying systems engineering principles via engineering service contracts. The product office averages twelve (12) to (14) engineering projects covering improvements, corrections, obsolescence, and information assurance/C4I updates per year. It isn't practical to incrementally depict the applicable engineering milestones within this SEP.

Figure 3.1-2 represents an example schedule. We block these separate projects into an aggregate configuration. This "blocking" strategy minimizes disruption to field units and aligns our training, technical manual, and logistics support. The “V2 Release 4” schedule is an example of this “blocking” strategy. It is dynamic: if an individual effort can’t complete on schedule (including requisite qualifications and logistics support elements) then it gets moved to the next scheduled release block.

Note that multiple contractors or government agencies might be involved in this process.

Each contractor or government agency participant that develops and qualifies a change will implement this SEP through an approved System Engineering Management Plan (SEMP) to ensure conformity with SEP requirements and to ensure all participants engage in a common methodology using the same criteria, tools, and procedures.

Figure 3.1-2 Example Engineering Release Schedule (as of Aug 2015)

3.2 Engineering Resources and Cost/Schedule Reporting

Engineering activities are included in each of the three contract types subject to this system engineering plan: production, engineering services, and performance based logistics. An overarching Integrated Master Schedule is maintained via the PM IPT.

However, each contract also has engineering resources aligned to a common Work Break-down Structure (WBS) and cost/schedule reporting criteria are implemented by each contract. The systems engineering contract, in particular, applies these criteria to each project or product improvement documented as a sub-engineering services memorandum.

Each product, reliability, obsolescence, or sustainment improvement implements an IMS to identify tasks and resources. Each schedule is based on a WBS following the MIL- STD-881, Appendix H (Unmanned Aircraft Vehicle) guidelines. It is provided as Appendix A to this plan. Each contractor or government agency that produces a configuration change – as discussed in Section 3.1, above – will adhere to Appendix A of this SEP.

Each contractor or government agency participating in systems engineering development activities under this SEP will tailor a common WBS at level 4 and below to meet Earned Value Management System (EVMS) requirements. This level of decomposition enables work package status tracking and cost and schedule performance reporting.

As depicted in the WBS at Appendix A, integrated product teams are included and subject to control system criteria as they manage their work and budgets.

Product office responsible engineers assess these reports and brief the product manager monthly to address issues, risks, and receive guidance.

3.3 Engineering and Integration Risk Management

The Program Manager, Unmanned Aircraft System process is based on the “DoD Guide to Risk Management” and is levied on each of the product teams. This SEP implements this policy as documented in Figure 3.3-1. Responsible engineers brief the product manager monthly to adjudicate new risk findings, approve and track mitigation plans, and receive additional program management guidance.

Figure 3.3-1 Risk Management Process

Figure 3.3-2 Risk Cube

Low Likelihood (21-40%)

Likely (41- 60%)

Highly Likely (61-80%)

Near Certainty (81-100%)

Likelihood Rating

Low Likelihood

(21-40%)

Likely (41-60%)

Highly Likely (61-80%)

Near Certainty (81-100%)

Likelihood Rating

Minimum impact.

Minimum oversight needed to ensure risk remains low.

Low

Some disruption.

Different approach may be required. Additional management attention may be needed.

Moderate

Unacceptable. Major disruption likely.

Different approach required. Priority management attention required.

High

Assessment

Minimum impact.

Minimum oversight needed to ensure risk remains low.

Low

Some disruption.

Different approach may be required. Additional management attention may be needed.

Moderate

Unacceptable. Major disruption likely.

Different approach required. Priority management attention required.

High

Assessment

Minimum impact. Consequences unimportant.Slight change w/schedule slack.< $50K1

Minor impact. Reduced performance margin.Slip <1 month. Slight program impact.$50K- $250K2

Minimum system impact. No performance margin but meets capability.

Slip 1-3 month. Slight MS impact. Possible program impact.

$250K - $1M3

Significantly degrades system performance. Does not meet capability requirements.

Slip >3 months. Moderate MS impact.$1M - $5M4

Does not meet KPP.Large slip. Significant MS / program impact.> $5M5

PerformanceScheduleCost

ConsequenceRating

Minimum impact. Consequences unimportant.Minimal or no impact.< $50K1

Minor impact. Reduced performance margin.Able to meet key dates. $50K-$250K2

Minimum system impact. No performance margin but meets capability.$250K - $1M3

Significantly degrades system performance. Does not meet capability requirements.Program critical path affected.$1M - $5M 4

Does not meet KPP.Cannot meet key program milestones.> $5M5

PerformanceScheduleCost

ConsequenceRating

Not Likely

(0-20%)

Risk Assessment Process

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

3.4 Technical Organization

The product office organization is depicted in Figure 3.4.1-1. The organization is augmented via part-time subject matter expertise support from the PM UAS Technical Management Division and the Navy’s PMA-263 project office as required.

3.4.1 Government Program Office Organization

Figure 3.4.1-1 Product Office Organization

‐ General Logistician (Maintenan

‐ Logistics Specialist (Reset/Prese

Training and Tech Pubs Team

‐ Lead Logistician (Training)

‐ General Logistician (BIT/NET)

‐ General Logistician (BIT/NET)

‐ General Logistician (BIT/NET)

‐ General Logistician (BIT/NET)

‐ Lead Logistician (Fielding)

Material Fielding & Integration

‐ Lead Logistician (Fielding)

‐ Logistics Specialist (GFP)

‐ Logistics Specialist (Fielding)

‐ General Logistician

‐ Logistics Specialist (PBL)

‐ Logistics Specialist (LMI/LORA)

Acquisition and Contracting

‐ Lead Logistician (PBL)

‐ Logistics Specialist (PBL)

‐ Logistics Specialist (PBL)

‐ Logistics Specialist (TCDL)

‐ Logistics Specialist (ILS)

‐ Logistics Specialist (LMI/LORA)

Operations & Sustainment Spt

‐ Lead Logistician (O&S)

‐ Logistics Specialist (USMC)

‐ General Engineer (Software)

‐ General Engineer (Radios)

‐ General Engineer (Propulsion)

‐ General Engineer (Weapons)

‐ General Engineer (Payload)

Logistics Branch

‐ Fleet Manager

‐ Lead Logistician

ILS Plans and Product Dev

‐ Lead Logistician

‐ Lead Engineer

‐ General Engineer

Product Engineering

‐ Lead Engineer (TCDL)

‐ General Engineer (AV)

‐ General Engineer (Ground Sys)

‐ Lead Engineer (Production)

‐ General Engineer (Quality)

‐ General Engineer (CM)

‐ General Engineer (Production)

‐ General Engineer (RAM)

Test Engineering

‐ Procurement Analyst

‐ Procurement Analyst

‐ Procurement Analyst Engineering Branch

‐ Branch Chief

Systems Engineering

Business Branch

‐ USMC Program Integrator

‐ Program Analyst/Scheduler

‐ Program Analyst

‐ Cost Analyst

‐ Program Analyst

‐ National Guard Liaison

‐ Safety and Standards Officer

‐ Operations Analyst

‐ Senior Operations Analyst

‐ Senior Operations Analyst

‐ Safety Manager

Headquarters

‐ Product Manager

‐ Deputy Product Manager

‐ Assistant Product Manager

‐ Assistant Product Manager

3.4.2 Program Office Technical Staffing Levels

This SEP is aligned with the acquisition strategy and Cost Analysis Requirements Document (CARD) to ensure staffing, resources, and funding alignment. As discussed in Section 1.1, above, this project is in the sustainment phase. Unlike SEPs that document major acquisition programs between Milestones A and C – this SEP documents a post milestone C sustainment program. Traditional programs have fixed engineering milestones and activities (design reviews, etc.). Engineering workload for a traditional program ramps up or down consistent with their schedule.

TUAS technical staff manning is essentially “flat”. If the future “Group III UAS depicted in Figure 3.1-1 comes to fruition then a SEP revision will be required along with all the other requisite acquisition documentation. For the purposes of this SEP: our systems engineering staffing is consistent with the SEP Section 3.1 narrative and as illustrated in Table 3.4.4-1.

3.4.3 Contractor Program Office Organization

The prime contractor organization is functionally represented in Figure 3.4.3-1. Staffing and management change to match engineering demand and project complexity. The prime contractor may not be the recipient of all the engineering work represented by our SEP Section 3.1 narrative. As a result, for those individual projects awarded to competing contractor or government agencies the prime contractor will adjust their management levels to ensure profitability. It is not practical to depict each “contractor” (or government agency) functional organization within this SEP. However, they will be required to produce a TUAS approved SEMP and execute their systems engineering accordingly.

Figure 3.4.3-1 Contractor Functional Organization

3.4.4 Engineering Team Organization and Staffing

The product office core engineering team is depicted in Table 3.4.4-1 and the functional team hierarchy is depicted in Figure 3.4.4-1. Table 3.4.4-2 describes the IPTs, membership, roles, and products in more detail. There is no over-arching IPT as is often true for major developments between Milestone A and C. This SEP documents Post- Milestone C sustainment activities that do not require recurring executive level engagement through an over-arching IPT.

Table 3.4.4-1 Engineering Team Details

Figure 3.4.4-1 IPT/WG Team Hierarchy

‐ General Engineer (Ground Sys)

‐ General Engineer (Software)

‐ General Engineer (Radios)

‐ General Engineer (Propulsion)

‐ General Engineer (Weapons)

‐ General Engineer (Payload)

Product Engineering

‐ Branch Chief

Engineering Branch

‐ General Engineer (Production)

‐ General Engineer (CM)

‐ General Engineer (Production)

‐ Lead Engineer

‐ General Engineer

‐ Lead Engineering (TCDL)

‐ General Engineer (AV)

Systems Engineering

‐ Lead Engineer (Production)

Test Engineering

‐ General Engineer (RAM)

PM IPT

SE IPT

IA

I P T

R is k

IP

T T&E

Working IPT

A vi o n ic s

IP

T

P ro p u ls io n I P T

C I

IP

T

So ft w ar e

IP

T

C o n tr o l E q u ip m en t

IP

T

Production IPT

Supportability IPT

System Safety Working Group

Fa ilu re R ev ie w B o ar d

Mishap IPT

Obsolescence IPT

Q u al it y

IP

T

Su p p o rt E q u ip m en t

IP

T

This page deliberately blank.

Team Name Chairperson Team Membership Role & Responsibility Products and Metrics

Headquarters Products:

‐ Deputy Pdm ‐ Acqusition Strategy

‐ Assistant PMs

‐ Cost Analysis

Requirements Document

‐ Operations Analysts ‐ ILS Plan

‐ Safety Manager

Integrated Master

Schedule

Business Branch Lead Metrics:

Engineering Lead ‐ Cost

Logistics Branch Lead ‐ Performance

Prime Contractor ‐ Schedule

Role: identify, document, track, and monitor risks through mitigation and closure.

Risk management plan

Schedule: meets monthly. Mitigation status

IASO

Coordinate issues, status, and solution plans.

Metrics: minutes, action items.

Contractor Leads Schedule: meets weekly.

PM

TCM UAS

AED

AMCOM Safety

PEO

Metrics: mishap trend analysis, hazard closure rate

Program Office Mishap Rates

Engineering Trend Analysis

Logistics Causal Analysis

Prime Contractor Action Items

Program Office

Engineering

Logistics

PEO Avn POC

TCM UAS

ATEC AEC

ATEC OTC

DUSA‐TE POC

DOT&E POC

ASA(AL&T) T&E POC

SE POC Production deliveries

Production POC Cost/Schedule metrics

DCMA POC Schedule: meets weekly. Performance

Product Tech Lead

Engr Branch Lead

Fleet Mgt POC

PBL Lead

AMRDEC Obsolescence

Team

System Engr Leads

System Engr Leads

‐ Avionics

‐ Propulsion

‐ C4I

‐ Software

‐ Control Equipment

‐ Support Equipment

‐ Reliability

‐ Test

‐ Production

‐ Obsolescence

‐ Quality

Contractor Engr Leads

Logistics POC

Table 3.4.4‐2 IPT Team Details (Page 1 of 2)

Safety Mgr

Role: review mishap data.

Schedule: meets weekly.

Pdm GM Same as PM IPT

IA Lead

Pdm GM &

Safety Mgr

Role: implement AR 385‐16 via closed loop hazard tracking system and analysis coordination

Schedule: meets quarterly.

Products: hazard tracking logs, risk acceptance documents

Role: track production issues and provide production activity oversight/guidance.

Products: TEMP and derivative plans and reports.

Role: implements AR 73‐1 via test strategy integration and advising

PdM GM.

Production IPT

Obsolescence IPT

SE IPT

SE Lead

SE Lead

Mishap IPT

Metrics: critical technical parameter & measure of effectiveness identification/tracking.

Schedule: meets semi‐annually or as needed.

T&E WIPT

Pdm GM &

Test Lead

PM IPT Pdm GM

Role: provides oversight, guidance, stategic integration.

Schedule: meets weekly.

Risk IPT

IA IPT

SSWG

Shadow

Obsolescence

Lead

Role: assess obsolescence impacts, trends, and status resolution plans.

Schedule: meets weekly.

Products: acquisition strategy, cost analysis, sustainment plan inputs;

trend analysis, action

Metrics: system health analysis reports, issue resolution metrics.

Products: problem change report (PCR) tracking & disposition, issue/action item tracking, use case and technical performance measure approval.

Metrics: critical technical parameters, PCR burn‐ down/schedule.

Role: provide product and functional system engineering integration and oversight.

Schedule: meets weekly.

Team Name Chairperson Team Membership Role & Responsibility Products and Metrics

Avionics POC

Quality POC

Contractor POCs Schedule: meets weekly.

Metrics: FRB top 5 solution completion status.

Avionics POC

Quality POC

Contractor POCs Schedule: meets weekly.

Metrics: FRB top 5 solution completion status.

Logistics POC

Quality POC

Navy POC

Propulsion POC

Logistics POC

Role: Review status of Shadow V1 and V2 SEIT SW PCRs, PPSS, JSIL, IA, AIC, and scheduled SW Release efforts.

Navy POC Schedule: meets weekly on Tuesdays at 1000 CDT/CST.

Control Equip POC

Quality POC

Reliability POC

System Engr POC

Support Equip POC

Quality POC

System Engr POC

Contractor POCs

Avionics POC

Propulsion POC

C4I POC

Software POC

Control Equip POC

Support Equip POC

Production POC

Quality POC

Logistics POC

QM POC

DCMA POC

Supply Support Lead

Maintenance Lead

Readiness Lead

Training Lead

Fielding Lead

ILS Lead Metrics:

PBL Lead

Marine Corps Logistician

FMS Specialist ‐ Depot Mean Down

Time

Maintenance Specialist ‐ MWO Status

COLTS/UAS‐I Specialist ‐ Supply Chain Status

Item Manager ‐ Availability

Prime Contractor POCs

Aircraft IPT AV Lead

Role: coordinate issues and status solution plans.

Products: minutes, action items, PCR Status

Propulsion IPT Propulsion

Lead

Role: coordinate issues and status solution plans.

Products: minutes, action items, PCR Status

Schedule: meets bi‐weekly on

Tuesdays at 0900 CDT/CST.

Metrics: FRB top 5 solution completion

C4I IPT Not currently active

Software IPT PdM TUAS

Software Lead

Metrics: Minutes, Action

Items

Control

Equipment IPT

Control

Equipment

Lead

Role: coordinate issues and status solution plans.

Metrics: Minutes, Action

Items, Problem Change

Report (PCR) Status Schedule: monthly on Thursdays at

1000 CST.

Ground Support

Equipment IPT

Support

Equipment

Lead

Role: coordinate issues and status solution plans.

Metrics: Minutes, Action

Items, Problem Change

Report (PCR) Status Schedule: monthly on Wednesdays at 1000 CST.

Failure Review

Board

Reliability

Lead

Purpose: assess new failures, trends, and corrective action plans.

Products: minutes, action items, metrics, trend and cost analysis.

Schedule: meets monthly.

Metrics: failure cost, quantity, rate per 100,000 flight hours

Quality IPT Quality POC Purpose: review open PQDRs, assess open general quality issues including

Metrics: Quality

Improvement Process

Supportability IPT

Logistics

Sustainment

Lead

Role: manage and monitor requirements compliance.

Products: sustainment plan, action item tracking, trend analysis.

Schedule: meets weekly.

‐ System Status

Readiness

Table 3.4.4‐2 IPT Team Details (Page 2 of 2)

AV Lead

Role: coordinate issues and status solution plans.

Products: minutes, action items, PCR Status

Avionics IPT

3.5 Relationships with External Technical Organizations

The TRADOC Configuration Manger (TCM) – Unmanned Aircraft Systems (UAS) is the principle external organization participating in our IPTs. Contractor quarterly management reviews, T&E IPTs, and system safety working groups involve active TCM UAS participation. The System Safety Working Group charter and the Test and Evaluation Master Plan (TEMP) discuss other agency participation and roles.

Pre-planned product improvement (P3I) and other design reviews during this operations and support phase include TCM-UAS involvement. The TEMP documents the methodology by which we ensure Army Test and Evaluation Command independent evaluation for efforts during this phase.

The Joint System Integration Laboratory (JSIL) provides training simulators, special test equipment, and post-production software change support. SEP methodology and processes crosswalk from this plan into JSIL system engineering and configuration control plans.

3.6 Technical Performance Measures and Metrics

Each new engineering effort produces tailored performance measures and metrics based on the capability improvement or obsolescence issue it addresses. However, an overarching minimum set of technical performance measures are presented in Table 3.6- 1.

Shadow is a mature acquisition program and completed its approved production quantity objectives. A reliability growth model was not used for this program. A reliability growth curve is not provided for this reason. Shadow uses a systematic reliability monitoring program as described below and in Table 4.6-2 R&M Activity Planning and Timing.

A failure reporting and correction system and field surveillance produce problem change requests (PCRs) that are presented to the SE IPT. PCRs are prioritized and introduced into improvement programs. Each of these programs follows system engineering processes, including metrics and appropriate verifications, which conclude with engineering change documentation approved by a Joint Configuration Control Board

(JCCB).

Table 3.6-1 Technical Performance Measures and Metrics

TPM Name Responsible IPT KPP (K) or CTP (C)

Correlation

Theshold

Value

Range (C) 125 Km

Endurance (C) 7 Hours

TLE (C) < 50 m

Probability of Recognition given Detection (P(R/D))

(K) and (C)

8000 ft

AGL, 7000

ft standoff

(day);

6000 ft standoff

(night)

MTBSA (C) 20 Hours

CPU Usage No < 50 %

Memory Usage No < 50 %

Network Utilization and Speed No Varies by project

Throughput (reserve) No >= 50 %

Disk Utilization No < 50 %

Unit and Life Cycle Cost

PM IPT,

Supportability IPT, SE IPT

No None

Supportability IPT

Production IPT

Avionics IPT

Propulsion IPT

Emplace, Displace Time (C) 180, 60

Minutes

Transportability and

Deployability (C)

Varies by project

Weight No

Varies by project

Launch and Recovery (C) Soccer

Field Area

Technical Performance Measures

(Each P3I or capability upgrade augments with additional TPMs correlating to

Performance Attribute)

SE IPT

SW IPT

Control

Equipment IPT

Mean Time to Repair (Field)

Space, Weight, and Power

(SWAP)

Varies by project No

(C) 2 hours

4 Technical Activities and Products

4.1 Previous Phase System Engineering Activities

The prior SEP dated 23 February 2007 discussed the “Production Program” engineering activities. The product office placed the last of the authorized 102 Army systems on contract during 2009. The prior SEP also discussed engineering activities and processes leading to the development and fielding of the Laser Range Finder/Designator payload and the communications relay subsystem. The prior SEP also provided the methodology and processes supporting the RQ-7BV2 development which provides Ku Band Type 1 command/control and payload video encryption and implements the Tactical Common Data Link (TCDL) messaging and waveform.

4.2 Next Phase System Engineering Activities

This SEP supports the P3I program as well as continued system operations and sustainment. Prior methodology and processes continue to apply, but are both tailored and described in more detail within this SEP.

This SEP also introduces methodology and processes tailored to support foreign material sales. For example, SEP Section 4.4 discusses uses cases. These are additionally tailored to address Australian unique configuration and practices. Engineering milestone reviews then include an assessment of change impacts on the Australian configuration. This assessment, coupled with peer review, ensures designs and supporting analyses address Australian impacts. Australia has two systems at this time. Its configuration baseline and logistics support are separately maintained.

This SEP also introduces the Integrating Joint Configuration Control Board (I-JCCB) as documented later in SEP Section 4.3.2. IJCCB structure and responsibilities are more fully described in UAS-MISC-001C. It is different from the Joint Configuration Control Board described in the prior approved SEP and in UAS-GM-001. The primary mission of the I-JCCB is to ensure that interoperability is achieved among the Universal Products and to maximize commonality among the Universal Product hardware and software configuration baselines. Section 4.3.2 provides additional I-JCCB detail. The JCCB, however, remains the single control authority for all Shadow system configuration baselines. Section 4.5 provides additional JCCB detail.

4.3 Requirements Development and Change Process

The PM and SE IPTs provide horizontal integration between multiple contract change sources: engineering services, production, post-production software support, performance based logistics, and foreign military sales programs. Horizontal integration occurs within weekly IPTs and quarterly reviews and as part of the SEP Section 3.1 narrative discussing our “blocking” or “release” methodology prior to fielding.

The SE IPT is the overarching engineering IPT. System Change Requests (SCRs) and Problem Change Reports (PCRs) are assessed within the SE IPT process and aligned with either existing contract scope or prioritized for new funding and scope within a contract.

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

The chief engineer exercises configuration control through the JCCB and is also responsible for developmental test configuration control and risk acceptance through a Test Flight Authorization (TFA) process. The TFA process provides test configuration control and PM level risk assessment and acceptance in accordance with AR 95-20 (Contractor’s Ground and Flight Operations) and the DFARS clauses 252.228-7001 and/or -7002.

System engineering processes implement cybersecurity test strategy and planning to obtain relevant data from all available sources, including information security assessments, inspections, component-and subsystem-level tests, system-of-system tests, and testing in an operational environment with systems and networks operated by representative end users. System engineering processes identify and assess network architecture, external network connections, intended operational environment, and the anticipated cyber threat requirements to influence the design and subsequently to assess test adequacy. Figure 4.3-1 illustrates our methodology.

Figure 4.3.1 Cybersecurity and Systems Engineering Integration

4.3.1 Analysis and Decomposition

The project office and prime contractor rely on the IBM Dynamic Object Oriented Requirements System (DOORS) tool to perform requirements analysis and management activities. The requirements schema facilitates the requirements development process through a hierarchy that maintains links from system level requirements down to allocated item level requirements. Cybersecurity is also integrated into the evaluation structure. Figure 4.3-1 depicts this schema, showing the relationships between the requirements modules maintained in DOORS, verification documentation, and product baseline documentation. The Figure 4.3-1 generic references to “Subsystem 1”, as an example, maps to “TUAV Air Vehicle Performance Specification R38561-00098” in Figure 4.3.1-2A.

The prior approved SEP documented product office functional baseline control. This SEP describes both functional and allocated baseline control to correct prior process shortfalls. Table 4.3-1 summarizes the new controls.

Table 4.3-1 JCCB Baseline Controls

Milestone Review Specification Exit Criteria Approval Authority Preliminary Design Review

Functional (System or Prime Item and Interface Specification Paragraph Changes) Baseline Impact Documentation

JCCB to receive and approve preliminary ECP.

Critical Design Review Allocated (Configuration Item and supporting analyses) Baseline Documentation

JCCB to receive and approve Preliminary ECP revision.

Functional and allocated requirements are illustrated in two specification trees. Figure 4.3.1-2A documents the RQ-7B specification tree. Figure 4.3.1-2B documents the RQ- 7BV2 specification tree. The specification tree as tailored for the Australian baseline is not depicted. Training simulator and/or special test equipment specification trees maintained by the Joint System Integration Laboratory (JSIL) are also not depicted.

Figure 4.3.1-1 Requirements Decomposition and Control

Validated Baseline

TUAV

ORD

CONOPS

Program

SOW

Program

TRD

System Functional Requirements Baseline

Subsystem Interface Requirement Specification

External Interface Requirement Specification

System Performance Specification

System Functional

Module

Verification Documentation

Allocated Subsystem Baseline

System Verification, Test Cases, ATP, DT&E

Subsystem 1

Subsystem 2

Subsystem 3

Subsystem 4

Subsystem n

Subsystem Specification

Subsystem Functional

Module

Subsystem Interface

Specification

Allocated Item Baseline

Software

Hardware

Subcontract

Subsystem Verification, Test Cases

SW Item Test

HW Item Test

SC Item Test

Product Baseline

Design Description Documents

Design Decision

Documents

Parts Lists

Drawings

Code

Technical Manuals

Training Materials

Validation Documentation

OT&E

Figure 4.3.1-2A RQ-7B Specification Tree

Figure 4.3.1-2B RQ-7BV2 Specification Tree

R38431-00097 Interface Requirement

Specification, Subsystem Interfaces for the

Tactical Unmanned Aerial Vehicle

R38431-00096 Interface Requirement

Specification, External Interfaces for the

Tactical Unmanned Aerial Vehicle

R38431-00003 Performance Specification for the Tactical Unmanned Aerial

Vehicle

R38561-00098 Performance

Specification for the TUAV Air

Vehicle

R38561-00100 Performance

Specification for the TUAV

Portable Ground Control Station

R38561-00102 Performance

Specification for the TUAV

Recovery System

R38561-00104 Performance

Specification for the TUAV Air

Vehicle Transport

R38561-00106 Performance

Specification for the TUAV Maintenance

Section Multi- Functional

R38561-00099 Performance

Specification for the TUAV Ground Control System

R38776-00037 Performance

Specification for the TUAV One

System ® Remote Video Terminal

R38561-00103 Performance

Specification for the TUAV Launcher

R38561-00105 Performance

Specification for the TUAV Mobile

Maintenance Facility

R39489-00066 Interface Requirement

Specification Subsystem Interfaces for the TCDL Tactical

Unmanned Aerial Vehicle

R39489-00065 Interface Requirement

Specification External Interfaces for the TCDL Tactical Unmanned

Aerial Vehicle

R39489-00064 Performance Specification for the TCDL Tactical Unmanned Aerial Vehicle

R39489-00116 Performance Specification for the TCDL Portable Ground Control Station

(PGCS) Subsystem

R39489-00434 Performance Specification for the TCDL Launcher (LAU) Recovery (REC)

Subsystem

R39489-00115 Performance Specification for the TCDL Air Vehicle

(AV) Subsystem

R39278-30003 Performance Specification for the Universal Ground

Data Terminal

R39489-10001 Performance Specification for the TCDL Portable Ground Data Terminal

(PGDT) Subsystem

R39593-00036 Performance Specification for the Universal Ground Control Station (UGCS)

4.3.2 Requirements Management and Change Process

The Defense Acquisition Guidebook defines eight (8) technical management processes that are implemented by the Shadow system engineering organization. The IPTs execute these processes and the SEMPs that crosswalk to this SEP discuss the details for each organization contributing to the change methodology discussed in SEP Section 3.1. The SEIT IPT addresses “Technical Planning”, “Technical Assessment”, “Decision Analysis”, and “Risk Management”. The remaining four technical management processes (“Requirements Management”, “Configuration Management”, “Interface Management”, and “Data Management”) involve control methodology implemented within the production contract.

There are two requirement change processes. These are illustrated by three flow charts.

The first flow chart (Figure 4.3.2A) documents the I-JCCB process which controls common requirements between multiple unmanned aircraft platforms. The second flow chart (Figure 4.3.2B) documents both the Shadow engineering process leading to JCCB change approval followed by production and acceptance. Section 4.5 (Configuration Management and Change Process) includes a complimentary third flow chart (Figure 4.5-

2) illustrating the JCCB and ECP process.

The primary mission of the I-JCCB is to ensure that interoperability is achieved among the Universal Products and to maximize commonality among the Universal Product hardware and software configuration baselines.

Figure 4.3.2A IJCCB Process

Multiple prime contractor contract change sources all share a common system engineering change process documented in this SEP. JSIL change sources also crosswalk to SEP processes documented herein. This SEP introduces an additional JSIL training simulator/special test equipment functional, allocated, and product baseline controlled through the JCCB.

The prior approved SEP focused on functional baseline management. OSD Configuration Management Guidance (MIL-HDBK-61A) defines a functional baseline as the approved configuration documentation describing a…