System F6 Accomplishments Space Programs

1
System F6
Dr. Owen Brown Tactical Technology Office Defense
Advanced Research Projects Agency May 2008
Approved for Public Release, Distribution
Unlimited
2
Contents

• System F6 Overview
• Monolithic vs. Fractionated Architectures
• F6 Technical Concepts
• Program Details
• Econometrics

3
Embracing Uncertainty
4
System F6 Overview
Program Goals and Objectives Demonstrate a new
space system architecture which replaces
traditional monolithic spacecraft with a wireless
virtual spacecraft operating as a cluster of
modules.
Technical Approach Create an architecture of
distributed modules that enable all major
spacecraft hardware components to function as
network-addressable and shareable devices.
Base architectural design and system engineering
trades on maximizing system lifecycle value,
rather than simply minimizing cost.
Click on title for link to Program Goals
specified in BAA
5
System F6
Monolithic to Fractionated Satellite Architectures
6
Paradigm Shift in Space System Design
Monolithic to Fractionated Satellite Architectures
7
Fractionated Architectures
High
A monolith with F6 interface and interoperability
capabilities (i.e. network, wireless link, etc.).
F6-enabled spacecraft system with payloads and
support systems distributed across a cluster of
modules
Support Function Distribution
Todays state-of-the-industry practice for
spacecraft design (no F6 enabling technologies).
Decoupling of multi-payload requirements and
interactions (no F6 enabling technologies).
Low
Low
High
Mission Function Distribution
8
Lifecycle Cost and UtilityMonolithic vs.
Fractionated
ConceptDevelopment
Full ScaleDevelopment
Launch
Operations
Retirement
9
Uncertainty in a Spacecraft Lifecycle
ConceptDevelopment
Full ScaleDevelopment
Launch
Operations
Retirement
Funding
Development
Launch
Sources of Uncertainty
Demand
Technology Obsolescence
Performance
Payload Delay
Launch Failure
On Orbit Failure
Cost/Utility Impact of
10
F6 Technical Concepts

• Networking
• Network of uniquely addressable nodes
• Self-forming, reliable, highly available, robust
  and secure

• Wireless Communication
• Enable cooperative module operation
• Maintain confidentiality, integrity and
  interference resistance

• Wireless Power Transfer
• Intra- and (optional) inter-module energy
  transmission
• Enable decoupled sun-pointing and off board power
  service equipment

• Distributed
• Computing / Payload
• Shared resource utilization across modules
• Decoupling individual payload requirements

• Econometrics
• Risk-adjusted, value-based design methodology
• Properly accounts for architectural flexibility
  and robustness

• Cluster Operations
• Autonomous gathering behavior, docking, and
  inter-satellite spacing
• Collision avoidance and maneuvers against threats

Click on Technical Topics for Expanded Description
11
Flexibility

• Scalability
• The addition of component modules incrementally
  increases system capability as modules become
  available in response to increased demand.

Evolvability Upgrades to an existing network are
as simple as adding a new module, thus allowing
the operator to actively respond to technological
obsolescence.
Adaptability The reconfiguration of existing
modules allows for entirely new functionality
with minimal investment.
Maintainability The loss of a module does not
equal mission failure. Minimal functionality is
maintained until a new module can be launched.
12
Robustness
Survivability Launch failures, ASAT attacks, or
other unanticipated events do not result in the
total loss of critical and extremely costly space
assets. The limited exposure risk implies a
quicker, less expensive recovery and is a form of
self insurance.
Fault Tolerance Internal system failures result
only in an incremental loss of utility versus
total loss for monolithic satellites.
Payload Isolation Separate payload modules enable
new operating paradigms and require significantly
less design integration effort.
13
System F6 Schedule
PDR
Notional Timeline
CDR
FRR
Launch 1
Launch 2

• Phase 1 Deliverables
• PDR design of fractionated spacecraft system
  meeting all BAA objectives
