© The Aerospace Corporation 2011

Next-Generation Distributed Satellite Bus Information Systems

L. H. Miller, M. M. Gorlick, D. L. Wangerin, C. A. Landauer The Aerospace Corporation

21 October, 2011

This presentation does not contain US export controlled (ITAR) information

2

Presentation Outline

•  “Standard” satellite bus hardware/software architecture [5 mins] –  Limiting factors: Weight, power, radiation –  Key characteristics: “Inappropriate” complexity! –  Survivability –  Bus|payload firewall –  Reminder: Terrestrial state of the art –  Limitations

•  Distributed satellite bus hardware/software architecture [20+ mins] –  Research goals –  Related work –  Software –  Inter-device communications –  Software architecture –  Research approach: Distributed satellite bus architecture –  COAST—COmputAtional State Transfer –  Future work

3

Space environment: Critical characteristics/concerns

•  Key limiting factors: Weight, power, thermal, radiation, processing power, memory, repairmen

•  Critical concerns: Autonomy, security, availability, survivability •  Bus|payload firewall •  “Inappropriate” complexity!

4

“Standard” satellite bus responsibilities

•  ACS – Attitude Control Subsystem •  TCS – Thermal Control Subsystem •  TT&C – Telemetry, Tracking & Commanding •  RCS – Reaction Control Subsystem •  EPS – Electrical Power Subsystem •  GN&C – Guidance, Navigation & Control •  Comm – Communications •  FMS – Fault Management Subsystem •  Bus management & control •  Payload interfaces

And these are just the high level responsibilities

5

“Standard” Satellite Bus Hardware/Software Architecture

RCS EPS TT&C GN&C ACS Additional subsystems

Bus controller

Data bus

Payload

Comm interface

Payload-bus interface

TCS

Real satellites tend to be far more complex with corresponding software complexity

Flight Processor

A side B side

6

A Real Satellite

7

Research Goals

•  Overcome “Key Limiting Factors” described on slide 3 •  Provide a simple, systematic, understandable, and

verifiable approach to “Critical Concerns” •  Provide a unified approach to both bus and payload

processing •  Simplicity through commercially available, standard

parts

8

Background: Related Work

•  DARPA F6: “Fractionated” spacecraft with functionality distributed across a cluster

•  ORS (Operationally Responsive Space): Fast1 turnaround from concept to

launch

•  PnP (Plug and Play Satellite): Construction from standard parts –  “The era of the huge military satellite programs that cost tens of billions of dollars appears to

be over.”

1Three tiers, with Tier 1 providing capability from minutes to hours. 2 Defense Industry Daily, Jan 28, 2010.

9

Research Approach: Distributed Satellite Bus Architecture

•  Pool of processors connected through Ethernet – Every device/box/subsystem talks IP/TCP

•  Tens to 100s of processors – Powerful, cheap, commercial quality

•  Redundancy through fast reassembly •  Mobile code, zero latency, inherently survivable

Cold PEs Hot PEs

Data store

EPS TCS GN&C

Processor Pool

What this talk’s about

10

Inter-Device Communication – Distribution, Redundancy

•  Ethernet-based TCP/IP –  Endpoint interconnects between processors and the network constructed

from commercial devices •  Massive processor redundancy

–  Tens to hundreds of distributed, inexpensive, low-power, Ethernet-ready, commercial micro-controllers

–  If several processors die we simply don’t care •  Advantages of a distributed spacecraft bus include

–  Eliminating processors and buses as single points of failure –  Ample reserve processing power –  Eases recovery due to failure of spacecraft bus peripherals –  Applying computational resources to compensate for the shortcomings

or degradation of bus peripherals –  Simplifying physical devices –  Enlarging the design space for spacecraft buses

11

Further Advantages

•  Reductions in cost and schedule for spacecraft development and integration

•  Encouraging more generic, highly modular, spacecraft buses •  Reducing spacecraft weight and mechanical complexity by

eliminating custom wiring harnesses and replacing them with standard PoE (Power on Ethernet) cabling— integrating into a single cable power distribution and network communications

•  Reducing the development cost of spacecraft bus software •  Employing open source software for spacecraft for including

