Draft Version 1.0, 7 Mar 08 DLL

AIAA S-XXX-200X

AIAA

S-XXX-200X

Draft Version 1.0, 7 Mar 08 DLL

Standard

Space Plug and Play Avionics xTEDS

Sponsored by

American Institute of Aeronautics and Astronautics

Approved

XX Month 200X

Abstract

This Standard establishes the electronic data sheet for space plug-and-play avionics.

LIBRARY OF CONGRESS CATALOGING DATA WILL BE ADDED HERE BY AIAA STAFF

Published by

American Institute of Aeronautics and Astronautics

1801 Alexander Bell Drive, Reston, VA 20191

Copyright © 200X American Institute of Aeronautics and Astronautics

All rights reserved

No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without prior written permission of the publisher.

Printed in the United States of America

Contents

Contents......

Figures......

Tables......

Foreword......

Acknowledgements

Introduction......

1Scope......

2Tailoring......

3Applicable Documents......

3.1Normative References......

3.2Informative References......

4Vocabulary......

4.1Acronyms and Abbreviated Terms......

4.2Terms and Definitions......

5SPA Architecture Overview......

6SPA XTEDS Details......

6.1XTEDS Overview......

6.2XTEDS Interface with Satellite Data Model......

6.3XML Schema Languages......

6.4SPA-U Protocols......

Annex ACommon Data Dictionary Overview (Informative)......

A.1Purpose......

A.2Organization......

A.3Format......

A.4Access......

A.4.1Subclause (level 1)......

Annex BSample......

B.1General......

B.2Clause......

A.2.1Subclause (level 1)......

Figures

Figure 1 Sample xTEDS shows the three basic parts of an xTEDS, as well as elements and attributes.

Figure 2 The allowable xTEDS structure shows the complete set of elements and nesting relations.

Tables

Table 1 The complete set of elements and attributes allowed in an xTEDS.

Foreword

The desire to quickly and reliably assemble spacecraft has been a challenge since the 1960s. In the 1990s the international computer market noted a similar need to quickly and reliably assemble computers and computer accessories. The invention of Plug and Play capabilities is now assumed for any modern computer system. Plug and Play capability is defined in various publicly available technical standards.

It is the purpose of the AIAA to capture, in this Standard, commonly understood technical approaches to constructing electronic data sheets, to be embedded with all plug-and-play components, compatible with the other standards for Space Plug-and-play Avionics.

The general outlines for each of the SPA topics are listed in the AIAA Spacecraft Plug and Play Avionics (SPA) Guidebook.

All sections in the initial versions of this AIAA Special Report are draft. Forward changes to James Lyke @ AFRL or Fred Slane @ Space Environment Technologies, LLC

Acknowledgements

This Standard was produced by the Space Plug-n-Play Avionics Committee on Standards of the American Institute of Aeronautics and Astronautics (AIAA). The development of SPA standards and the SPA Guidebook were supported by:

BYERS, Wheaton (Tony), Science Applications International Corporation,

CANNON, Scott

ENOCH, Michael

ESPER, Jaime

FORMAN, Glenn

FRONTERHOUSE, D., Scientific Simulation, Inc.

JAFFE, Paul

JORDAN, Luis

KAISER, D.

KATZMAN, Vladimir

KOHL, R.J.

LANZA, Denise, Science Applications International Corporation,

LYKE, James, Air Force Research Laboratory/Space Vehicle Directorate,

MARQUAT, Jane

MARSHALL, Joseph R,

MARZWELL, Neville

MCDERMOTT, Scott

NEWMAN, D.

SLANE, Frederick A., Space Environment Technologies, LLC, COS Chair

WELCH, Dave

HOOKE, Adrian J

TAYLOR, Frank

VANSTEENBERG, Michael

PARKER, Tony

KWAN, Peter

REYNOLDS, Dave

SIMPSON, Peter

COBERLY, Steve

BEATTY, Scott

The above consensus body approved this document in Month 200X.

The AIAA Standards Executive Council (VP-Standards Name, Chairman) accepted the document for publication in Month 200X.