• Hardware-In-the-Loop Testbed Demonstrator
• National Security Space stakeholder analysis and
  mission selection

Click on Phase titles for link to Phase-specific
Go/No-Go Criteria
14
System F6 Government Team
Program Management Contract Management
Validation and Verification Subject Matter Experts
Contract Support
Systems Engineering Technical Assistance
Air Force Chief Scientists Office
Government Observers

• The System F6 Government Team draws from
  expertise across multiple disciplines and seeks
  to involve potential government transition
  partners from program inception.

15
System F6 Performers
16
Contracting Status

• Contract Awards and Value

17
Why Econometrics?

• Fractionated spacecraft promise to deliver
  comparable mission performance to their
  monolithic counterparts
• but may have a different cost proposition
• Increased mass due to fractionation overhead
  and duplication
• Decreased mass due to decoupling of pointing
  security requirements
• Reduced integration, assembly, and testing (IAT)
  effort
• Mass production effects
• and enhanced mission utility / value, aside
  from basic performance
• Flexibility to adapt the architecture to
  lifecycle uncertainties
• Robustness to internal and external failures and
  threats
• Ability to reuse on-orbit infrastructure across
  multiple missions or generations
• The F6 performers are developing a suite of
  econometric tools that enable quantitative
  architectural trades on the basis of cost, value,
  and risk impact
• This will help articulate the value proposition
  of fractionation to various stakeholders and
  transition partners

18
Quantifying Value
Architecture Tradespace
Pareto frontier
VALUE
COST
We expect the performers to develop a tool set
that enables the exploration of a broad trade
space of architectures to identify
Pareto-dominant designs
19
Quantifying Risk
Architecture Tradespace with Value and Cost
Variance Ellipses
VALUE
COST
In addition to identifying value-maximizing
architectures, the tool set will offer a novel
capability of quantifying lifecycle risk as the
variance in value and cost metrics
20
Quantifying Risk
Pareto Optimal Architecture Portfolio
Stakeholder Risk Aversion Profiles
Risk Aversion Profiles
Set of Risk-Value Optimal Architectures
NET VALUE
NET VALUE RISK (?net value)
Based on the risk aversion profile of the mission
stakeholder, a risk- and value- optimal
architecture may be selected
21
Phase I Value Modeling Efforts
F6 Demo System
F6 Objective System Analysis
Program of Record Analysis

• Affordable, near-term DARPA tech demo
• Technology objectives treated as exogenous
  constraints on value model
• Short duration of demo mission hides benefits of
  flexibility and robustness
• Value optimized through application of heuristics
  developed in Objective System and PoR analyses

• Extension of DARPA demo to mission(s) with
  warfighter utility
• Multi-attribute utility analysis of objective
  mission(s) (or monetization)
• Development of detailed parametric value and cost
  models to capture flexibility and robustness
• Exhaustive exploration of architectural trade
  space for optimal fractionation of objective
  mission(s)

• Recent major satellite program undertaken by each
  contractor
• Development of several notional variants
• Traditional monolith
• Cluster of single-payload monoliths
• Fractionable monolith
• Fractionated cluster
• Detailed cost and value comparison with
  proprietary cost data
• Sensitivity analysis to key architectural
  parameters

22
Questions
23
Backup Slides
24
Program Objectives Top Level

• Decompose a monolithic spacecraft system into a
  distinct set of two or more modules.
• Demonstrate both pre- and post-launch system
  functionality
• Demonstrate 99 mission availability over one
  month.
• Develop an exhaustive hardware and software
  interface specification
• Demonstrate ability to incorporate mass
  production schemes.
• Develop a risk-adjusted value centric methodology
  which quantifies the net value of flexibility
• Conduct a Multi-attribute Utility Analysis for
  the fractionated system.

25
Program Constraints

