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?
Top Related