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