Sect_J_Attach_I_SEP_19Apr2016.pdf

UNCLASSIFIED

Shadow RQ-78 Tactical Unmanned Air System (TUAS)

ACAT Level IC

System Engineering Plan (SEP), R1 Supporting the

Operations and Support Phase 5 January 2016 fl~~ IC

DATE

istant PEO for Engineering and Technology EO Aviation

UAS-00004

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, ATIN: SFAE-AV-UAV, Redstone, AL 35898

(This page intentionally left blank)

SYSTEM ENGINEERING PLAN (SEP), Rl

FOR THE

SHADOW RQ-7B OPERATIONS AND SUPPORT PHASE

December 2015

Chief Engineer, SUBMlTTED BY:

1z/nl201 ~

DATE

DATE

t Colonel, AV Tactical Unmanned Ai rcraft Systems anager Tactical Unmanned Aircraft Systems

CONCURRENCE:

~·- /~4£u_.

ERICSSON ~

C:f, TechNfanagement Division, Unmanned Aircraft Systems f,< c~WTN{YP~OTE Colonel, AV Project Manager, Unmanned Aircraft Systems

UNCLASSIFlED

1J-/)-1f1S

DATE

UNCLASSlFIED

TABLE OF CONTENTS

1 INTRODUCTION

1.1 P ROGRAM DESCRIPTION

1.2 APPLICABLE D OCUMENTS

1.3 PROGRAM BACKGROUND

2 PROGRAM TECHNICAL REQUIREMENTS

2.1 ARCHITECTURES AND INTERFACE CONTROL

2. 1. 1 Architecture

2.1.2 Interface Control

2.2 TECHNICAL CERTIFICATIONS

3 ENGINEERING RESOURCES AND MANAGEMENT

3.1 TECHNICAL SCHEDULE AND SCHEDULE RISK ASSESSMENT

3.2 ENGINEERING RESOURCES AND COST/SCHEDULE R EPORTING

3.3 ENGINEERING AND INTEGRATION RISK MANAGEMENT

3.4 T ECHNICAL ORGANIZATION

3. 4. 1 Government Program Office Organization

3.4.2 Program Office Technical Staffing Levels

3.4.3 Contractor Program Office Organization

3.4.4 Engineering Team Organization and Staffing

3.5 RELATIONSHIPS WITH EXTERNAL TECHNICAL ORGANIZATIONS

3.6 TECHNICAL PERFORMANCE M EASURES AND M ETRICS

4 TECHNICAL ACTIVITIES AND PRODUCTS

4.1 PREVIOUS PHASE SYSTEM ENGINEERING ACTIVITIES

4.2 N EXT PHASE SYSTEM ENGINEERING ACTIVITIES

4.3 REQUIREMENTS D EVELOPMENT AND CHANGE PROCESS

4.3.1 Analysis and Decomposition

4.3.2 Requirements Management and Change Process

4.4 T ECHNICAL REVIEWS

4.5 CONFIGURATION AND CHANGE MANAGEMENT PROCESS

4.6 D ESIGN CONSIDERATIONS

4.7 ENGINEERING TOOLS

ANNEX A - ACRONYMS

APPENDIX A: WORK BREAKDOWN STRUCTURE

APPENDIX B: TECHNICAL READINESS REVIEW PRODUCTS AND

CRITERIA

ii i

UNC LASSIFI E D

TABLES

Table 1.1-1 SEP Update Record Table 1.2-1 Applicable Documents Table 2.2-1 Technical Certifications Table 3.4-1 Engineering Team Details Table 3.4-2 IPT Team Details Table 3.6-1 Technical Performance Measures and Metrics Table 4.3-1 JCCB Baseline Controls Table 4.4-1 Technical Review Type and Summary Table 4.6-1 Design Considerations Table 4.6-2 R&M Activity Planning and Timing Table 4.7-1 Engineering Tools

FIGURES

Figure 1.3-1 Program Background Figure 1.3-2 System Description Figure 2.1-1 System Functional Architecture Figure 2.1-2 UGCS/UGDT Physical Architecture Figure 2.1-3 PGCS/PGDT Physical Architecture Figure 2.1-4 External Interfaces Figure 2.1-5 Subsystem Interfaces Figure 3.1-1 System Technical Schedule (as of Feb 2015) Figure 3.1-2 Engineering Release Schedule (as of Dec 2015) Figure 3.3-1 Risk Management Process Figure 3.3-2 Risk Cube Figure 3.4-1 Product Office Organization Figure 3.4-2 Contractor Functional Organization Figure 3.4-3 IPT/WG Team Hierarchy Figure 4.3-1 Cybersecurity and Systems Engineering Integration Figure 4.3-2 Requirements Decomposition and Control Figure 4.3-3 RQ-7B Specification Tree Figure 4.3-4 RQ-7Bv2 Specification Tree Figure 4.3-5 IJCCB Process Figure 4.3-6 Shadow System Engineering Process Figure 4 .3-7 Development and Verification Relationship Figure 4.5-1 Configuration Management Process Diagram iv