• Each spacecraft module will be on a
  smallsat/microsat scale (
• First launch will occur within 4 years of program
  start.
• Modules will be distributed across multiple
  launches.
• The launch vehicle(s) will be commercially
  available, manufactured in the US, and have
  demonstrated at least one successful previous
  launch.
• The on-orbit lifetime of the system will be at
  least one year after the launch of the final
  spacecraft.

26
Enabling Technology Networking

• Demonstrate autonomous, self-forming network of
  nodes
• Ground element treated as another network node.
• Transfer a spacecraft function to ground and then
  back
• Maintain 24/7 TTC
• Demonstrate ground node flexibility
• Re-locate within CONUS in 24 hours

27
Enabling Technology Networking

• Develop a standard hardware and software appliqué
  that enables the packaging and insertion of
  spacecraft components as uniquely addressable
  network devices.

F6 Appliqué
I/O Interface
Payload Electronics
Networked internal sub-systems
28
Enabling Technology Wireless Communications

• Aggressive full duplex data rate via wireless
  communications
• Enables Spacecraft Black Box
• Component maintains data connectivity wirelessly
  to host node and to network
• Wireless networking data protocol between each
  node
• Continues operation in the presence of
  interference

Intra-Satellite Communication
Inter-Satellite Communication
29
Enabling Technology Cluster Flight

• Autonomous gathering and virtual docking
• Mechanical docking allowed, but no physical power
  or data connections

30
Enabling Technology Cluster Flight

• Operator definable min and max spread radius and
  cluster geometries
• Demonstrate defensive rapid cluster geometry
  change
• Autonomous collision avoidance

31
Enabling Technology Distributed Computing

• Demonstrate basic keep alive functionality of
  the system with the failure of any node.
• Demonstrate the insertion of a new mission data
  processor into the cluster for processor node
  failure, upgrade, and parallel operation.

Processor Node Parallel Operation
Processor Node Failure/Replacement
Processor Node Upgrade
32
Enabling Technology Wireless Power Transfer

• Demonstrate wireless power transfer at minimum
  within a single spacecraft node.
• Acceptable methods of wireless power transfer
  include RF, optical, inductive, and WiTricity
  techniques.

33
Enabled TechnologyThe Spacecraft Black Box

• New class of spacecraft component, enabled by
  Wireless Power Transfer and Wireless intra/inter
  spacecraft comm
• Capabilities
• Flight Data Recorder (Black Box) for failure
  diagnosis
• Back-door Spacecraft Recovery Option
• Demonstrates
• Intra and Inter module communication
• Wireless power transfer
• Characteristics
• Capable of being powered externally
• Maintain 90 minutes of spacecraft health and
  status information
• Bluetooth-like communications with intra-module
  components
• Can provide commands directly to SC components
• TBD communications with inter-module components

34
Key Go-No-Gos By Phase Phase I (PDR)

• Demonstrate the Top Level program objectives are
  met at the PDR.
• Develop a hardware in the loop (HIL) test bed
  which replicates the fractionated spacecraft
  mission in real time and fast time.
• Fully networked computers representing nodes.
• Middleware enabling distributed computing and
  network management.
• GPS emulation.
• RF path emulation of link disturbances.
• Orbital dynamics simulation.
• Identify possible launch vehicles using design
  mass and size .
• Perform conceptual design and trade space
  analysis of spacecraft power transfer options.

35
Phase I Reviews/Inchstones
Orbital Mechanics / Trajectory Design Review
System Value Modeling Methodology Design Review
Preliminary Design Review (PDR)
Performer Defined Schedule
Block III HIL Demo
Block II HIL Demo
Program Kickoff
Power Transfer Trade Space Analysis
Block I Hardware In the Loop (HIL) Test Bed Demo
System Conceptual Design Review
Plus additional, frequent, detailed program
progress reporting AKA Inchstones
36
Key Go-No-Gos By Phase Phase II (CDR)

• Demonstrate the Top Level program objectives are
  met at the CDR.
• At a minimum, add to the HIL
• Breadboard wireless data communication modules
  for node-to-node data transfer.
• Prototype mission processors.
• Prototype or flight equivalent GPS receivers.
• Ground command, control, and mission support
  suite.
• Demonstrate compatibility of spacecraft design
  and launch vehicle.
• Execute breadboard level test of selected
  wireless data communication hardware and
  software.
• Execute breadboard-level test of selected power
  transfer hardware and software.

37
Key Go-No-Gos By Phase Phase III (FRR)

• Show that FRR system elements meet all program
  objectives.
• Conduct a successful ground demonstration of
  end-to-end capability
• Network demonstration of all flight nodes.
• Wireless communication demonstration with
  simulated RFI environment.
• Power transfer subsystem demonstration in a
  relevant environment.
• Ground C2 and mission support suite
• Inclusion of fractionation-related variables,
  including data latency, link degradation, and GPS
  error.
• Completion of individual spacecraft and
  cross-network integration.
• Completion of all space and launch environmental
  testing.
• Demonstrate ability to meet all launch
  integration timelines for launch of each system
  element.
• Assembly, training, and preparation for ground
  operations center.

38
F6 Whats up with all the Fs?

• Future Possibly the architecture of the future.
• Flexible Providing the ability to modify the
  system at anytime during the lifecycle.
• Fast Smaller, leaner, production line mentality.
• Fractionated Decomposing a monolith into
  elements.
• Free-Flying Those elements are launched
  separately and then dock or virtually dock.
• Spacecraft united by Information eXchange
  Wireless data connectivity creates a virtual
  spacecraft.

39
Uncertainty Payload Delay
ConceptDevelopment
Full ScaleDevelopment
Launch
Operations
Retirement
40
Uncertainty Launch Failure
ConceptDevelopment
Full ScaleDevelopment
Rebuild
Retirement
Relaunch
41
Uncertainty On-Orbit Failure
DecreasedUtility
ConceptDevelopment
Full ScaleDevelopment
Launch
Operations
Retirement
42
Lexicon

• Flexibility ability of a system to change on
  demand
• Scalability addition of components (syn
  incremental deployment)
• Evolvability replacement of components due to
  obsolescence (synonym upgradeability)
• Maintainability replacement of components that
  have failed or are near end of life
• Adaptability reconfiguration of existing
  functionality (synonyms reconfigurability,
  versatility)
• Robustness retention of functionality in
  response to an internal or external stimulus
• Reliability ability to function under nominal
  conditions
• Survivability ability to function under
  off-nominal or unanticipated conditions
• Fault tolerance gradual loss of functionality
  due to failures (synonyms graceful degradation)
• Lifecycle cost total cost to develop, deploy,
  maintain desired service/functionality
• Lifecycle cost including development,
  procurement, launch, operations, and sustainment
  costs
• Volume effects including production learning
  and launch volume effects
• Performance ability of system to provide
  desired service or functionality to the user
• Measures of performance appropriate metrics of
  service capability ultimately, such MOPs can be
  translated into dollar value based on service
  value to customer(s)
• Availability percentage of time that the
  objective service or functionality is available
• Net value in present-day dollars, total value
  delivered by system over its lifetime, including
  value of all system attributes, minus the total
  lifecycle cost
• Net risk the standard deviation or variance of
  net value

43
Stochastic Lifecycle Cost Distributions
One way of seeing the benefits of architectural
flexibility and robustness is through total
lifecycle cost including response to uncertainty.
The fractionated architectures, while higher in
mean cost, have narrower distributions of
expected lifecycle cost.
44
Uncertainty in the Marketplace

• Options
• The right, but not obligation to conduct a future
  transaction

• Portfolio Investments
• A risk limiting strategy via investment in a
  variety of assets with minimized covariance

Insurance Transfer of risk from one party to
another in exchange for a premium