Auxiliary-hosted Regional Geosynchronous Optical Space Situational Awareness (ARGOS) System BRIAN BONE SUBMITTED IN PARTIAL FULFILLMENT FOR THE DEGREE OF MASTER OF SCIENCE IN ENGINEERING, IN SYSTEMS ENGINEERING

1

Agenda Biography System Introduction and Need System Requirements Development Approach CONOP Summary Functional Analysis Summary Physical Concept Summary Trade Study Summary Specifications Summary Risk Management Summary Further Work Required Lessons Learned Course Recommendations

2

Agenda Biography System Introduction and Need System Requirements Development Approach CONOP Summary Functional Analysis Summary Physical Concept Summary Trade Study Summary Specifications Summary Risk Management Summary Further Work Required Lessons Learned Course Recommendations

3

Biography – Brian Bone 16 years as Developmental Engineer in USAF

MILSATCOM satellite TT&C replacement effort – concept development through prototype demo; successful large SW development effort

Nevada Test and Training Range safety analysis – mod/sim of munitions

delivery profiles for tests, training, and exercises Space Control plans and programs – system SME representing user for

block upgrades and new systems – CONOPs, operational requirements Space experimentation – operated unique experimental space and

ground systems to validate operational utility and develop CONOPs

4

Biography – Brian Bone (cont’d) 16 years as Developmental Engineer in USAF (cont’d)

Space Protection requirements lead – assess needs and develop operational requirements for new programs of record

DoD Space Test Program – manage rideshare* programs and launch

vehicle integration for promising technologies from defense and university laboratories

Currently supporting Space Test and Training Range as Systems Engineer Range system modernization user SME – TO review & validation; SoS

integration with NTTR and other virtual and constructive ranges

5

* Rideshare = additional satellite hosted on launch vehicle dedicated to different mission

Agenda Biography System Introduction and Need System Requirements Development Approach CONOP Summary Functional Analysis Summary Physical Concept Summary Trade Study Summary Specifications Summary Risk Management Summary Further Work Required Lessons Learned Course Recommendations

6

System Introduction & Need Introduction: SSA

7

Space Situational Awareness “…[is] the ability to view, understand and predict the physical location

of natural and manmade objects in orbit around the Earth” – Space Foundation

Objectives: avoid collisions, protect valuable assets, and characterize objects of interest

Until recently, exclusive domain of governments and militaries (US DoD)

“Space Traffic Management” (i.e., collision avoidance) becoming more difficult for US DoD’s JSpOC

GEO of critical importance!

System Introduction & Need Introduction: Current systems for GEO SSA

8

Ground-based sensors Telescopes

Work only in darkness and with clear skies Revisit times for each observed object: hours to days Suffer from atmospheric effects such as turbulence

Radars All-weather, day/night Revisit times much less than for telescopes Accuracy at GEO is very limited (very good for

absolute range)

Dedicated space-based sensors No terrestrial atmosphere/weather limitations Much shorter average revisit times Highly accurate EXPEN$IVE!

System Introduction & Need System Needs & Objective

9

N.1 Need an SSA system providing persistent observation of RSOs in the GEO belt.

N.2 Need an SSA system that collects accurate observations with minimal outages due to poor viewing conditions.

N.3 Need an SSA system with short revisit times between RSO observations.

N.4 Need an SSA system that can be produced quickly at low cost

N.5 Need an SSA system avoiding national security policy issues while meeting customer requirements for data necessary to meet international requirements for the responsible use of space.

Objectives: Develop an Engineering Design Model to demonstrate low-SWaP sensor and communications suite, and scalable ground-based processor; reduce risk and mature

production-quality design.

Agenda Biography System Introduction and Need System Requirements Development Approach CONOP Summary Functional Analysis Summary Physical Concept Summary Trade Study Summary Specifications Summary Risk Management Summary Further Work Required Lessons Learned Course Recommendations

10

Requirements Development Approach

Sources “Paper”: Industry websites, industry publications, conference proceedings SMEs: Commercial satellite service provider CEO, satellite manufacturer executive, and published

optical SSA SME

Approach Analysis

