October 2012

CCSDS Working Session

Innovative Satellite Acquisition: Transition to S pace U niversal MO dular Architecture (SUMO)

Bernie Collins ODNI/AT&F

Office: 703 275-3525 Email: [email protected] 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

Spacecraft

Modular architecture with plug & play (P&P)

– 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”

Satellite Components

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

• •

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 Torque Rods Sun Sensors Star Trackers IMUs

Potential Economies of Scale

Component Reaction Wheel/CMGs Magnetometers GPS Receivers Transponders Integrated CDH Processor Boards Solar Cells Battery Cell Main Engine Maneuver Thrusters RCS Thrusters 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 Style A Style A Style A Style A Style A Style A Style A

LEO1

3 3 6 1 1 1 1 1 4 4 752 1 4 SV Class (Component Qty per SV)

LEO2 LEO3 LEO4 GEO1

3 3 6 1 1 1 1 1 5 5 2372 2 4 3 4 6 2 2 2 2 2 6 6 2959 2 4 3 4 6 2 2 2 2 2 8 8 11090 13 8 4 6 2 2 2 8 8 9274 24 1 6 12

GEO2

4 6 2 2 2 8 8 19895 28 1 6 12

130 350 Avgerage Satellite Quantity Per Year 5.5

1.2

11.4

2.3

14.8

6.8

“Universal” components present opportunities for improved economies of scale

1 Year Total 17 4 34 7 17 49 9 59 27 33 219 6 29 6 72 6 72 6 29 77 288 288 338763 606 22 20 Years Total 330 72 684 138 330 984 184 1184 544 660 4380 110 572 120 1436 110 1436 110 572 1546 5752 5752 6775264 12124 432 2592 7000

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 DoD NRO Policy

• • • •

Leading the nation in the adoption of Spacewire.

Representative to CCSDS. Several relevant projects and initiatives.

Investigating approach to engage.

• • •

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.

• •

Looking for components which could be “universalized”.

Investigating approaches to engage.

• • •

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

Workshop for:

End to End (E2E) Service Providers

Workshop for:

“Big Space” Primes & Integrators Participants: Eutelsat, Hughes, Echostar, Intelsat General,

Inmarsat Global Xpress, Inmarsat Government – US, Iridium, SES Govt Solutions, Telesat, ViaSat, Xtar

Participants:

GSI

Globecomm, DRS and Harris Caprock

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

• Establish acquisition, testing & certification approach, parts materials and processes that envelop environments.

Spiral 1b: SUMO Certified Components (SUMO-CC)

• 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 Term of Reference

8/9/12

Gather Comments

8/13/12 Industry Consensus Activities Send Concept Paper to CCSDS in Fall 2012

Concept Paper Draft Final

9/14/12

Concept Paper Review

CCSDS US SIG Members review Concept Paper

Fall ‘12

CCSDS Fall Plenary

Birds of a Feather (BOF) meeting .

Charter for CCSDS WG

Spring ‘12 Standards Production Pre-Approval US Special Interest Group Development & Integration Phase 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 S pace

AV

ionics

O

pen

I

nterface a

R

chitecture improves delivery and use of space hardware & software. Standardized as Spacecraft Onboard Interface Services (SOIS) through CCSDS.

IMA:

Commercial Avionics

’s I ntegrated

M

odular

A

vionics architecture supports modularity of components that share same computing resources.

cFE:

NASA Goddard

’s

c

ore

F

light

E

xecutive 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 building block functional elements; may be combined to form box level functionality

FDK:

DARPA

’s

F

6

D

eveloper’s

K

it, 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

Connector Cabling Shielding

Mechanical interface Power interface

Bolt patterns Vibration isolation Thermal isolation and/or thermal management Cable type Voltage Shielding

In Scope?

yes

Rationale

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.

no no no Too expensive/overengineered: benefit is outweighed by the constraints that would be imposed

Data bus

Data rate Jitter Latency Protocol

Component (type specific)

Bus interface Interface to application software

SW infrastructure/ services

OS abstraction (incl. CPU time & space partitioning) Network access layer Other services (TBD)

Intra-satellite data Applications Payloads

Command formats Telemetry formats GN&C, C&DH, EPS, etc.

General partial May specify standards for a few different voltage levels (e.g., 28V, 56V, 112V) to facilitate standardization with some differentiation to avoid excessive inefficiency no yes yes no yes varies 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 yes varies no no no partial Need to allow components to work with different operating systems 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 16

Category Interoperability Scope: Non-Functional - Physical Characteristic In Scope?

Rationale

Parts, Materials & Process reqts yes Have to standardize on space-qualified components and processes. Leads to universal component certification.

Component RMA reqts Vibration Acoustic Radiation EMI/EMC Thermal/vac no yes Need system reliability to be within spec but component reliability can vary Need universally certified components to avoid unworkably narrow selection of components for any particular system Allowable unmasked faults no Too difficult to define a priori at this time; push complexity into logical interface, as is currently done Sensor Precision and Accuracy 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 17

Category Interoperability Scope: Non-Functional – Logical/System Characteristic In Scope?

Rationale

SW & system dependability/RMA reqts Development processes & process evidence 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 Cybersecurity Component failure notification format Component failure notification content Software failure responses Format for database of permissible value ranges Worst case execution times Algorithm precision and accuracy Quality of service yes yes no no yes no partial 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 Part of electronic data sheet for sensor; allows swapping of sensors without retooling software interface Do not need to specify this for particular subsystems; can rely on static analysis of integrated system and OS guarantees on time partitioning Requirements algorithms place on component precision/accuracy need to be standardized, but precision/accuracy characterization of software outputs varies too widely to be in scope at this time.

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 • Identify a

champion demo programs

– Transition to Program of Record (2020+ ATP) – 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

Industry

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 21

Questions and Comments?

Bernie Collins

ODNI/AT&F

Office: 703 275-3525 Email: [email protected]

SUMO Support Team Karen L. Jones

Office: 703 275-2902 Email: [email protected]

Donley Silbaugh

Office: 703 275-3324 Email: [email protected]

22