October 2012
CCSDS Working Session
Innovative Satellite Acquisition:
Transition to Space Universal
MOdular Architecture (SUMO)
Bernie Collins
ODNI/AT&F
Office: 703 275-3525
Email: bernie.f.collins@dni.gov
1
Agenda
Introduction
Outreach and Support
Transition Plan
Scoping the Approach
Conclusion
2
Global Market Trends
Future orders are not
fully accounted for –
beyond 2016.
Limited volume constrains the business case
Expanding international market drives the benefit to follow global standards
3
Space Universal MOdular Architecture (SUMO)
• Universal components created through “bounding” design
characteristics/features, test environments, and specifications
–
–
–
Standard electrical interfaces
Standard testing that can apply from LEO to GEO and Minotaur to
Atlas
Benefits: cost savings, innovation & improvement, mission assurance
and assembly time
• Modular architecture with plug & play (P&P)
–
Satellite
Components
Spacecraft
High speed data bus; pin out and data definitions
• Leverage existing initiatives and standard development
–
–
Space Modular and P&P standards are being developed by AFRL,
ESA, NASA and industry
Consultative Committee for Space Data Systems (CCSDS) standards
body
• Focus on satellite bus interface with sub-systems & components
–
–
–
–
Data & electrical interoperability; avoid defining mechanical interfaces
Emphasize capabilities over requirements
Potential benefits for payload interoperability
Retain intellectual property and unique designs “inside the box”
Focus on interoperability of interfaces.
4
Goals
• Innovative Satellite Acquisition Objective
– Reduce the overall cost of space assets to government clients
– Enhance the global responsiveness of the space industrial base
• Conditions for Success
– Approach must be compelling to both industry and government
– Collaboration between government and industry is necessary
5
Introduction
Outreach and Support
Transition Plan
Scoping the Approach
Conclusion
6
Market Analysis
•
•
•
Aerospace recently modeled the US satellite market to quantify the savings which may
be achieved from “universal” components and from applying SpaceWire and SUMO.
Variables include: capture rate, integration complexity, design compression,
organizational complexity, rate of obsolescence and frequency of technology insertion,
planned build quantity, and program length.
Results indicate that billions of dollars can be saved.
Design >
Cost >
Technology >
Market >
ROI
7
Potential Economies of Scale
Component
Table gives an
indication where
universal
components are
possible/likely
across SV classes
There may be
more than one
manufacturer for
each style of
component
6
2
2
2
2
2
2
2
1
1
2
2
2
2
2
2
4
5
6
8
8
8
288
5752
4
752
1
5
2372
2
6
2959
2
8
11090
13
8
9274
24
1
8
19895
28
1
288
338763
606
22
5752
6775264
12124
432
4
4
4
8
6
12
6
12
130
350
2592
7000
5.5
1.2
11.4
2.3
14.8
6.8
GPS Receivers
Transponders
Integrated CDH
Processor Boards
Solar Cells
Battery Cell
Main Engine
Maneuver
Thrusters
RCS Thrusters
Reaction
Wheel/CMGs
Sun Sensors
Magnetometers
•
6
LEO1
3
Torque Rods
•
1 Year
Total
17
4
34
7
17
49
9
59
27
33
219
6
29
6
72
6
72
6
29
77
Style
Style A
Style B
Style C
Style D
Style A
Style B
Style C
Style D
Style E
Style A
Style B
Style A
Style B
Style A
Style B
Style A
Style B
Style A
Style B
Style A
Star Trackers
IMUs
Avgerage Satellite
Quantity Per Year
SV Class (Component Qty per SV)
LEO2
LEO3
LEO4
GEO1
3
3
3
3
3
4
4
4
4
6
6
6
6
1
2
2
1
2
1
1
Style A
Style A
Style A
Style A
Style A
Style A
Style A
GEO2
1
1
1
1
20 Years
Total
330
72
684
138
330
984
184
1184
544
660
4380
110
572
120
1436
110
1436
110
572
1546
“Universal” components present opportunities for improved economies of scale
8
Government Reach Out Campaign
Goal: understand policy & budget drivers, and industrial base policy issues.
Government Buyers & Stakeholders: Focus on affordability, responsiveness and
ability to maintain programs of record during budget driven era.
NASA
•
•
•
•
Leading the nation in the adoption of Spacewire.
Representative to CCSDS.
Several relevant projects and initiatives.
Investigating approach to engage.
DoD
• AT&L is very supportive.
• SMC is: developing a transition plan; looking for comments to
“universalize”; and selecting a target system.
• AFRL developed SPA and now MONARCH.
NRO
• Looking for components which could be “universalized”.
• Investigating approaches to engage.
Policy
• OSTP requested further details, considering further action.
• NSC and OMB are very supportive.
• DoC (including ITA and NIST) are engaged.
Strong support throughout US government.
9
Industry Reach Out Campaign
Feedback and interaction through Request for Information on FedBizOps and
four SIA & AIA sponsored workshops.
Focus: Core Competencies; Business Goals (profitability, risk, target markets); Business
Challenges; USG Buyer Perceptions; Improved Acquisition Approaches
Findings: Industry supports standardized mission assurance and interface requirements,
requirements stability, government/industry consortium, P&P capabilities, export reform, hosted
payloads, and stable government planning cycles.
(1)
(2)
Received feedback through individual meetings, teleconferences – including companies not listed below.
Primes and component manufacturers list below reflect workshop attendance although these companies may be BOTH primes & component manufacturers.
Workshop for:
Satellite Operators
Participants: Eutelsat, Hughes, Echostar, Intelsat General,
Inmarsat Global Xpress, Inmarsat Government – US,
Iridium, SES Govt Solutions, Telesat, ViaSat, Xtar
Workshop for: End to End
(E2E) Service Providers
Participants: GSI Globecomm, DRS and Harris Caprock
Workshop for: “Big Space”
Primes & Integrators
Participants: Boeing, Lockheed Martin, Northrop Grumman,
Orbital, The SI Organization, Space Systems/Loral
Workshop for: Subsystem,
Payload & Component
Manufacturers
Participants: Aerojet, ATK, BAE, Ball Aerospace, Cisco,
Cobham, Comtech AA, Harris, ITT Exelis, Goodrich, PnP
Innovations, Raytheon, SEAKR, Sierra Nevada, and SpaceX
Industry invested $100M+ in IR&D
10
Introduction
Outreach and Support
Transition Plan
Scoping the Approach
Conclusion
11
Space Universal MOdular Architecture (SUMO)
Spiral 1a: Universal
Components
Spiral 1b: SUMO Certified
Components (SUMO-CC)
• Establish acquisition, testing &
certification approach, parts
materials and processes that
envelop environments.
• Universal Components to
modular configuration.
• Evolve into Plug & Play.
Spiral 2: Plug Side of SUMO
•
•
Incorporate a standardized electrical & data interface into
Universal Certified Components.
Create an adaptor device to convert between the
standardized component output interface and the
application-specific interface of a given bus manufacturer.
Spiral 3: Play Side of SUMO
•
Eliminate the adaptor device. The bus interface must be
standardized to accept the components.
Foundation: Proactive Industry Consensus Standards Development
• Via CCSDS – launch a “Space Universal MOdular architecture” or SUMO
• Consider SPA, SAVOIR, IMA and other US, European and global standards
• Longer term progress from modular to Plug & Play – if supported by industry
12
Foundation: Standards Process
Form a CCSDS Working Group to Realize Voluntary Consensus &
Broad Industry Participation
Send Concept Paper to
CCSDS in Fall 2012
Term of Reference
Gather
Comments
Concept Paper
Draft
8/9/12
8/13/12
Final
9/14/12
Concept
Paper Review
CCSDS US
SIG Members
review Concept
Paper
CCSDS Fall Plenary
Birds of a Feather
(BOF) meeting .
Charter
for
CCSDS
WG
Spring ‘12
Fall ‘12
Industry Consensus Activities
Standards
Production
Development & Integration Phase
US Special Interest
Group
Pre-Approval
Birds of
a Feather (BoF)
Working
Group
13
Coalesce Around Open Modular Architecture & Standards
SPA: AFRL’s Space PnP Architecture – focused on reducing satellite development to months
instead of years. Draft standards created through AIAA. Evolved to MONArch.
SAVOIR: ESA’s Space AVionics Open Interface aRchitecture improves delivery and use of
space hardware & software. Standardized as Spacecraft Onboard Interface Services (SOIS)
through CCSDS.
IMA: Commercial Avionics’s Integrated Modular Avionics architecture supports modularity of
components that share same computing resources.
cFE: NASA Goddard’s core Flight Executive software framework enables basic sw functions
to be reused across programs, while allowing for tailoring of mission-specific sw application
functionality.
Common Avionics Architecture (SpaceAGE Bus): NASA Goddard combines cFE/CFS
with modular hardware (intra-box electrical & mechanical) definition for board level buildingblock functional elements; may be combined to form box level functionality
FDK: DARPA’s F6 Developer’s Kit, which is a set of open source interface standards,
protocols, behaviors, and reference implementations thereof, necessary to develop a new
module that can fully participate in a fractionated cluster.
Joint Architecture Standard (JAS): DOE Sandia National Labs – satellite PL processing &
data com architecture, focuses on increasing mission flexibility, accommodating enhanced
sensor performance, optimizing payload size, weight & power (SWaP) consumption.
Leverage and consider existing architectures and standards to the extent practical
14
Introduction
Outreach and Support
Transition Plan
Scoping the Approach
Conclusion
15
Interoperability Scope: Functional – Physical and Logical
Category
Data bus
Characteristic
In Scope?
Connector
Cabling
yes
Shielding
Physical
Bolt patterns
Mechanical
Vibration isolation
Thermal isolation and/or
interface
thermal management
Cable type
Power interface Voltage
Shielding
no
no
no
partial
no
Jitter
yes
Latency
yes
Protocol
no
Bus interface
yes
Data bus
Logical/system
Functional
Data rate
Component (typeInterface to application
specific)
software
OS abstraction (incl. CPU
time & space partitioning)
SW
infrastructure/ Network access layer
services
Intra-satellite
data
Applications
Payloads
varies
A commonized physical output will allow bus manufacturers to choose a component based on
price, performance, and availability rather than because of the cost of the NRE to incorporate
the component into the bus's data network. Weight of potential middleware needed for
adaptation is low.
Too expensive/overengineered: benefit is outweighed by the constraints that would be
imposed
May specify standards for a few different voltage levels (e.g., 28V, 56V, 112V) to facilitate
standardization with some differentiation to avoid excessive inefficiency
Requirement is that data bus can support rate needed by system. MIL-STD-1553B provides an
implicit minimum data rate. Data rates may increase as new technologies become available;
need to leave flexibility to take advantage of advances.
May have different allowable categories but algorithms & message partitioning activity need to
know tolerances
May have different allowable categories but algorithms & message partitioning activity need to
know tolerances
Need to capture reqts underlying protocol -- jitter, latency, others that we need domain experts
to help define; otherwise specifics of protocol can be internal to data bus system, if the
appropriate abstraction is included in the data bus interface
Need components to be able to plug into whatever bus protocol is chosen
Team will need to define what components may change, which drives which interfaces need to
be standardized
yes
Need to allow components to work with different operating systems
yes
Need to allow components to work with different operating systems
SOIS contains some candidates; these are points of coupling of the applications and are needed
if sets of subsystems are to be reused/changed/rapidly assembled
Needed, but can be separated from the current effort
Needed, but can be separated from the current effort
Would result in overspecification
Payloads will conform to specification of a general component within the vehicle
Other services (TBD)
varies
Command formats
Telemetry formats
GN&C, C&DH, EPS, etc.
no
no
no
partial
General
Rationale
16
Interoperability Scope: Non-Functional - Physical
Category
Characteristic
In
Scope?
Rationale
General
Univ. Env. Test reqts
Physical
Fault
Interface
Nonfunctional
Performance
Parts, Materials
& Process reqts
yes
Have to standardize on space-qualified components and processes. Leads
to universal component certification.
Component RMA
reqts
no
Need system reliability to be within spec but component reliability can vary
yes
Need universally certified components to avoid unworkably narrow
selection of components for any particular system
no
Too difficult to define a priori at this time; push complexity into logical
interface, as is currently done
yes
Specific precision/accuracy will not be defined beforehand, but
characterization of precision/accuracy will be required such that algorithms
can statically determine whether a given component in a class is within
tolerance
Vibration
Acoustic
Radiation
EMI/EMC
Thermal/vac
Allowable
unmasked faults
Sensor Precision
and Accuracy
17
Interoperability Scope: Non-Functional – Logical/System
Category
Characteristic
General
SW & system dependability/RMA
reqts
Development processes & process
evidence
Cybersecurity
Fault interface
Logical/system
Nonfunctional
Component failure notification
format
Component failure notification
content
In Scope?
Rationale
one or Need a way to determine whether a piece of software has been
the other developed and tested to the appropriate level of assurance
yes
yes
no
Vulnerabilities may exist, and may be public, in common
elements; could preclude adoption of standard if not addressed
Need to standardize so that component + data bus + service
interfaces are defined
Push the complexity into software to allow for flexibility in
implementation
Push the complexity into software to allow for flexibility in
implementation
Performance
Software failure responses
no
Format for database of permissible
value ranges
yes
Part of electronic data sheet for sensor; allows swapping of
sensors without retooling software interface
no
Do not need to specify this for particular subsystems; can rely
on static analysis of integrated system and OS guarantees on
time partitioning
Worst case execution times
Algorithm precision and accuracy
Quality of service
Requirements algorithms place on component
precision/accuracy need to be standardized, but
partial
precision/accuracy characterization of software outputs varies
too widely to be in scope at this time.
no
Not typically applicable to domain
18
Agenda
Introduction
Transition Plan
Why We Have Confidence
Scoping the Approach
Conclusion
19
Transition Plan and Standards Process
• Launch standards consensus process; August 2012
– Terms of Reference (August 9, 2012)
– Concept Paper (Early Fall 2012)
– CCSDS Working Group (Fall 2012 and beyond)
• Refine transition plan with industry involvement; October 2012
– Include process for gravitating towards “universal” components
– Include process for developing a national (and eventually global)
standard for SUMO
– Include process for gradually integrating SUMO standard acceptance
with industry (R&D, Title III funding, etc…. to support industry efforts).
• Process letter of intent signed by IC, NASA and DoD; Fall 2012
• Identify NRO, NASA and SMC demo programs
– Transition to Program of Record (2020+ ATP)
• Identify a champion
– Possible Space Industrial Base Council sponsorship
20
Conclusion
Reduce the cost of satellites and help the industry compete
in a growing international space market
ODNI
NRO
AFRL
SMC
NASA
Collaboration
Standards
Process
Transition
Plan
SUMO Certified
Components
Space Universal
MOdular architecture
SUMO
Plug & Play
•
•
•
•
Space Industrial Base
More Competitive Internationally
Larger Addressable Market
Less Time to Market/Orbit
Increased Innovation
Government Buyer
• Reduced Acquisition Costs
• Enhanced Capabilities
Industry
21
Questions and Comments?
Bernie Collins
ODNI/AT&F
Office: 703 275-3525
Email: bernie.f.collins@dni.gov
SUMO Support Team
Karen L. Jones
Office: 703 275-2902
Email: karen.l.jones@aero.org
Donley Silbaugh
Office: 703 275-3324
Email: SilbaughD@saic.com
22