Understand the need, consider alternatives Define system context

Decomposition Determine the “whats” of the system (CONOP, functions) Break down “whats” to lowest necessary level

Synthesis Determine the “hows” and “how wells” necessary to implement the “whats” (operational, interface,

constraint requirements and performance measures) Perform traceability analysis and iterate as necessary at each level

11

Requirements Development Approach

Statistics: Total requirements: 148

Functional Requirements: 56

Operational Requirements: 66

Interface Requirements: 20

Constraints: 6

12

Requirements Development Approach – Initial KPPs

13

Number Name Description - Threshold Description - Objective

O.1 Detection sensitivity at

radial distance

The system shall sense resident space objects as small as a 1m unpainted, diffuse aluminum

(Lambert) sphere up to 30 degrees away on the GEO belt.

The system shall sense resident space objects as small as a 1m unpainted, diffuse aluminum

(Lambert) sphere up to 60 degrees away on the GEO belt.

O.15 Orbital regime The system's Space Segment shall be designed to

operate in the GEO orbital regime

O.16 Mean mission duration/

design life

The sytem's space segment shall be designed for mean mission duration of three years and a design

life of five years.

The system's Space Segment shall be designed for a mean mission duration of five years and a

design life of seven years.

O.2 Bidirectional sensing

The system shall sense resident space objects in both the plus- and minus-velocity vector directions

(annotated as "east" and "west" respectively) from each host satellite.

O.5 SSA Accuracy

The system shall produce SSA observations with less than 500m radial uncertainty using SGP4/SDP4

propagation for a detected reference RSO within two observational opportunities

The system shall produce SSA observations with less than 10m radial uncertainty using SGP4/SDP4 propagation for a detected reference RSO within

two observational opportunities

Requirements Development Approach – Initial KSAs

14

Number Name Description - Threshold Description - Objective O.13.1 Processing capacity The system shall have the capacity to process

data from up to 12 sensors (six satellites hosting two sensors each) simultaneously.

The system shall have the capacity to process data from up to 20 sensors (10 satellites hosting two sensors each) simultaneously.

O.20 Operational availability

The system shall have an operational availability (AO) of .98 for any 30-day period.

The system shall have an Ao of .995 for any 30-day period.

O.20.1 System Reliability The system shall have a reliability figure of .99 for any 30-day period

The system shall have a reliability figure of .998 for any 30-day period

Agenda Biography System Introduction and Need System Requirements Development Approach CONOP Summary Functional Analysis Summary Physical Concept Summary Trade Study Summary Specifications Summary Risk Management Summary Further Work Required Lessons Learned Course Recommendations

15

CONOP Summary – OV-1 16

CONOP Summary - Scenarios Launch & Early Orbit Ops

Scenario begins at host satellite mate to rocket

Environment: violent vibration, shock, and acoustics; rapid thermal and air pressure changes lasting several hours

ARGOS payload must survive launch, satellite separation from rocket, and activation without damaging host satellite or rocket

ARGOS allows host satellite to activate and verify own function before being allowed to activate ARGOS payload

Payload Operations Center verifies ARGOS function via brief test campaign

Scenario ends on declaration of ARGOS ops readiness

17

CONOP Summary - Scenarios Steady-state operations

Scenario begins on declaration of ops readiness Environment: GEO space (vacuum, thermal, radiation, light) Collect observations of host satellite’s GEO region

POC determines when sun/moon will interfere with observations (~2 hours per day) or other no-image windows and uploads to ARGOS space segment

ARGOS collects raw images of existing GEO Resident Space Objects in FOV ARGOS collects images of new objects arriving within FOV (maneuvers, launches) ARGOS collects optical brightness data of each observed RSO over time

Payload Data Center processes observations for and stores SSA data Update orbital data of existing RSOs Determine orbital data of new RSOs Characterize optical brightness signature of RSOs over time

PDC Disseminates SSA data Notify customers of new data Authenticate and transmit authorized data to customers

18

CONOP Summary - Scenarios End-of-life and Disposal

Scenario begins when EOL determination is made Environment: GEO space (vacuum, thermal, radiation) Anomaly on host satellite:

May require ARGOS to shut down to provide additional power or thermal margin for host satellite

Host satellite can cut off power to ARGOS in emergency, otherwise will request from Payload Operations Center

Anomaly on ARGOS payload: POC initiates shutdown procedure and notifies host satellite

owner/operator POC requests host satellite owner/operator shut down payload ARGOS’s power and communications paths available to host satellite

“Natural” end of mission life Graceful shutdown of satellite and/or ARGOS payload

19

Agenda Biography System Introduction and Need System Requirements Development Approach CONOP Summary Functional Analysis Summary Physical Concept Summary Trade Study Summary Specifications Summary Risk Management Summary Further Work Required Lessons Learned Course Recommendations

20

Functional Analysis Context Diagram

21

Functional Analysis Function Tree

22

Functional Analysis Top Level Functional Block Diagram

23

Functional Analysis N2 Diagram

24

Functional Analysis Function to Requirements Traceability

25

Verified all functions trace to one or more requirements All functions are fully implemented

Verified all requirements trace to a function All requirements are necessary and value-added

Where one function had more than five allocated requirements, analyzed function for possible further decomposition

Where only one requirement implemented one function, analyzed requirement for possible further decomposition

Where a requirement implemented more than one function, analyzed requirement and functions for possible further decomposition

Agenda Biography System Introduction and Need System Requirements Development Approach CONOP Summary Functional Analysis Summary Physical Concept Summary Trade Study Summary Specifications Summary Risk Management Summary Further Work Required Lessons Learned Course Recommendations

26

Physical Concept Top Level Physical Block Diagram

27

Physical Concept Level 2 Physical Block Diagram – Space Segment

28

Physical Concept Software Data Flow Diagram – SSA Processor

29

Physical Concept Physical Interfaces

30

Physical Concept Physical to Functional Traceability

31

Verified all functions trace to one or more physical components All functions are fully implemented by allocated components

Verified all physical components trace to a function All components are mature, necessary, and value-added

Verified all requirements are satisfied by one or more physical components

Verified all component alternatives meet or exceed required performance measures

Agenda Biography System Introduction and Need System Requirements Development Approach CONOP Summary Functional Analysis Summary Physical Concept Summary Trade Study Summary Specifications Summary Risk Management Summary Further Work Required Lessons Learned Course Recommendations

32

Trade Study Introduction

Selected component for trade study: Optical Camera Primary physical component necessary for SSA mission

Do not desire to develop brand-new component due to cost and time constraints

Sufficient maturity, capability, and number of “off-the-shelf” alternatives available

Alternatives Considered Malin Space Sciences Systems (MSSS) ECAM-M50

Sodern SED26 Star Tracker

Space Dynamics Laboratory (SDL) Digital Imaging Space Camera (DISC)

JenaOptronik Astro APS

33

Trade Study Selection Criteria

34

Sensitivity (magnitude) – dimmer magnitude is better Mapped requirement: O.1, Detection Sensitivity at Radial Distance (KPP)

Threshold: Detect 1m Lambert sphere at 30o angular separation

Objective: Detect 1m Lambert sphere at 60o angular separation

Mass (kg) – lower is better Mapped requirement: L.4, Payload Mass (KPP)

Threshold: Space Segment mass <100kg

Objective: Space Segment mass <50kg

Trade Study Selection Criteria (cont’d)

35

Size (cm3) – smaller is better Mapped requirement: L.5, Payload Volume, added during trade study criteria

development Threshold: 330,000 cm3, with vertical dimension (above payload deck) not to exceed 70cm

Power consumption (W) – lower is better Mapped requirement: L.3, Power Consumption (KPP) Threshold: Space Segment power consumption <120W Objective: Space Segment power consumption <50W

Design Life (years) – longer is better Mapped requirement: O.16, Mean mission duration / design life (KPP) Threshold: Space segment MMD >3yrs, design life >5yrs Objective: Space segment MMD >7yrs, design life >10yrs

Trade Study Selection Criteria (cont’d)

36

Criteria Name Definition Worst -------------------------------------------> Best

Sensitivity (mV) (magnitude)