operating systems, cryptography, and application libraries •  Encouraging the development of standard network command and

control interfaces for common spacecraft bus devices (such as gyroscopes, reaction wheels, sun, star, and earth sensors)

12

Software Design: COAST — COmputAtional State Transfer

•  Architectural style for decentralized, flexible, secure, open and adaptive systems

•  Bilateral transfer of computation (not data) as the fundamental medium of exchange among peers

•  Reduces data exchange to a side effect of computational exchange •  All computations are named by Capability URLs (CURLs), that

provide authority-to-communicate and authority-to-execute semantics

•  All computations are mobile, reified as continuations, closures, and binding environments

•  All computations are conducted within CURL-specific execution environments that explicitly confer capability

•  The interpretation of computations is CURL-specific

13

COAST Architectural Style

•  COAST supports: – Self-healing – Capable of detecting faults and recovering

autonomously – Hot update – Changes applied without halting system execution

•  System properties supporting these include: – Rapid transfer of executing computations between processor s –  Fine-grain update of running software –  Isolation for safety and robustness –  Inexpensive, dynamic, setup and teardown of subsystem

software – Multiple, simultaneous execution of subsystems and applications

for hot failover without loss of critical state, data, or execution continuity

14

COAST Testbed

•  Computations are actors; message-passing and actor spawning are core operations •  Actors are organized into hierarchical clans

–  Each actor is a member of exactly one clan

–  Each clan is governed by a distinguished actor, the chieftain, responsible for recursively spawning new actors and clans

–  Clans occupy an island, a single address space named by a unique IP address/port pair

•  CURLs are self-certifying and signed, and may contain computations and arbitrary metadata including embedded predicates and contracts that are checked when a message directed at the CURL is processed

•  Deserialization, recompilation, and execution take place in a clan-specific sandbox and binding environment –  A sandbox regulates an actor's consumption of fungible resources (processor cycles, network bandwidth, and

memory) while a binding environment dictates the capability conveyed to an actor

•  Actors may derive new binding environments from old (environment sculpting) to apply to their own computations or the computations they receive from others

•  Computations are exchanged via peer-to-peer asynchronous messaging protocol with a simple structure and provision for arbitrary metadata

15

How It Works

•  Motile — mobile code language •  Island — peering infrastructure for computation

exchange •  Motile programs move from island to island on demand •  Powerful security and safety mechanisms built into the

language and core infrastructure – Capability-based security everywhere always –  Impossible to circumvent – Mobile computations may be restricted in time, space, function,

and authority

16

Mobile code: Example/1

Island with a video camera.

17

Mobile code: Example/2

How do we get a video flow from the source to the sink?

18

Mobile code: Example/3

The sink island dispatches mobile code to the source island

19

Mobile code: Example/4

The sink island establishes the tail of the flow and subscribes to the relay on

the source island

Source island

VideoEncoder

Relay

Sink island

VideoDecoder

RelayDisplayDriver

20

Mobile code: Example/5

21

Mobile code: Example/6

22

Application to Spacecraft Bus Hardware

•  Canonical spacecraft bus architecture (from slide 9)

Cold PEs Hot PEs

Data store

EPS TCS GN&C

Processor Pool

•  Bus processes distributed to general purpose processors •  Processors are monitored through well known heart beat or similar means •  On processor failure, processes migrate to processors from the processor pool •  State maintained in replicated data stores •  Design supports simple, safe software upload process •  Conceptually simple, elegant, fault tolerant

•  But some really tough engineering to make it all work

23

What’s Next

•  Apply COAST architectural style to a (simulated) spacecraft bus –  Focus on GN&C –  Investigate satellite control algorithms to operate both in a

distributed fashion and in the presence of unexpected network delays

–  Introduce fault scenarios

•  Apply COAST architectural style to a redesign of an existing spacecraft bus

•  Apply multi-criteria optimization work to design trade spaces, including cost, schedule, political necessity considerations

24

References

J. Erenkrantz, M. Gorlick, G. Suryanarayana, and R. Taylor. “From representations to computations: the evolution of web architectures,” in Proceedings of the ACM SIGSOFT symposium on The foundations of software engineering, pp. 255–264, Dubrovnik, 2007.