AIAA S-XXX-200X
AIAA
S-XXX-200X
Draft Version 1.0, 7 Mar 08 DLL
Standard
Space Plug and Play Avionics xTEDS
Warning
This document is not an approved AIAA Standard. It is distributed for review and comment.
It is subject to change without notice.
Recipients of this draft are invited to submit, wit their comments, notification of any relevant
patent rights of which they are aware and to provide supporting documentation.
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.
1
AIAA S-XXX-200X
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
AIAA S-XXX-200X
Contents
Contents .......................................................................................................................................... 3
Figures............................................................................................................................................. 3
Tables .............................................................................................................................................. 3
Foreword ......................................................................................................................................... 4
Acknowledgements ......................................................................................................................... 5
Introduction ..................................................................................................................................... 7
1
Scope ....................................................................................................................................... 8
2
Tailoring.................................................................................................................................. 8
3
Applicable Documents ............................................................................................................ 8
3.1
Normative References ......................................................................................................... 8
3.2
Informative References ....................................................................................................... 8
4
Vocabulary .............................................................................................................................. 9
4.1
Acronyms and Abbreviated Terms ..................................................................................... 9
4.2
Terms and Definitions......................................................................................................... 9
5
SPA Architecture Overview ................................................................................................. 10
6
SPA XTEDS Details ............................................................................................................. 12
6.1
XTEDS Overview ............................................................................................................. 12
6.2
XTEDS Interface with Satellite Data Model .................................................................... 13
6.3
XML Schema Languages .................................................................................................. 13
6.4
SPA-U Protocols ................................................................Error! Bookmark not defined.
Annex A Common Data Dictionary Overview (Informative) .................................................. 19
A.1
Purpose................................................................................................................................ 1
A.2
Organization ........................................................................................................................ 1
A.3
Format ................................................................................................................................. 1
A.4
Access ................................................................................................................................. 1
A.4.1
Subclause (level 1) .........................................................Error! Bookmark not defined.
Annex B Sample......................................................................................................................... 1
B.1
General ................................................................................................................................ 1
B.2
Clause.................................................................................Error! Bookmark not defined.
A.2.1
Subclause (level 1) .........................................................Error! Bookmark not defined.
Figures
Figure 1 Sample xTEDS shows the three basic parts of an xTEDS, as well as elements and attributes. ................... 14
Figure 2 The allowable xTEDS structure shows the complete set of elements and nesting relations. ........................ 15
Tables
Table 1 The complete set of elements and attributes allowed in an xTEDS. .............................................................. 16
3
AIAA S-XXX-200X
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
AIAA S-XXX-200X
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, wheaton.b.byers.jr@saic.com
CANNON, Scott scott.cannon@usu.edu
ENOCH, Michael michael.enoch@lmco.com
ESPER, Jaime Jaime.Esper@nasa.gov
FORMAN, Glenn formanga@crd.ge.com
FRONTERHOUSE, D., Scientific Simulation, Inc. don@ssi-sw.com
JAFFE, Paul paul.jaffe@nrl.navy.mi
JORDAN, Luis luis.jordan@aeroastro.com
KAISER, D. don.kaiser@kirtland.af.mil
KATZMAN, Vladimir traffic405@cox.net
KOHL, R.J. rjkohl@prodigy.net
LANZA, Denise, Science Applications International Corporation, denise.lanza@kirtland.af.mil
LYKE, James, Air Force Research Laboratory/Space Vehicle Directorate, james.lyke@kirtland.af.mil
MARQUAT, Jane Jane.K.Marquart@nasa.gov
MARSHALL, Joseph R, joe.marshall@baesystems.com
MARZWELL, Neville marzwell@mail.jpl.nasa.gov
MCDERMOTT, Scott scott@aeroastro.com
NEWMAN, D. dnewman@microsatsystems.com
SLANE, Frederick A., Space Environment Technologies, LLC, freds@spacestandards.com COS Chair
WELCH, Dave welch@lasp.colorado.edu
HOOKE, Adrian J adrian.j.hooke@jpl.nasa.gov
TAYLOR, Frank Frank.Taylor@SpaceDev.com
VANSTEENBERG, Michael Michael.E.VanSteenberg@nasa.gov
PARKER, Tony
KWAN, Peter
REYNOLDS, Dave david.r.reynolds@lmco.com
SIMPSON, Peter
COBERLY, Steve
5
AIAA S-XXX-200X
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.
AIAA S-XXX-200X
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-RecurringEngineering 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.
7
AIAA S-XXX-200X
Scope
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.
Tailoring
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.
NOTE Tailoring 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.
Applicable 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.
Normative References
Universal Serial Bus (USB) 2.0, updated 21 Dec 2000, http://www.usb.org (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
Informative References
NASA/TM-2003-212348 Toward a Dynamically Reconfigurable Computing and Communication System
for Small Spacecraft
NASA/565-PG-8700.3.1 Spacecraft Level Installation, Integration And Test Of Fiber Optic Related
Components
JPL/NTR-NPO 20942
Failure Reporting Devices Concepts for Spacecraft and Remote Vehicles
NASA/Practice-ED-1248
Spacecraft Data Systems (SDS) Hardware Design Practices
NASA/TM-2002-211811 Artificial Neural Networks Applications: From Aircraft Design Optimization to
Orbiting Spacecraft On-board Environment Monitoring
NASA/TM-2004-212534 A Reconfigurable System for Small Spacecraft
ECSS-Q-40-04 Parts 1A/2A
Sneak Analysis
AIAA S-XXX-200X
AIAA G-072-1995
Guide for Utility Connector Interfaces for Serviceable Spacecraft
Vocabulary
Acronyms 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
Terms 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)
9
AIAA S-XXX-200X
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 plugand-play. (See http://www.usb.org).
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.
SPA 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 standard
derives 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
AIAA S-XXX-200X
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 this SPA 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 as the Satellite Data Model (SDM), which
is covered 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
11
AIAA S-XXX-200X
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.
An endpoint device (e.g., a sensor or an actuator) could be connected to any compatible port on any SPA
network. For example, a spacecraft structure might have a number of pre-integrated SPA ports in various
locations. It should be possible to plug a SPA device in any location on the network and, if needs dictate,
to relocate the same device to another port without altering any software or hardware in the overall
spacecraft. This positional independence within a SPA network suggests a property called “topologyagnostic,” simply meaning that a SPA network is capable of transparently managing arbitrary
arrangements of devices.
The Appliqué Sensor Interface Module (ASIM), with a SPA connector, provides the encapsulated wiring
and software translations needed to interface the sensor or actuator to the port. The ASIM bridges the
specifics of the component behavior model to the interfaces described in the SPA standard. The
component xTEDS, based upon entries in the Common Data Dictionary, would be stored in the ASIM.
The specific design of the ASIM is left to the device manufacturer or vendor, who may choose to embed
an ASIM in the device or use a fully external ASIM. Full form, fit and function compliance with the SPA
standard by device manufacturers will eliminate the need for an internal or external ASIM.
The remainder of this document is concerned with the details of the SPA xTEDS and understanding and
using the SPA Common Data Dictionary.
SPA xTEDS Details
xTEDS Concept
The idea for an embedded data sheet in a SPA device was inspired by the IEEE 1451 Transducer
Electronic Data Sheet (TEDS) Standard series. However, early examination of the TEDS structure
suggested a rigorous form with a relatively fixed memory map that would not accommodate the desired
flexibility of SPA. (As the IEEE 1451 standard evolves, system developers may wish to revisit the TEDS
as an option for SPA.) Therefore, the developers of the SPA electronic data sheet turned to the
eXensible Markup Language (XML) to provide a schema-controlled language for the data sheet that
would allow users to define their own elements. XML is a freely-available open standard recommended
by the World Wide Web Consortium for the exchange of structured data across differing information
systems, particularly via the Internet. In deference to both standards, the resulting SPA electronic data
sheet was named the XML Transducer Electronic Data Sheet (xTEDS).
The SPA xTEDS differs from the IEEE 1451 TEDS in two important ways: 1) xTEDS are interface
descriptions as opposed to data repositories (xTEDS descriptions may point to data but do not contain
the data themselves) and 2) xTEDS are extensible descriptions (not limited to fixed memory space and
mappings). But the SPA xTEDS closely resembles the IEEE 1451 TEDS in that every device (including
sensors, actuators, processors, hubs, and routers) and every software application must have an xTEDS
to function on the SPA network.
The xTEDS provides the system level information on data produced, commands accepted, interfaces
supported, and services provided along with information on the physical “care and feeding” of a SPA
endpoint device. Care and feeding information may include device power requirements, device safety
limits, and device safety controls.
This 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." Annex A provides the SPA common
commands.
SPA also defines component-specific commands. This type of command might be a request for specific
data published by the component (hardware or software). The component is expected to respond with
AIAA S-XXX-200X
one or more data messages containing the specific data products requested to complete the service.
Thus, a command is defined as any request for an action by the component; a service request is further
defined as a command linked to a specific data reply message. The component may also provide data
without first receiving a service request. This type of unsolicited data message is called a notification and
may include periodic sensor reports, safety warnings, and event detections.
Consistent names for component-specific commands, service requests, or notifications are essential to
the successful implementation of SPA. Component-specific names and their meanings are regularly
published in the Common Data Dictionary, which is maintained on-line and described in Annex B. This is
a living document that will evolve as SPA gains wider use.
xTEDS Interface with Satellite Data Model
In the SPA network, the xTEDS are actually used and routed by the Satellite Data Model (SDM). The
SDM is the messaging protocol and set of primary managers (software) that enable the SPA network to
function and which are detailed in the SPA Satellite Data Model Standard. The xTEDS define the
communications interface for each sensor, actuator, processor, hub, router, software application and
even each SDM primary manager within the SPA network. Every component of the SPA network that
receives or produces data must define how it communicates, using the xTEDS. This document explains
how to prepare an xTEDS. For an explanation of how SPA uses the xTEDS to communicate, refer to the
SPA Satellite Data Model Standard.
xTEDS and the XML Schema Language
The XML standard requires a set of rules to which an XML document must conform in order to be
considered valid. This set of rules is called a “schema language.” XML schema languages express
shared vocabularies and provide a means for defining the structure, content and semantics of XML
documents. Of the multiple widely-available XML languages (i.e. Document Type Definition (DTD),
RELAX NG, and W3C XML Schema), SPA has chosen to use the World-Wide Web Consortiumrecommended XML Schema, abbreviated as W3C XML Schema, version 1.0, published in May 2001.
SPA uses a particular XML Schema instance, called an XML Schema Definition (XSD), to fully describe
an xTEDS. An XSD defines a type of XML document in terms of what elements and attributes may
appear, their relationship to each other, what types of data may be in them, and other qualifying and
constraining information. All xTEDS prepared for SPA implementations must conform to the SPA xTEDS
Schema and the XML Schema. Conformance with the SPA xTEDS Schema and the XML Schema must
be validated using a “validating XML parser.”
Detailed information on accessing the current version of the SPA xTEDS Schema and a suitable
validating XML parser is contained in Annex C. The following section provides a general description of a
valid SPA xTEDS.
XTEDS Format
The xTEDS is written to define communication interfaces between a software application or a hardware
device and the rest of the satellite network. All xTEDS have three basic parts:
1)
The header, that names the xTEDS and the schema with which it conforms,
2)
The component declaration, that provides information on the supported application or device, and
3)
All the communication interfaces that the device or application supports.
This information must be presented in the XML format, which says that every piece of information in the
xTEDS is either an element or an attribute. An attribute is a single piece of data while an element has
one or more attributes or elements under it. Elements can be nested under elements. Using the XML
syntax, the code looks like:
13
AIAA S-XXX-200X
-<Element1 attribute11=”data11” attribute12=”data12”/>
<Element2 attribute21=”data21” attribute22=”data22” attribute23=”data23”/>
<Element3 attribute31=”data31” attribute32=”data32”/>
</Element1>
The hyphen indicates the beginning of a nested element, while the slash before the element name shows
the end of the nested element. Multiple layers of nesting can be used. All possible xTEDS elements and
attributes must be defined in the xTEDS Schema.
All three parts of the xTEDS, listed above, must conform to the XML syntax. Figure 1 provides a sample
xTEDS. Note that the top line, part of the header, has a slightly different format to define the XML version
and the encoding information.
Header
Component
Declaration
(static properties
of a device or
application)
Communication
Interface
<?xml version="1.0" encoding="UTF-8" ?>
- <xTEDS version="1.1" name="Thermometer_Demo" description="Text"
xmlns="http://www.interfacecontrol.com/SPA/xTEDS">
<Device modelId="1000" name="Demo_Thermometer" kind="Demo" id="123" />
- <Interface name="ThermometerInterface" id="1">
<Variable units="s" name="Time" kind="time" format="UINT32" />
<Variable units="counts" scaleUnits="seconds" scaleFactor="0.0001" name="SubS"
kind="subSeconds" format="UINT32" />
<Variable name="Temperature" kind="temperature" id="1" format="INT16" />
<Variable name="LED" kind="status" format="UINT08" />
- <Notification>
- <DataMsg msgRate="1" msgArrival="PERIODIC" name="Temperature_Reading" id="1">
<VariableRef name="SubS" />
<VariableRef name="Time" />
<VariableRef name="Temperature" />
</DataMsg>
</Notification>
- <Command>
- <CommandMsg name="SetLEDs" id="10" description="Set LED's To Bits 0, 1, 2">
<VariableRef name="LED" />
</CommandMsg>
</Command>
Attributes
Elements
</Interface>
</xTEDS>
Figure 1 Sample xTEDS shows the three basic parts of an xTEDS, as well as elements and attributes. (I need to find
a better sample. This one has problems.)
Several naming conventions must be followed in building an xTEDS:
1)
Self-describing names are preferred over short, bandwidth-conserving ones.
2)
Mixed case is used in names, rather than underscores, to combine multiple words (e.g.
scaleFactor).
3)
Element names begin with an upper case letter (e.g. Variable).
4)
Attribute names begin with a lower case letter (e.g. name).
Actual values, called data (bold text in Figure 1), for attributes are entered to the right of the equal signs.
Underscores may be used in data names, but the mixed case naming convention is preferred. Other data
standardization and conventions are covered in the Common Data Dictionary in Annex B.
The SPA xTEDS Schema defines the root element as “xTEDS” and all elements that can be directly
nested under it as “child” elements. Figure 2 shows a diagram of all the elements that can be used in an
AIAA S-XXX-200X
xTEDS and all possible child elements for each element. There are presently 20 distinct elements that
have been defined for the xTEDS. The function of each element is explained in Table 1.
Application
Qualifier
Device
Qualifier
Location
Orientation
XTEDS
Qualifier
Location
Orientation
Interface
Variable
Qualifier
Location
Orientation
Drange
Option
Curve
Coefficient
CommandMsg
Qualifier
VariableRef
FaultMsg
Qualifier
VariableRef
DataMsg
Qualifier
VariableRef
FaultMsg
Qualifier
VariableRef
CommandMsg
Qualifier
VariableRef
DataReplyMsg
Qualifier
VariableRef
FaultMsg
Qualifier
VariableRef
Command
Notification
Request
Figure 2 The allowable xTEDS structure shows the complete set of elements and nesting relations.
It is possible for a SPA component to have more than one interface. An interface is defined as a grouping
of messages by logical convenience, such as messages related to power or messages related to safety.
The groupings are determined by the xTEDS developer, but each interface must be complete and
uniquely defined in accordance with the XML and xTEDS Schemas, i.e., messages in one interface
cannot reference variables defined in another interface. The same variable can be used in two different
interfaces, but it must be completely defined in each interface.
Each element has one or more attributes that describe or define the element. A complete list of the
allowable attributes for each element is also provided in Table 1. Annex D provides more detailed
descriptions for all the allowable attributes.
15
AIAA S-XXX-200X
Table 1 The complete set of elements and attributes allowed in an xTEDS.
Element
xTEDS
Function
The root element, it defines the
static properties and messages
interfaces for SPA components.
Application
Defines the static properties of a
SPA software application
Device
Defines the static properties of a
SPA hardware device
componentKey
name
kind
Interface
Defines the set of messages and
variables implemented by the
SPA component
Provides additional information
about the component. It can be
used to query for components.
Provides device location in Body
Coordinates – merged at runtime from an SDMConfig
instance document (See the
SPA SDM Standard)
Provides device orientation –
merged at run-time from an
SDMConfig instance document
(See the SPA SDM Standard)
Defines specific information that
will be conveyed in a Command,
Notification, or Request
Message. Variables must be
defined at the interface level
before they can be used in a
specific message.
name
id
Qualifier
Location
Orientation
Variable
Required Attributes
xlmns (xTEDS namespace)
xmlns:xsi (XML namespace)
schemaLocation
name
version
componentKey
name
kind
Optional Attributes
description
description
version
manufacturerId
id
architecture
memoryMinimum
operatingSystem
pathForAssembly
pathOnSpacecraft
description
version
manufacturerId
modelId
versionLetter
serialNumber
calibrationDate
calDueDate
powerRequirements
description
extends
name
value
units
x
y
z
units
- none -
axis
angle
units
- none -
name
kind
format
units
id
description
rangeMin
rangeMax
yLow
yHigh
rLow
rHigh
length
defaultValue
invalidValue
precision
AIAA S-XXX-200X
Drange
Option
Curve
Coefficient
Command
Notification
Request
CommandMsg
DataMsg
DataReplyMsg
FaultMsg
Used to define a range of
discrete values that can be
assigned to a specific variable
Used exclusively with Drange
Elements to describe a discrete
value and a name to be
associated with the value.
Defines coefficients for a named
polynomial curve for data
conversion from raw data counts
to engineering units
Used exclusively with Curve
Elements to hold the coefficients
for a conversion curve.
Describes a value and an
exponent associated with the
value.
Defines a one-way command
operation using an in-only or
robust-in-only message
exchange pattern with exactly
one input command message
and an optional fault message.
Defines a one-way data or event
notification operation using outonly and robust-out-only
message exchange patterns with
exactly one output data
message and an optional fault
message.
Defines a two-way requestresponse operation using in-out
and in-optional-out with exactly
one input command message
followed by one output data
reply message and an optional
fault message. Using the fault
replaces the data reply message
and the fault message triggers
fault rules.
Defines a command message
received by the component
Defines a data message sent by
the component
Defines a data message sent by
the component in response to
the associated CommandMsg.
Defines a fault message.
Typically, a fault message will
name
accuracy
scaleFactor
scaleUnits
description
name
value
description
alarm
name
description
exponent
value
description
- none -
- none -
- none -
- none -
- none -
- none -
name
id
name
id
msgArrival
name
id
description
name
id
description
description
msgRate
description
17
AIAA S-XXX-200X
VariableRef
contain a reference to a variable
that specifies the fault as a
Drange
Identifies a message parameter
previously defined as a variable
name
- none -
AIAA S-XXX-200X
Annex A
SPA Common Commands (Normative)
19
AIAA S-XXX-200X
Annex B
Common Data Dictionary Overview (Informative)
B.1
Purpose
B.2
Organization
B.3
Format
B.4
Access
1
AIAA S-XXX-200X
Annex C
C.1
SPA xTEDS Schema and Validating Parsers (Informative)
General
The W3C XML Schema was designed with the intent that determination of a document's validity would
produce a collection of information adhering to specific data types. It can be used with validation software
in order to ascertain whether a particular XML document is of that type, and to produce a Post Schema
Validation Infoset (PSVI). In the PSVI for an xTEDS, each element, attribute, and in general, any node of
the xTEDS XML document is assigned the data type from the xTEDS schema.
Version Number Conventions:
Advances in minor versions must be a compatible superset of earlier minor versions of the same major
version, i.e., backward compatibility is guaranteed.
Advances in major version are not required to be supersets of earlier versions and are not guaranteed to
be backward compatible.
The xTEDS schema filename includes the major version number and is referenced in the xTEDS
element’s xsi:schemaLocation attribute.
xTEDS are validated against the latest xTEDS schema version.
1
AIAA S-XXX-200X
Annex D
SPA Attributes (Normative)
Attribute
Description
accuracy
alarm
angle
architecture
axis
calDueDate
calibrationDate
componentKey
defaultValue
description
exponent
extends
format
id
invalidValue
kind
length
manufacturerId
memoryMinimum
modelId
msgArrival
msgRate
name
operatingSystem
pathForAssembly
pathOnSpacecraft
powerRequirements
precision
1
AIAA S-XXX-200X
rangeMax
rangeMin
rHigh
rLow
scaleFactor
scaleUnits
schemaLocation
serialNumber
units
value
version
versionLetter
x
xlmns
(xTEDS namespace)
xmlns:xsi
(XML namespace)
y
yHigh
yLow
z