How dim an object can the camera detect?

< 15 MV 16 MV 16.5 MV 17 MV ≥ 18 mV

Mass (kg) Mass of camera assembly and any included components

≥ 50 kg 42 kg 34 kg 26 kg ≤ 18 kg

Size (cm3) Volume of camera assembly

v ≥ 43,000 cm3

33,000 cm3 23,000 cm3 13,000 cm3 v ≤

3,000cm3

Power (W) Peak power consumption of camera assembly and any included components

≥ 50 W 40 W 30 W 20 W ≤ 10 W

Design Life (years) How long will the camera assembly last on orbit?

< 5 years 6.25 years 7.5 years 8.75 years ≥ 10 years

Trade Study Trade Study Criteria Weighting Process

37

Applied Pairwise weighting method with Nth-root normalization Derived relative weights from SME interviews and relevant research Of note: Mass and Power Consumption were valued higher than sensitivity

“You can build the best camera in the world, but if it can’t fit on your desired satellite, it’s useless as a hosted payload”

Build the best hosted SSA payload that will fit on the widest selection of potential hosts

Optical Sensitivity

Mass Size Power Design Life

Nth Root of Row Value Products

Normalized Weighting

Factor Optical Sensitivity

1.000 0.500 2.000 0.500 4.000 1.149 0.188

Mass (kg) 2.000 1.000 3.000 2.000 3.000 2.048 0.336

Size (cm3) 0.500 0.333 1.000 0.500 2.000 0.699 0.115

Power (W) 2.000 2.000 2.000 1.000 2.000 1.741 0.286 Design Life (years)

0.250 0.333 0.500 0.500 1.000 0.461 0.076

Sum of Nth Root values 6.097

Trade Study Utility Curves

38

Derived from market research of available alternatives Product fact sheets or brochures

Other internet research

Proprietary information not available without signed NDA and intent to purchase

Linear in all cases

Fail to meet thresholds equals utility of zero; meeting or exceeding objective values equals a utility value of 1

Trade Study Utility Curves

39

Sensitivity Utility Function: y = (1/3)x - 5 Mass Utility Function: y = -(1/32)x + 1.5625 Size Utility Function: y = -(1/40000)x + 1.075

Power Consumption Utility Function: y = -(1/40)x + 1.25 Design Life Utility Function: y = (1/5)x - 1

Trade Study Final Matrix

40

Criteria Criteria Weight

Malin Space Science Systems ECAM-M50

Sodern SED26 Star Tracker Space Dynamics Laboratory Digital Imaging Space Camera (DISC) JenaOptronik Astro APS

Raw Score

Utility Value

Weighted Utility Value

Raw Score

Utility Value

Weighted Utility Value

Raw Score

Utility Value

Weighted Utility Value

Raw Score

Utility Value

Weighted Utility Value

Sensitivity (mV) 0.188393 18 1 0.188393 12 0 0 16.5 0.5 0.094196 6 0 0

Mass (kg) 0.3358297 1.366 1 0.33583 3.7 1 0.33583 0.6 1 0.33583 2 1 0.33583

Size (cm3) 0.1146116 1118 1 0.114612 9520 0.837 0.09593 1400 1 0.114612 5620 0.9345 0.1071

Power consumption (W)

0.2855503 15.5 0.8625 0.246287 13.5 0.9125 0.26056 2 1 0.28555 11 0.975 0.27841

Component design life (years)

0.0756154 10 1 0.075615 18 1 0.07562 8 0.6 0.045369 18 1 0.07562

Operational Utility Function (Weighted Sum) 0.960736831 0.76793971 0.875557352 0.796961231

Unit Cost ($) $525,000 $550,000 $328,000 $575,000

Cost-Effectiveness Selection Function (weighted Sum / Cost)

1.82997E-06 1.39625E-06 2.66938E-06 1.38602E-06

Agenda Biography System Introduction and Need System Requirements Development Approach CONOP Summary Functional Analysis Summary Physical Concept Summary Trade Study Summary Specifications Summary Risk Management Summary Further Work Required Lessons Learned Course Recommendations

41