1 Introduction

1.1 Program Description

The prior approved System Engineering Plan (SEP) dated 23 February 2007 supported the final production phase. This SEP continues the overall technical approach to manage system engineering activities for the Shadow RQ-78 Tactical Unmanned Air System (TUAS) Program. The program is post Milestone C and in its operations and support phase. There are no future milestones that this SEP supports. The Army placed the last of its authorized 104 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. This SEP augments the Shadow Supportability Strategy dated 16 June 2014 by ensuring engineering changes assess and implement supportability considerations. 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 ensure compliance with the latest policy and regulatory changes.

Revision Basic

1.0

Future

Table 1.1-1 SEP Update Record

Change Log and Date Reason

5 March 2007 Implement Department of the Army (DA) policy

TBD January 2016 Support 7Bv2

TBD

acquisition strategy and provide contractor and JSIL SEMP guidance.

Align with future Life Cycle Sustainment Plan and Corrosion Prevention & Control Plan.

UNCLASSIFIED

Approved By PEO Aviation (ACAT II Milestone Authority)

Assistant PEO Aviation (Engineering and Technology)

Assistant PEO Aviation (Engineering and Technology)

1.2 Applicable Documents

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

Table 1.2-1 Applicable Documents (Joint Configuration Control Board (JCCB) approved baseline.)

Document Tactical Unmanned Aircraft Vehicle (TUAV) Operational Requirements Document

(ORD)

TUAV Performance Specification Tactical Common Data Link (TCDL) (RQ-7Bv2) Performance Specification IRS External Interfaces for the TCDL Tactical Unmanned Aerial Vehicle IRS Subsystem Interfaces for the TCDL Tactical Unmanned Aerial Vehicle Performance Specification for the TCDL Air Vehicle (AV) Subsystem Performance Specification for the TCDL Portable Ground Control Station (PGCS) Subsystem Performance Specification for the TCDL Portable Ground Data Terminal (PGDT) Subsystem Performance Specification for the Universal Ground Control Station (UGCS) Performance Specification for the Universal Ground Data Terminal (UGDT) Subsystem Performance Specification for the TCDL Launcher (LAU) Recovery (REC) Subsystem Overarching Inter-Operability Profile (IOP) Common Data Link (COL)

IOP

Performance Specifications for the Standard Common Data Link (Std-COL) Waveform TUAS Acquisition Strategy Report UAS Integrating JCCB (IJCCB) Charter JCCB Charter

Document Number

N/A

R38431-00003G

R39489-00064A

R39489-00065A

R39489-00066B

R39489-00115C

R39489-00116C

R39489-10001 G

R39593-00036E

R39278-30003C

R39489-004 34 B

Version 1.5.5

Version 2.0

PRF 7681990G

N/A

UAS-MISC-001 B

UAS-GM-001

UNCLASSIFIED

Date

29 August 2003

March 2009

October 2012

November 2012

April 2014

April 2014

June 2014

June 2014

February 2011

April 2010

May 2014

October 2008

October 2010

Nov 2007

February 2013

April 2014

December 2012

1.3 Program Background

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