The AIAA Standards Procedures dictates that all approved Standards, Recommended Practices, and Guides are advisory only. Their use by anyone engaged in industry or trade is entirely voluntary. There is no agreement to adhere to any AIAA standards publication and no commitment to conform to or be guided by standards reports. In formulating, revising, and approving standards publications, the committees on standards will not consider patents that may apply to the subject matter. Prospective users of the publications are responsible for protecting themselves against liability for infringement of patents or copyright or both.

Introduction

This standard provides the requirements for adaptation of USB 1.1 to spacecraft. This effort is a response to the need for reduced design and integration schedule and costs for small spacecraft.

Responsive space refers to the ability to rapidly achieve a specific objective through the use of space. The operative word is "rapidly." The Office of Force Transformation suggested that the goal for fielding a new payload is "weeks and months and not decades."1

Were it possible to build spacecraft without avionic systems, electronics, and software, the goal might be considerably simplified, but it is difficult to imagine what space missions could be achieved. The introduction of more than trivial amounts of electronics gives rise to misinterpretations in software and interfaces. Complexities in functional verification are associated with the aggregation of elements built in many different locations by different people. To account for the associated uncertainties, it is common practice to allocate months in a development schedule just for integration, often repeated recursively at lower levels in the decomposition of a large space platform.

In the vision of an adaptive avionics framework, a new discipline involving machine-negotiated interfaces can be used to permit the elements of a complex system to transparently contribute information that accelerates the integration process by reducing or eliminating error-prone human interpretation. Such adaptive avionic interfaces, by process of electronic self-configuration / self-organization, could allow for rapid space vehicle construction. The placement of sensors and actuators on the spacecraft would not be restricted to specific, predetermined locations. In the terrestrial electronics industry, this capability is called “Plug-and-Play (PnP).” The Space Plug-and-play Avionics (SPA) approach fully supports an à la carte method of constructing arbitrarily complex arrangements of virtually any sensor or actuator type. This behavior makes the network not only easy to expand and modify, but also makes it robust to component failure from either natural causes or from deliberate attack.

Plug-and-Play is an essential enabler for the mass production of satellite bus components. Through the production of scores or hundreds of units the economies of scale and the amortization of Non-Recurring-Engineering costs, including iterative design, testing and certification, can fundamentally alter the profitability of satellite fabrication and integration. The result will be faster turns of satellite orders at a lower delivered price at a better profit margin to the manufacturer.

The Air Force Research Laboratory, with support from the commercial space industry, NASA, academia, and other DOD organizations, has initiated the Space Plug-and-Play Avionics (SPA) Technical Committee (TC) to develop a SPA standard for space applications. The TC is a two-sided organization. One side, the working groups, will develop and test guidelines for the SPA. The other side of the TC, the Committee on Standards (COS), will work to convert the developed guidelines into an AIAA-approved standard for the U. S. space industry.

There are currently five working groups that have been defined by the TC to develop the SPA guideline. The GEN 0 Working Group is charged with developing an initial SPA USB (SPA-U) guideline based on the commercial Universal Serial Bus (USB) interface standard. The GEN 1 Working Group explores the producibility of SPA-U for the space environment and other possible standards that could be used or modified for space. The Software Working Group is developing the “play” side of SPA. An Appliqué Sensor Interface (ASI) defines a simple protocol, which is the underlying software, independent of the hardware and applied interface standard that enables the SPA interface. The Testbed Working Group must develop a SPA testbed responsive to all of the working group test needs. Finally, the GEN 2/3 Working Group will seek more advanced plug-and-play capabilities.

1Scope

This Standard establishes the electronic data sheet for space plug-and-play avionics for application in the space environment. This Standard is applicable to spacecraft with a rapid integration requirement.

2Tailoring

When viewed from the perspective of a specific program or project context, the requirements defined in this Standard may be tailored to match the actual requirements of the particular program or project. Tailoring of requirements shall be undertaken in consultation with the procuring authority where applicable.

NOTETailoring is a process by which individual requirements or specifications, standards, and related documents are evaluated and made applicable to a specific program or project by selection, and in some exceptional cases, modification and addition of requirements in the standards.

3Applicable Documents

The following documents contain provisions which, through reference in this text, constitute provisions of this standard. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative document referred to applies.

3.1Normative References