Specification Summary Statistics, from RAR to System Specification:

Added 47 requirements 38 Operational requirements

9 Interface requirements

Primarily as a result of discovery during physical architecture phase

Changed 5 requirements Upgraded two to KPPs (Power Consumption and Mass)

Changed values on 4 requirements (more stringent in all cases) including 2 KPPs (Power Consumption and Mass)

Result from trade study and SME interviews

42

Specification Summary Final KPPs

43

Number Name Description - Threshold Description - Objective Verification Method

(I/A/D/T)

O.1 Detection sensitivity at radial distance

The system shall sense resident space objects as small as a 1m unpainted, diffuse aluminum sphere up to 30 degrees away on the GEO belt.

The system shall sense resident space objects as small as a 1m unpainted, diffuse aluminum sphere up to 60 degrees away on the GEO belt.

A

O.15 Orbital regime

The system's Space Segment shall be designed to operate in the GEO orbital regime

A

O.16 Mean mission duration/ design life

The system's space segment shall be designed for mean mission duration of three years and a design life of five years.

The system's space segment shall be designed for a mean mission duration of five years and a design life of seven years.

A

O.2 Bidirectional sensing

The system shall sense resident space objects in both the plus- and minus-velocity vector directions (annotated as "east" and "west" respectively) from each host satellite.

I

O.5 SSA Accuracy

The system shall produce SSA observations with less than 500m radial uncertainty using SGP4/SDP4 propagation for a detected reference RSO within two observational opportunities

The system shall produce SSA observations with less than 10m radial uncertainty using SGP4/SDP4 propagation for a detected reference RSO within two observational opportunities

T

L.3 Power Consumption

The system's space segment shall draw no more than 120 Watts of power from the host satellite

The system's space segment shall draw no more than 50W of power from the host satellite

T

L.4 Payload Mass The system's space segment mass shall be less than 100kg

The system's space segment mass shall be less than 50kg

T

Specification Summary Final KSAs

44

Number Name Description - Threshold Description - Objective Verification

Method

O.13.1 Processing capacity

The system shall have the capacity to process data from up to 12 sensors (six satellites hosting two sensors each) simultaneously.

The system shall have the capacity to process data from up to 20 sensors (10 satellites hosting two sensors each) simultaneously.

A

O.20 Operational availability

The system shall have an operational availability (AO) of .98 for any 30-day period.

The system shall have an Ao of .995 for any 30-day period.

A

O.20.1 System Reliability

The system shall have a reliability figure of .99 for any 30-day period

The system shall have a reliability figure of .998 for any 30-day period

A

No change from RAR

Agenda Biography System Introduction and Need System Requirements Development Approach CONOP Summary Functional Analysis Summary Physical Concept Summary Trade Study Summary Specifications Summary Risk Management Summary Further Work Required Lessons Learned Course Recommendations

45

Risk Management Approach

Smith & Merritt, Proactive Risk Management: Controlling Uncertainty in Product Development (2002) Standard Risk Model

Assign Probability of Risk Event and Probability of Impact (< 1 in most cases)

Determine Risk Event and Impact drivers

Define Total Loss (usually in terms of money or time)

Calculate and track Expected Loss (Pe x Pi x LT = LE)

46

Risk Management Approach (cont’d)

Risk threshold defined based on maximum tolerated expected loss Curve of threshold based on best fit (linear, exponential are most

common) Risks defined as Active or Inactive based on above/below threshold on

plot of expected loss vs. probability of loss Active risks require a mitigation plan to address Event drivers, contingency

plan to address Impact drivers, and “Closed” criteria

Inactive Risks require monitoring plan and “Active” criteria

Goal: reduce expected loss (or total loss for risks that become issues) to below risk threshold line

Benefits: more fidelity in risks, forces proactive risk planning, and directly involves SE and PM to mitigate risks together

47

Risk Management Summary

48

Agenda Biography System Introduction and Need System Requirements Development Approach CONOP Summary Functional Analysis Summary Physical Concept Summary Trade Study Summary Specifications Summary Risk Management Summary Further Work Required Lessons Learned Course Recommendations

49

