Next-Generation Distributed Satellite Bus Information Systems

Transcription

1 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 The Aerospace Corporation 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 2

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! 3

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 4

5 Standard Satellite Bus Hardware/Software Architecture A side B side Flight Processor RCS EPS TT&C GN&C ACS Additional subsystems Bus controller Payload-bus interface TCS Comm interface Data bus Payload 5 Real satellites tend to be far more complex with corresponding software complexity

6 A Real Satellite 6

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 7

8 Background: Related Work DARPA F6: Fractionated spacecraft with functionality distributed across a cluster ORS (Operationally Responsive Space): Fast 1 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. 8 1 Three 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 What this talk s about Hot PEs Cold PEs GN&C TCS EPS Data store Processor Pool 9

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 10

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) 11

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 12

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 13

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 14

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 15

16 Mobile code: Example/1 Island with a video camera. 16

17 Mobile code: Example/2 How do we get a video flow from the source to the sink? 17

18 Mobile code: Example/3 The sink island dispatches mobile code to the source island 18

19 Mobile code: Example/4 Source island Video Encoder Relay Sink island Display Driver Video Decoder Relay The sink island establishes the tail of the flow and subscribes to the relay on the source island 19

20 Mobile code: Example/5 20

21 Mobile code: Example/6 21

22 Application to Spacecraft Bus Hardware Canonical spacecraft bus architecture (from slide 9) Hot PEs Cold PEs GN&C TCS EPS Data store 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 22

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 23

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