Universal Serial Bus (USB) 2.0, updated 21 Dec 2000, (Note: SPA-U only uses USB 1.1. This USB version is fully embedded in the USB 2.0 reference)

The SCPS Standards:CCSDS: ISO:

SCPS File Protocol MIL-STD-2045-47000 717.0-B 15894

SCPS Transport Protocol MIL-STD-2045-44000 714.0-B 15893

SCPS Security Protocol MIL-STD-2045-43001 713.5-B-1 15892

SCPS Network Protocol MIL-STD-2045-43000 713.0-B 15891

3.2Informative References

NASA/TM-2003-212348Toward a Dynamically Reconfigurable Computing and Communication System for Small Spacecraft

NASA/565-PG-8700.3.1Spacecraft Level Installation, Integration And Test Of Fiber Optic Related Components

JPL/NTR-NPO 20942Failure Reporting Devices Concepts for Spacecraft and Remote Vehicles

NASA/Practice-ED-1248Spacecraft Data Systems (SDS) Hardware Design Practices

NASA/TM-2002-211811Artificial Neural Networks Applications: From Aircraft Design Optimization to Orbiting Spacecraft On-board Environment Monitoring

NASA/TM-2004-212534A Reconfigurable System for Small Spacecraft

ECSS-Q-40-04Parts 1A/2ASneak Analysis

AIAA G-072-1995Guide for Utility Connector Interfaces for Serviceable Spacecraft

4Vocabulary

4.1Acronyms and Abbreviated Terms

AIAA / American Institute of Aeronautics and Astronautics
AFRL / Air Force Research Laboratory
CM / Configuration Management
COS / Committee on Standards
DOD / Department of Defense
FAA / Federal Aviation Administration
GEN / Generation
IP / Intellectual Property
NASA / National Aeronautics and Space Administration
OS / Operating System
PnP / Plug and Play
R&D / Research & Development
SDO / Standards Development Organization
SDM / Satellite Data Model
SOIS / Spacecraft Onboard Interface Services
SPA / Space Plug and Play Avionics
TBSL / To Be Supplied Later, in a future revision
TC / Technical Committee
USB / Universal Serial Bus

4.2Terms and Definitions

For the purposes of this document, the following terms and definitions apply.

ASI (Appliqué Sensor Interface)

The device and host software model, independent of the physical layer, which enables plug-and-play capability in space avionics. ASI is modeled after the highly successful USB standard, but adds other features (e.g. xTEDS, robust hubs) to enhance fault tolerance and utility to real-time embedded systems.

PnP (Plug and Play)

A protocol for electronics systems in which components are automatically recognized and integrated upon assembly.

SPA (Space Plug-and-play Avionics)

Supports an à la carte method of constructing arbitrarily complex arrangements of virtually any sensor, processor, or actuator types, suitable for application in the space environment.

SPA TC (Technical Committee)

Multi-organizational group formed as a committee, following the AIAA definitions and procedures for a committee on standards (COS), to develop a widely-accepted plug-and-play standard for space.

SPA-S (SpaceWire-based SPA)

A SPA interface, based on the SpaceWire standard, that provides a higher-speed protocol for data transport.

SPA-U (USB-based SPA)

USB-based portion of a plug-and-play system for space avionics. Intended to accommodate control and data signaling transport for devices up to 10Mb/sec performance. Higher speed devices may use SPA-U for control, but another, higher-speed protocol for data transport.

SpaceWire

A standard for high-speed links and networks for use onboard spacecraft, easing the interconnection of: sensors; mass-memories; processing units, and; downlink telemetry sub-systems.SpaceWire is defined in the European Cooperation for Space Standardization standard ECSS-E50-12A.

TEDS (Transducer Electronic Data Sheet)

An electronically embedded description, contained within an ASN node, containing both generic information about the type of component and the services it provides, but also can include calibration, maintenance history, technical orders, and other useful information.

XTEDS (XML-based Transducer Electronic Data Sheet)

A machine-readable representation of data for a specific component within a plug-and-play network.

USB (Universal Serial Bus)