Further Work Required Project is executable

Realistic work performed to date

All technologies referenced are TRL 5 or higher

With some additional development would work as commercial venture or as government/military gapfiller or augmentation system

Some requirements may need additional assessment and possibly adjustment to be successful Essential M&S tools not available to me during this project (>$10K)

Specific expertise in optics to perform detailed analysis

50

Further Work Required Space Segment

Optical camera Determine whether additional optimization of selected alternatives is

beneficial over “off the shelf” capabilities Both MSSS ECAM-M50 and SDL DISC offer customizable optics Potential fly-off through EDM? Additional analysis requires Systems Tool Kit (STK), plus Analysis

Workbench, Astrogator, Integration, and SatPro modules

Optimum hosted payload spacing vs. likely spacing along GEO belt M&S using STK to determine GEO belt coverage and overlap given ideal

and expected launch schedule and location Determines when availability and reliability figures can be met May influence optical camera optimization decision

51

Further Work Required Ground Segment

Sizing data storage capacity Storage Area Network – File System (SAN-FS) provides inherent reliability

and availability through redundancy, even across geographically separated sites

Study to determine how much storage space is required to achieve necessary PDC reliability and availability, including on-hand spares

Sizing SSA Processor capacity Cluster computing uses arrays of inexpensive, readily available rack-

mounted processors to share computationally intensive tasks for faster processing

Study to determine PDC computational loading at IOC (one hosted payload on orbit) and FOC (all hosted payloads on orbit) and thus derive number of processors in cluster plus spares, and growth plan through FOC

52

Agenda Biography System Introduction and Need System Requirements Development Approach CONOP Summary Functional Analysis Summary Physical Concept Summary Trade Study Summary Specifications Summary Risk Management Summary Further Work Required Lessons Learned Course Recommendations

53

Lessons Learned Project Related

Unexpected Complexity Very good mental picture of high-level system architecture Functional architecture was straightforward Physical architecture presented challenges

SSA processor software architecture

Required some re-work and additional research

Abundant scholarly knowledge, scant accessible practical knowledge SSA at GEO recently declassified with specific systems acknowledged Many conference proceedings on topic Many SMEs still reluctant to talk about topic, even the authors of conference

papers! Many related components protected as proprietary technology

54

Lessons Learned Systems Engineering Related

Complexity isn’t always apparent at the start Concept development and functional analysis cannot be short-cut Results in more complete functional description and CONOP, leads to more

complete requirements Reveal technical risks and provide developer and customer opportunities to make

informed decisions early in program

Ensure customer understands proposed architecture early Necessary to ensure we’re designing the correct system as well as designing the

system correctly

“Failures” in early testing is a good thing Favorite lesson from 645.769, System Test and Evaluation DoD space background ingrained mortal fear of test failures Test “failures” early in development necessary to learn about system and find

“corners of the envelope”

55

Agenda Biography System Introduction and Need System Requirements Development Approach CONOP Summary Functional Analysis Summary Physical Concept Summary Trade Study Summary Specifications Summary Risk Management Summary Further Work Required Lessons Learned Course Recommendations

56

Course / Program Recommendations Combine Concept and Proposal

Duplicate effort - already being implemented for Fall 2015

Provide document templates and page limits Unsure in some cases if providing sufficient detail or too much Help guide, standardize and constrain content Short time to produce work-quality documents to demonstrate knowledge;

helps students plan and assess effort Would also provide more consistent product for mentors and instructors to

evaluate

Develop course focusing on engineering risk management Vital task too often overlooked, especially by government teams SE’s at all levels at least participate in, if not execute risk management programs Elective course would provide skills that would make JHU SE grads more

valuable

57

Conclusion I’ve thoroughly enjoyed my time learning from my instructors and fellow

students

I feel comfortable with advanced SE concepts as presented in my JHU coursework

I feel I’ve demonstrated sufficient knowledge of Systems Engineering through my Final Project deliverables

ARGOS is an executable project requiring a reasonable amount of work to move it forward

I feel I’ve met all requirements necessary to earn the degree of Master of Science in Engineering in Systems Engineering

58

Questions and Feedback?