The RQ-7B 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 (TUAV) ORD in June 2003. The ORD specified a blocking concept with Thresholds required for Production and Objective requirements for three Block Upgrades, (1) 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 (ECPs) designed to meet Urgent Operational Requirements as well as software and hardware fault resolution. The result is a robust system that has flown over 970,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 Modifications (MODS) Aircraft Program Element 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-78 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 Army Test and Evaluation Command (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 & Evaluation to assess 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.3-1 below.

Proc•m tnlti•tlon IOTE/ MSC luer Deslc nator FOTE V2 FOTE

Sh.ldo. ~•< It'll d' a lo< tn O<T lOOl lun~lOl O In< kt de ' TC DL. H AllM1 COTS .t<• 1t11\.11Jon ~S86 U<..CS UttOT '"· ' l I l lo .ttlo ut. Z7 <t0hlt t>t \ l 2002 2004 2006 2008 2010 2012 2014 t OSGCS 1101 Enclne Upc rade ReWlnc • nd L•ser 1102 Enc1ne Upcrade th~,NI O.Ui> tlov 1007 Oesl1nator Upcr1de Atlth fii t;>l ulW<110i \ ,m<I douMe' MTRC FF

Total Systom1

Figure 1.3-1 Program Background

The system is depicted in Figure 1.3-2.

i~~'(;\

~~\ RQ-7Bv2 Product Description ~

(1JT-

Lmdlng Sp- (TALS}

(1} Hr<frw* l..llmcllwl - Anu*'IJ Sp -

(Z)Universal Ground O.taT..-m/,,.I•

--C-..IS- - (1)1Stw-- O... ,........,

(Z) IJniven;al Gm&md Contro/Stadon•

Main_ ...,. Section Mulli-lum:tionM {llfSM) i-•tn/lwl

Figure 1.3-2 System Description

(t} 1SE IJAS--..

The Tactical Unmanned Aircraft Systems 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, 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 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 fi re support

• Rear area security support

• Combat search and rescue support

• Battle Damage Assessment (BOA) 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-1 below. The former RQ-7A and RQ-78 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.

L/R Equipment

GK

• Engine Starter

· Fueling Equip

• IFF Tester

• Transport Contliners -HMM'M/s

Man-Mtcb!ot tnltrftct

• KeybollRI I joystidt

• Oisplays I g111plb brdo ---Gel QwMimal fWllpn

· AV & P.,-COnlrol - GVSMOCUCS

-TALS~ GVSM

• Dmlnk COnlrol - GVSMOCUCS

. 1.,_p,-.g IT-'"O · CUCS

· C41- & conw.... cues

• Fight om Recording - GVSMICUCS

• ~ Tr""1ing (!otUSE) .

-- -cues

UNCLASSIFIED

Llllll

· OnnMt ·-

6 k QCa hm\ .-.....,

· - (QoS) ~T

U OCA ICo!rtm!pn

· --IOSiriglo -

Air Vehicle

ACI Opm!ieN! ,_..,,,, Dmlnk COlrrN • Ort

· AV FlgtC COnlrol & AoAQPlo( ---"·GPSllNSl<alrrMFibMg

· AV Splerrw Ho•lll Moncoring

· fuel~C -~COnlrol

• - & AV Sywl-Conlrcl

· IFFT,__ COnlrol

·FfVllT ·llOSV-~ -~Una

-.nu COnlrol

UGDT

COMKC Encryption eil!zS.Jls!ll ... . _..._

Air Tnlftc lnftdtctl

· IFFT~

-~Ughtl --Ugl!t

Cqmputational hlllm ACE II Processors: -FlgtC Clrt

P.,- Cormuicallona

· -(MSE)

· 1-.:om

• LAHs (Fl. TAC &

Sil()

· F-91"""

'.'rf'KW~ I E"t;""L Prpcn al!q & !lb!ribM!ion

· -•..,.,._/UPS · ECU ·Video-

• Pvwer Di1lribulon • V-llMon • CloM C.pllon EncodW>g

• Cl<ouit brnke<I • NBC IOI

Figure 2.1-1 System Functional Architecture limn

· Alerono ·--Alps ·---

Pgwtr DisL & Qd.

· Alemator

·VolAIQo~ . p- !loot. lkil --.ups-y

- ~-C<>nn. ---lllmlllismll

• Ooallnl< Control . 1,,_ P!--1ng I

Totgt1ing

• C41 Proceoolng &

COlrrN

· Mt"""'M..._,...,.

. Woo Reconling

· Woo R.,...,

· STAHAG -

eor-.ion ---

OSRVT

RQ-7Bv2 Functional

Architecture

Figure 2.1-2 depicts the UGCS/UGDT physical architecture. The Shadow RQ- 7Bv2 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 Airborne System Interface Module (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.

r r

ACEl

[ ...._ ~ RSCZ!

-+---=--4 1- - O'u I

I ,... CP\J I

RS2F

Figure 2.1-2 UGCS/UGOT Physical Architecture

RrDnk RFE

Ill' ~

-8-Mlnl .. T llW-C -AOT AOT (WURi (V"-Enc,1

c. - sw ACEJ

1~CPU 1

E

.-t-- --- -+---=-------i I-CPU I I RoN CPV I

Air Vehicle

EOOMD p-f--• .. f: lhefnet Debug P(W1

• • ~Oot>uQPort

RS2F

E I PGCS I

---E-----1-1

EJ

i------1-----F ·---~!--.---'--"----'--"----' I

Figure 2.1-3 PGCS/PGDT Physical Architecture

2.1.2 Interface Control.

External interfaces are under JCCB configuration control through the External Interfaces Specification R39489-00065 and are depicted in Figure 2.1-4. UAS Inter-Operability Profiles (IOP) are also implemented as coordinated with the Integrating Joint Configuration Control Board (IJCCB). These are represented as "El-15" in Figure 2.1-4.

IFF Interrogator 1"

Mulliband Comml.rllcatJon •

Weight and 1 Balance System

BFT Sateld.e ...

GPS Satelrte •

External Power ,..

El-14

El-13

El-12

Et-11

El-10

UNCLASSIFIED

Class NBIC cues

El-15 El-16

External Video Producls

El-01

El-02

El-03

El-04

El-05

El--Oe El-07 El-06

DAS VAN

Figure 2.1-4 External Interfaces

AFATOS

• DCGS-A

• TAIS

.. TOC/CPP

• ATC/ATS

~ ABC CC

(Figure 2.1-4 acronyms: Common User Control System (CUCS), Advanced Field Artillery Tactical Data System (AFATDS), Distributive Common Ground System -Army (DCGS-A), Tactical Airspace Integration System (TAIS), Tactical Operations Center (TOC), Command Post Platform (CPP), Air Traffic Control (ATC), Air Traffic Services (ATS), Airborne Command, Control and Communications (ABCCC), Airborne Warning And Control System (AWACS), Data Acquisition System (DAS), Global Positioning System (GPS), Blue Force Tracker (BFT), Identification Friend or Foe (IFF), External Interface (El))

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

.-------------;;!l-15------, Pilol Box

I ~ Sl-14 Sl- 1 3~-------;Sl·I

~-"--~ r- --

GCS 1·9-- PGCS _ h 0 ~ ~I '---.--- "-. I I

Sl·8 I S l·11 SI- I:?

D I GOT PGOT

SI-:?:?

Sl-10

Sl-4

/ REC

/ .~ • I Sl-3

Sl·f'.___ _ s,.s,__ -___,l ; . 1 I ,, ;;".I ~ Sl-7

EY'~ ··~X'"

Legend

" CoosumablesfTransports oo AVT

O Spares/Consumables on MSM

CJ Spares/Consumables on MMF

<> Transp0<ls on GCS

Figure 2.1-5 Subsystem Interfaces

Sl-18

I

(Figure 2.1-5 acronyms: Maintenance Section - Multi-functional (MSM), Subsystem Interface (SI) , Tactical Unmanned Aerial Vehicle (TUAV), Mobile Maintenance Facility (MMF), Ground Control Station (GCS), Portable Ground Control Station (PGCS), Ground Data Terminal (GOT), Portable Ground Data Terminal (PGDT), Recovery (REC), Air Vehicle (AV), Launcher (LAU), One System Remote Video Terminal (OSRVT), Air Vehicle Transporter (AVT))

2.2 Technical Certifications

Certification requirements are summarized in Table 2.2-1 below.

Table 2.2-1 Technical Certifications

Certification POC Certification Certification Authority Date

Clinqer-Cohen PMO IASO CIO G-6 Army 18 Dec 2014

Interoperability PMOC41 POC CIO G-6 Spectrum PMO Spectrum Multiple:

Supportability Manager ASMO correlates to

RFE

Risk Management Multiple: varies Framework PMO IASO CIO G-6 by accreditation

(RMF)/lnformation boundary Assurance

Future Airborne Capability PMO P31 POC TSO None: future

Environment intent

(FACE}

Airworthiness AMRDEC AED AED Recurring

The PEO Aviation policy affecting FACE was coordinated during 2014 and is limited to our general purpose computing environment during future efforts. At this time, we anticipate our small mission computer and GPS denied navigation capability improvements are likely candidates to incorporate FACE requirements.

There is no funding to re-engineer existing code to meet FACE requirements.

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 unti l 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.

AMERICA'S AR:\!Y •

THE STRENGTH oF THE NATION Shadow RQ-78 30-Year Plan~ --uNCLASSrFrco 1 FOi/() x-P-1 l ·R.-ed~hn

Future Group Ill

UAS

• tnaeastd 1utonomy

• tncreued endurance

• Dual poytoad capabiily

• Increased AU1omatlon (roducecl ""'"_,

• lncrea$«1 SuMvabtM:y 1-----~

· Improved Pl~

N21 IY J2

oc

0.-c>IOYl'T'tfll fOC

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

UNCLASSIFIED

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/Command , Control, Communications, Computers, and Intelligence (C41) 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. PM TUAS blocks 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.

Shadow RQ-78 v2 Release 4 Roadmap

.. ..... . ... 0 • k•···· ~· t---t---- - - - -- - • 1a.h1"• • • "1 - ._..., ..

D-

1.._·:-_ ...... __._1 __ -_--=_-_-_[·-=----~-=--_---..-_, __ _...-·,..,,.....,.£:",....,,:?,......,..~:,__,:I

I Figure 3.1-2 Engineering Release Schedule (as of Dec 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, rel iability, obsolescence, or sustainment improvement implements an Integrated Master Schedule (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 th is SEP.

Each contractor or government agency participating in systems engineering development activities under this SEP wi ll ta ilor 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 current approved 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. However, contractors or offerers implementing this SEP through their SEMP will implement the latest approved guidance to manage risks and opportunities associated with their contracts tasks. These will be assessed at milestone reviews with the government project office.

U NC LASS I Fl ED

Risk Process Flow

'!l'!llLClcl.Go \'lroog?

.a..--.. . ..__...._

Risk An uncert1ln future event or condrhon th.at. rf 11 occurs. would have ~live consequences on• Pf'ot•ct objechve lllCOIJ)Ofllle Risk MrlJgabOn Plans •n Program Sctie<lulos ~

Figure 3.3-1 Risk Management Process

Risk Assessment Process

Likelihood

" °"'""""'"Plan l>udge<._ .. -·-• Mell'lcsar'IOTN!nd

- 8

Rating

Unacceptable MaJOr d1srup110n likely Different approach required Pnonty management attention required

Rating s

Near Certainly (81-100%)

Highly L.Jkely • ~ 3 ::; 2 • (61-80%)

L.Jkely (41-60%)

Low L1kellhOOd

Some dtsrupbOn Olfferen1approach may be reqwred Add1tJOna1 management anent.ten may b<! needed

(2 1-40%) Notl.Jkely

1().20%1

Coat

> S5M

SIM·SSM

S250K- S1M

SSOK· S250K

< SSOK

Cu11tqt1tt1et

Consequence

Schedule

Cannot meet key program milestones

Program enbcal path atte<:ied

Minor schedule Slip Able to meet key milestones with no schedule float

Allie to meet key dates

Performance

Does not meet KPP

Mm1mum impact M.nimum overs.;ht needed to ensure nsk remains low

S1gMicanUy degrades system perfonnance Does nol meet capablhty requirements

Minimum system impact No performance margin but meets capab1l1ty

Minor impact Reduced perlonnance margin

Minimum impact Consequences ul'llmportant

Figure 3.3-2 Risk Cube

3.4 Technical Organization

The product office organization is depicted in Figure 3.4-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

Business Branch

- USMC Program Integrator

· Program Analyst/SchecUer

• Pro gnm Analyst . Cost Analyst

· Program Analyst

• Proc~ment Analyst

• ProC\.W'ement Analyst

• Proc~ment Ana

- Product Manager

• Dep.(y Product Manager

- Assistant Product Manager

- Assistant Product Manager

• National Guard Liaison

·Safety and Standards Officer

- Operations AN lyst

• Ser*> r Operations Analyst

- Ser*>r Operations Analyst

Branch

· Aeet Manager

· Lead Logistician

Sustanment Branch

- Branch OWef

• Maintenana Teom Lead

· Reset/Preset Coordinator

- ReacSness Teom Lead

· Rea<iness Coordnator

· USMC Liaison

• FMS Liaison

1...-__!!!l!~~Bt!!!;rai:!!::idl~-.J+--+j -Operations Support

• Branch OWef

Systems Enclnttrtnc

· Lead Engineer (ProO..ction)

• ~ral Engineer (Quality)

· ~ral Engineer (CM)

· ~r.il Engineer (Proo..ction)

• ~ral Engineer (RAM)

Test Enpneerinc

• Le;id Engineer

• ~ral Engineer

Product Enclneertnc

- Lead Engineer (TCDL)

• ~ral Engineer (AV)

- General Engineer (Ground Sots)

• ~ral Engineer (Software)

- General Engineer (Radios)

• ~ral Engineer (Propulsion)

· ~ral Engineer (Weapons)

• ~ral · er {Payk>ad)

· Supply Team Lead

- Logistics Specialist, x7

Acq Loe & P8l Branch

• Br.inch OWef

• P8L Team Lead

• Logistics Specialist, x2

• Acq Log Team Lead

· Logistics Specialist, xS Retd9lc & Tralnm,c llnnctl

• Br.inchOWef

• FielcSng Team Lt!od

· Logistics Specialist, x4

· Training Team Lead ialist, x4

Figure 3.4-1 Product Office Organization

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 Ill 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-1 .

3.4.3 Contractor Program Office Organization

The prime contractor organization is functionally represented in Figure 3.4-2.

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.

j .. ~ , Figure 3.4-2 Contractor Functional Organization

3.4.4 Engineering Team Organization and Staffing

The product office core engineering team is depicted in Table 3.4-1 and the functional team hierarchy is depicted in Figure 3.4-3. Table 3.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.

I Systems Engineering

• Lead Engineer (Production)

• General Engineer (Production)

• General Engineer (CM)

- General Engineer (Production)

- General Engineer (RAM)

Supportability IP

UNCLASSIFIED

Table 3.4-1 Engineering Team Details

Engineering Branch

· Branch Chief I I

Test Engineering

- Lead Engineer

· General Engineer

I- I- c: c

!:!:: !:!:: II> II>

c: I- E E "' 0 !:!:: ~ 0. a.

u ·;;; "' ·:; ·:; ·;: :; <t :!: c; c;

0 a. u .:::: w w l? 0 ~ <l:

Cl.

Vl ~ u.

Figure 3.4-3 IPT/WG Team Hierarchy

UNCLASSIFIED

I Product Engineering

- Lead Engineering (TCDL)

• General Engineer (AV)

• General Engineer (Ground Sys)

- General Engineer (Software)

- General Engineer (Radios)

• General Engineer (Propulsion)

· General Engineer (Weapons)

· General Engineer (Payload)

I-

This page deliberately blank.

Team Name Chairperson

PMIPT PdmGM

Risk IPT PdmGM

IA IPT IA Lead

PdmGM &

SSWG

Safety Mgr

MishaplPT Safety Mu

T&E WIPT

PdmGM&

Test Lead

Product ion IPT SE Lead

Shadow

Obsolescence IPT Obsolescence

Lead

SE IPT SE Lead

UNCLASSIFIED

Table 3.4-2 IPT Team Details

Team Membership Role & ResponslbUlty

Headquarters

- OeputyPdm

Role: provtdes oversight, guidance,

· Assistant PMs stateJllC integration.

- Operat ions Analysts

· Sa fety Manuer

Business Branch Lead

Engineering Lead Schedule: meets weekly.

Logistics Branch Lead

Prime Contractor

Role: identify, document, track, and

Same as PM IPT monitor nsks through rnt11gauon and closure.

Schedule: meets monthly.

IASO

Coordinate issues, status, and solution pjans.

Contractor Leads Schedule: meets w eekly.

PM Role: implement AR 385-16 via

TCMUAS closed loop hazard tracking system

AEO and analysis coordination.

AMCOM Safety

PEO

Schedule: meets quarterly.

Program Office Role: review mishap da ta.

Engineering

Logistics

Pnme Contractor Schedule: meets w eekly.

Program Office

Engineenng

Logist ics Role: implements AR 73· 1 via test

PEO Avn POC strategy integration and advising

TCM UAS PdMGM.

ATEC AEC

ATEC OTC

OUSA-TE POC

OOT&E POC

Schedule: meets semi-annually or as

ASA{AL& Tl T&E POC needed.

SE POC Role: track production issues and

Production POC provide production acuvhy ove1$ight/guidance.

OCMA POC Schedule: meets w eekly.

Product Tech Lead

Engr Brarn:h lead

Fleet Mgt POC

Role: assess obsolescence impacts, PBL Lead trends, and status resolution clans.

AMRDEC Obsolescence

Team Schedule: meets w eekly.

System Engr Leads

System Engr Leads

· Avtonics

• Propulsion Role: provide product and

- C41 lunctional system engoneenng

- Software 1ntegrauon and oversight.

- Control Equipment

- Support Equipment

- Reliability

- Test

·Production

- Obsolescence Schedule: meets w eekly.

· Quality

Contractor Enl!f Leads

Logistics POC

UNCLASSIFIED

Products and M etrics

Products:

- Acqus1tion Str.lleRY.

- Cost Analys.s

Requirements Document.

• ILS Plan.

Integrated Master

Schedule.

Metrics: - -Cost .

• Performance.

- Schedule.

Risk management plan.

Mitigation status.

Met rics: minutes, action Items.

Products: hazard tracking logs, nsk acceptance documents.

M etrics: mishap trend analysis, hazard closure rate.

M ishap Rates.

Trend Analvsis.

Causal Analysis.

Action It em$.

Products: TEMP and derivative plans and reports.

Metrics: cntical t echnical parameter & measure of ellect1veness identilication/track1nR.

Production deliveries.

Cost/Schedule metrics.

Perfonmance.

Products: acquisition strategy, cost analysis.

sustainment plan inputs;

trend analysis, acuon item tracking.

Metrics: system health analysis reports, issue resolution metrics.

Products: problem change report (PCRI tracking & disposit ion, 1ssue/act1on item t racking. use case and technical performance measure approval.

Metrics: critical technical parameter$, PCR burn-dow n/schedule.

Team Name Chairperson

Avionics IPT AV Lead

Aircraft IPT AV Lead

Propulsion Propulsion IPT

Lead

C41 IPT

Software IPT PdMTUAS

Software Lead

Contro l Control

Equipment Equipment IPT

Lead

Support Ground Support

Equipment IPT Equipment

Lead

Failure Review Reliability

Board Lead

Quality IPT QualityPOC

Logistics

Supportability IPT Sustainment

Lead

UNCLASSIFIED

Team Membership Role & Responsibility

Avionics POC Role: coordinate issues and status

Quality POC solution plans.

Contractor POCs Schedule: meets weekly.

Avionics POC Role: coord inate issues and status

QualityPOC solution plans.

Contractor POCs Schedule: meets weekly.

Logist ics POC Role : coordinate issues and status

Quality POC solution plans.

Navy POC Schedule: meets bi-weekly on

Propulsion POC Tuesdays at 0900 CDT /CST.

Not currently active

Role : Review status of Shadow Vl

Logistics POC 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.

Contro I Equip POC Role: coord ina te issues and status

Quality POC solution plans.

Reliability POC Schedule: monthly on Thursdays at

System Engr POC 1000 CST.

Support Equip POC Role : coordinate issues and status

Quality POC solution plans.

System Engr POC Schedule: monthly on Wednesdays

Contractor POCs at lOOOCST.

Avionics POC

Propulsion POC Purpose: assess new failures, trends, C41 POC

Software POC and corrective action plans.

Control Equip POC

Support Equip POC

Production POC

Quality POC Schedule: meets monthly.

Logistics POC

QMPOC Purpose: review open PQDRs, assess open general quality issues including DCMAPOC MRB actions, and review open CARs and SCARs.

Supply Support Lead

Maintenance Lead Role: manage and monitor

Readiness Lead

Training Lead requirements compliance.

Fielding Lead

ILS Lead

PBL Lead

Marine Corps Logist1cian

FMS Specialist

Maintenance Specialist Schedule: meets weekly.

COL TS/UAS·I Specialist

Reliability POC

Item Manager

Prime Contractor POCs

UNCLASSIFIED

Products and Metrics

Producls: minutes, action items, PCR Status.

Metrics: FRB top 5 solut ion completion status.

Products: minutes, act ion items, PCR Status.

Metrics: FRB top 5 solution completion status.

Products: minutes, action items, PCR Status.

Metrics: FRB top S so lut ion completion status.

Metrics: Minutes, Action

Items

Metrics: Minutes, Action

Items, Problem Change

Report (PCR) Status.

Metrics: M inutes, Action

Items, Problem Change

Report (PCR) Status.

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

Metrics: failure cost, quant ity, rate per 100,000 flight hours.

Metrics: Quality

Improvement Process

(QIP) data.

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

Metrics:

• System Status

Readiness.

• Depot Mean Down

Time.

• MWO Status.

·Supply Chain Status.

• Mean Time to Repair.

· Availabili ty.

3.5 Relationships with External Technical Organizations

The TRADOC Capability 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 (P31) and other design reviews during this operations and support phase include TCM-UAS involvement. The contractors implementing tasks under this SEP, if they have external dependencies under their task orders then they will develop and provide an external dependencies chart or section in their SEP that corresponds to the latest approved SEP outline as required by ASA(AL&T) memorandum dated 2 July 2012, Subject: Army Level Approval Authority for System Engineering Plan and Guidance. The TEMP documents the methodology by which PM TUAS 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 tailors 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 . The program has availability, system abort, and mean time-to-repair requirements. It has no discrete system level or subsystem (aircraft) reliability requirements. Each engineering change executed by our contractors or agencies under this SEP assesses the reliability change impact.

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

Technical Performance Measures

(Each P31 or capability upgrade augments with additional TPMs correlating to Performance Attribute)

TPM Name Responsible IPT KPP (K) or CTP (CJ Theshold

Status Correlation Value

Range (CJ 125 Km Endurance (C) 7 Hours TLE (C) < 50m

8000 ft

AGL, 7000

ft Probability of Recognition

(K) and (CJ standoff given Detection (P(R/D)) (day);

SE IPT

6000 ft standoff

(night)

C41 Interoperability (K) and (CJ

MIL-STD-

E3 (CJ 464, ADS-

37A- PRF,

MTBSA (C) 20 Hours

CPU Usage No < 50%

Memory Usage No < 50 %

Network Utilization and Speed SWIPT No None

Throughput (reserve) No >= 50% Disk Utilization No

PM IPT,

Unit and Life Cycle Cost Supportability IPT, No None

SEIPT

Mean Time to Repair (Field) Supportability IPT (C) 2 hours

SE IPT

Space, Weight, and Power Varies as Avionics IPT No

(SWAP) required

Propulsion IPT

Emplace, Displace Time (CJ 180, 60

Minutes

Transportability and

(CJ

Deployability Control

Weight Equipment I PT No

(CJ

Soccer

Launch and Recovery Field Area

KPP = Key Performance Parameter; CTP = Critical Technical Parameter

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 104 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 P31 program as well as continued system operations and sustainment. Prior methodology and processes (as in prior approved SEP, 7 March 2007) 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 military sales. For example, SEP Section 4.4 discusses uses cases. These are additionally ta ilored 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 introduces the Integrating Joint Configuration Control Board (1-JCCB) as documented later in SEP Section 4.3.2. IJCCB structure and responsibilities are more fully described in UAS-MISC-001. 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 1-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. 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 Requests (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 product baseline and is responsible for merging new capability and/or improvements (configuration changes) into the product baseline using SEP methodology, processes, and procedures.

The program manager and chief engineer exercise 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.

This SEP, the TUAS RMF System Security Plan (Version 1.0, December 2015), and associated contract implementation introduces DOD Architecture Framework Documentation (Dl-MGMT-81644), Information System Accreditation Plan (Dl ADMN-80239) , Information Security Boundary Configuration Management Plan (Dl-SESS-81343), and Information Assurance Design Review Information Package (Dl-MGMT-81845). This corrects prior data delivery shortfalls linked to inadequate contractor data delivery instructions. Additionally, Appendix B records applicable technical readiness review criteria.

RMF in the Product Lifecycle

System ldenllfteollon Profile (SIP)

• S.,k<J bow line - ny control.

• Apply o~rloy> Tooloring

Concept of 0 Operations

• Copture IA require~" (DOORS)

I ill.JU

IA Fvnd1onal Spec1f1cat1ons

• Cr..ote IA funcrionol Module (DOORS) •O..rtv.. IA Controlt for Sy11em V.W 8500.2

0 Reqli'ements and

Architectlre ond AR·25-2 . PPS CAL, Common Cnterio lat for HW, OS & Ncrwo<I<, Appllcollon Software, STIG.

~II.

IA Arch1teC1Vrol Speetfrcotrons

• Acceptobk Rhlr O..tc'"*10110n (ARD) Score Co<d -tnr.,...,.,i Re~ of Olog<arm. 0010 Ac.•, Nc""oric, HW / SW I.hi, SW ~Pie.\ PPS, IA

.r4!Xb•1~~ (DOORS)

Detaned

0 Design

Verification and

Validation

Operation llCI

MailtenllCe

0 ""9ttfffx A n et• m."h

O Maintenance

• Continuou> Monit0<lng of OtSA r~quiremcntt, DlP; and syuem ~o.mry posture s t A!;}.. S<~&"lll••'•"'..ATO J<_,'4

V~ca~n 0 External Cert. and Accredit.

and "aid ti · Provide ATO Podcoge to 3"' Pony IA V' a on Aswnment Teom

•Support Volidorlon of fundional Spe<ificorlom

Integration, oh· lvild~ ,Cl Voril. f. • S.on, s ... ,.

Test, and Internal Cert. And Accredit.

Verification • OA CM Reteow of doa Dara AO'"', Nc1won., HW SW Lists, PPS. SW ~ Pion, CM Pie.\ Bounc:lory O.ogram, AC.A Oue-1'ionnc,.re, IAVM Pion, SW Ploeords

• Perform IA Scon on Producllon Syst""' -G..n..r01e CM Soseliirwe Medio

~r01e / Updo1e IA Complicn:r Monflor si.-1 1

Implement Security Design

PLANNING IS THE · Apply Po1ch Configs • Configure one! ""'""· ~ env. 5con 1oo1s MOST IMPACTED · Apply s..a.n1y Conflg• ' "' por1 mon1tor1ng

• CJ.\ a>ntrolkd OS lounch lmogn

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.