The familiar serial bus used by personal computers, which supports automated enumeration and plug-and-play. (See

USB Full-Speed Data Rate

The USB full-speed signaling bit rate is 12 Mb/s.

USB Low-Speed Data Rate

A limited capability low-speed signaling mode is also defined at 1.5 Mb/s.

5SPA Architecture Overview

SPA is defined as an interface-driven set of standards, encompassing hardware, software, and protocols, intended to promote the rapid development and integration of spacecraft (busses and payloads). The SPA standard comprises an open systems framework, which combines core commercial data-transport standards (such as USB and Ethernet) with carefully chosen hardware and software extensions necessary for the real-time embedded systems onboard a satellite. Each specific SPA transport standardderives its name from the adapted core interface standard, such as SPA-U (using USB) and SPA-S (using SpaceWire).

In SPA, spacecraft connections are free-form in nature with the goal being that components are simply “plugged in” to the network. While the paradigm sought for SPA is similar to the ease-of-use model promoted by "plug-and-play" (PnP) in the PC industry (e.g., USB-based "thumb drives"), SPA is not simply the transplant/grafting of consumer PnP onto aerospace electrical components. Instead, while exploiting existing standards for physical and transport layers (such as supplied by USB, SpaceWire, and Ethernet), SPA accommodates special space-system constraints not typically faced by high-volume commodity PnP products:

• Environment (e.g. radiation, temperature, stress)
• Synchronization demands
• Fault tolerance
• Weight limitations (the need for simple, compact implementations of interface)
• Genericity/Extensibility (the ability to handle broad diversity of component types)
• Scalability (the ability to handle large networks)
• Higher power delivery
• Driverless functioning (ability to work across many operating systems, even unknown ones)

In SPA, every device is considered an endpoint on the network. A SPA device by this definition is a very broad concept. It includes both traditional bus components, such as reaction wheels or torque rods, and payload components, such as imaging devices. Processors are also endpoints on the network. The SPA network is created dynamically as devices are introduced to it. Any SPA device can become an endpoint on the network in any available location. In some styles of interface, it is necessary to include devices that facilitate network scaling. Examples include routers (SPA-S), hubs (SPA-U), and bridges (which negotiate between two different SPA subnetworks). Often these devices include their own captive endpoints, or they may be integrated into endpoints (e.g., a SPA-U receiver might contain its own hub).

SPA represents a service-oriented architecture; each SPA device supports commands and may publish data. A command is defined as any request for an action by the component; a service is further defined as a command linked to a specific data reply message. The SPA Electronic Data Sheet standard defines a minimum set of commands that every component in a SPA network is expected to support. An example of a common command is "reset." SPA also defines component-specific commands. This command might be a request for specific data published by the component. The component is expected to respond with one or more data messages containing the specific data products requested to complete the service.

Consistent names for device-specific commands, services, or data are essential to the successful implementation of SPA. Device-specific names and their meanings are regularly published in the publicly available Common Data Dictionary (an annex to thisSPA Electronic Data Sheet Standard). This is a living document that will evolve as SPA gains wider use.

Since components in the SPA concept provide actions or services, then the system must have mechanisms for recognizing these actions and services and the components that provide them. In a SPA device, an electronic data sheet, called the “extended Transducer Electronic Data Sheet” (xTEDS),is stored with the device. The xTEDS contains descriptions of all device-specific commands accepted, variables produced, and data messages that can be delivered by the device. It fully describes the services or data provided by the device and represents the complete protocol for accessing these services or data.

SPA interfaces are defined by components in their resident xTEDS and provide the information needed to piece together a network. Instead of requiring custom electronics or software to interface one modular block with another, each block contains everything it needs to maintain compatibility with the other blocks in the system. Above the xTEDS level, a standard messaging protocol and a common set of software are needed to enable networking. These are collectively referred to asthe Satellite Data Model (SDM), which iscovered in a separate SPA standard.

In practice, a framework has to exist to which the appropriate hardware and software can be rapidly added. A standardized structural panel is envisioned for the spacecraft bus with the built-in ability to support plug-and-play components, such as sensors and actuators. The structural panel could contain a networking device, such as a router or a hub, and harnessing to pre-positioned ports that together allow the panel to be a node with multiple endpoints on the spacecraft network. One could take a number of the panels just described and connect them in a box or whatever shape is physically possible to form a spacecraft bus.