AIAA S-133-7-2013 Space Plug-and-Play Architecture Standard Ontology.pdf

1、 Standard AIAA S-133-7-2013 S-102.2.5-2009 Space Plug-and-Play Architecture Standard Ontology AIAA standards are copyrighted by the American Institute of Aeronautics and Astronautics (AIAA), 1801 Alexander Bell Drive, Reston, VA 20191-4344 USA. All rights reserved. AIAA grants you a license as follo

2、ws: The right to download an electronic file of this AIAA standard for storage on one computer for purposes of viewing, and/or printing one copy of the AIAA standard for individual use. Neither the electronic file nor the hard copy print may be reproduced in any way. In addition, the electronic file

3、 may not be distributed elsewhere over computer networks or otherwise. The hard copy print may only be distributed to other employees for their internal use within your organization. AIAA S-133-7-2013 Space Plug-and-Play Architecture Standard Ontology Sponsored by American Institute of Aeronautics a

4、nd Astronautics Approved August 2013 Abstract SPA systems use the XML schema in conjunction with extensible transducer electronic data sheets (xTEDS) to convey information about devices to the system. This document provides details on the use of common electronic data sheet schema for plug-and-play

5、systems. AIAA S-133-7-2013 ii Published by American Institute of Aeronautics and Astronautics 1801 Alexander Bell Drive, Reston, VA 20191 Copyright 2013 American Institute of Aeronautics and Astronautics All rights reserved No part of this publication may be reproduced in any form, in an electronic

6、retrieval system or otherwise, without prior written permission of the publisher. Printed in the United States of America ISBN 978-1-62410-235-6 AIAA S-133-7-2013 iii Contents Foreword iv Introduction. vi 1 Scope . 1 2 Applicable Documents . 1 3 Vocabulary . 1 3.1 Acronyms and Abbreviated Terms . 1

7、4 xTEDS and the XML Schema Language . 2 4.1 SPA xTEDS Schema . 2 4.2 xTEDS Format . 2 4.3 xTEDS Syntax 3 4.4 Common Data Dictionary . 8 Annex A Common Data Dictionary and xTEDS Extensions . 10 A.1 CDD Purpose . 10 A.2 Updating the CDD 10 A.3 Validating XML Parser . 10 Annex B Exemplar SPA CDD . 10 B

8、.1 Ontology Naming Conventions 10 B.2 Taxonomies 11 Figures Figure 1 Sample xTEDS showing the basic parts of an XTEDS, elements, and attributes . 3 Figure 2 Defining the variable element 4 Figure 3 Allowable xTEDS structure shows the complete set of elements and nesting relations . 5 Figure B.1 The

9、StandardImplemented taxonomy 10 Figure B.2 The Kind taxonomy root . 13 Figure B.3 The Application Kind taxonomy 14 Figure B.4 The Device Kind taxonomy 15 Figure B.5 The Variable Kind taxonomy root . 16 Figure B.6 Expansion of the System segment of the Variable Kind taxonomy . 17 Figure B.7 Expansion

10、 of the Inertia and GPS segments of the Variable Kind taxonomy 18 Figure B.8 Expansion of the MagneticField and Sun segments of the Variable Kind taxonomy . 19 Figure B.9 Expansion of the StarTracking and Camera segments of the Variable Kind taxonomy 20 Figure B.10 Expansion of the ReactionWheel seg

11、ment of the Variable Kind taxonomy . 21 Figure B.11 Expansion of the Torquer and Propulsion segments of the Variable Kind taxonomy 22 Figure B.12 Expansion of SGLS, Battery, and Hub segments of the Variable Kind taxonomy . 23 AIAA S-133-7-2013 iv Figure B.13 Expansion of the SolarArray segment of th

12、e Variable Kind taxonomy 24 Figure B.14 First half of the Units taxonomy 25 Figure B.15 Second half of the Units taxonomy 26 Tables Table 1 Complete set of elements allowed in an xTEDS. 6 Table 2 Set of common data dictionary tables . 9 Table B.1 Complete set of taxonomies in the SPA Ontology 11 Tab

13、le B.2 The set of dual-option enumerations . 27 Table B.3 The set of multiple-option enumerations . 28 AIAA S-133-7-2013 v Foreword This standard was developed through a partnership of the Air Force Research Laboratory Space Vehicles Directorate, the Air Force Office of Operationally Responsive Spac

14、e, numerous government contractor teams, independent contractor teams, and academic experts. The Space Plug-and-Play Architecture (SPA) is a collection of standards developed to facilitate rapid constitution of spacecraft systems using modular components. This document includes specifications for th

15、e use of a common XML-based schema for conveying information about components to the system. The intent of this document is to allow SPA designers and manufacturers to provide components and/or subsystems that successfully interface with SPA-enabled spacecraft. This particular volume of the SPA Onto

16、logy Standard contains information not recorded in previous documentation. It is part of a set of 10 documents describing other components of the standard: SPA Guidebook SPA Networking Standard SPA Logical Interface SPA Physical Interface Standard SPA 28V Power Service Standard SPA System Timing Sta

17、ndard SPA Test Bypass Standard SPA SpaceWire Subnet Adaptation Standard SPA System Capability Guide At the time of approval, the members of the AIAA SPA Committee on Standards were: Fred Slane, Chair Space Infrastructure Foundation Jeanette Arrigo Sierra Nevada Corporation Scott Cannon Utah State Un

18、iversity Ken Center PnP Innovations Don Fronterhouse* PnP Innovations Rod Green Design Group Jane Hansen HRP Systems Doug Harris Operationally Responsive Space Office Paul Jaffe Naval Research Laboratory Stanley Kennedy* Comtech Aero-Astro Ronald Kohl R.J. Kohl & Associates Bill Kramer Independent R

19、amon Krosley Independent Denise Lanza SAIC AIAA S-133-7-2013 vi James Lyke Air Force Research Laboratory Joseph Marshall BAE Systems Gerald Murphy* Design Group Gary Rodriguez sysRand Steven Schenk Comtech Aero-Astro Robert Vick* SAIC The above consensus body approved this document in June 2013. The

20、 AIAA Standards Executive Council (VP-Standards, Laura McGill, Chairperson) accepted the document for publication in August 2013. 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

21、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 subj

22、ect matter. Prospective users of the publications are responsible for protecting themselves against liability for infringement of patents or copyright or both. _ *Alternate CoS Participant AIAA S-133-7-2013 vii Introduction The enabling mechanism for achieving plug-and-play (PnP) capability in SPA s

23、ystems is the extensible Transducer Electronic Data Sheet (xTEDS). Every hardware device or software application used within a SPA system must have an associated self-describing electronic data sheet that fully explains the component (device or application) to other components in the system. The xTE

24、DS contains descriptions of all component-specific commands accepted, variables produced, and data messages that can be delivered by the component. It fully describes the services or data provided by the component and represents the complete protocol for accessing these services or data. The xTEDS u

25、ses the eXtensible Markup Language (XML) to provide a schema-controlled language for the data sheet. A common set of terms shared by all SPA applications allows for the creation of xTEDS that can be understood and accessed by components throughout a SPA system. Descriptions of data products within d

26、ata messages are constructed from a SPA Common Data Dictionary (CDD) of standard terms. Terms used in the CDD must be easily recognized by the system developers, unique for each variable type, and nonduplicating. The use of an XML Parser and Validator software tool validates the SPA xTEDS against th

27、e xTEDS schema. It also tests the xTEDS against the CDD to ensure only registered terms are used. AIAA S-133-7-2013 1 1 Scope Two functions are critical in defining an ontology: Naming conventions and relationships between the names. The naming conventions have been selected to cover the complete do

28、main of data elements and characteristics to be addressed by the SPA ontology. A mechanism for expressing the terms relationally, a taxonomy, has also been defined so that the naming is unambiguous and terms cannot be mistakenly used out of context. Specifically, the taxonomy subdivides the problem

29、space into increasingly specialized classes, relationally assigning logical names to precisely defined relational paths within the taxonomy. The SPA Ontology is organized into a set of relational taxonomies to assign names to data and define properties. This standard establishes the electronic data

30、sheet for SPA for application in the space environment. It establishes the form of a common data dictionary and provides an exemplar. This standard is applicable to spacecraft with a rapid integration requirement. Guidance on preparing a SPA-compliant xTEDS is the subject of this standard. 2 Applica

31、ble 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 e

32、ncouraged 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. AIAA S-133-3-2013 Space Plug-and-Play Architecture Standard Logical Interface AIAA S-133

33、-2-2013 Space Plug-and-Play Architecture Standard Networking AIAA G-133-1-2013 Space Plug-and-Play Architecture Guidebook W3C XML Schema World-Wide Web Consortium-recommended XML Schema, version 1.0, May 2001 3 Vocabulary 3.1 Acronyms and Abbreviated Terms AIAA American Institute of Aeronautics and

34、Astronautics CDD Common Data Dictionary PSVI Post Schema Validation Infoset SPA Space Plug-and-Play Architecture XML XSD xTEDS extensible markup language XML schema definition extensible transducer electronic data sheet AIAA S-133-7-2013 2 4 xTEDS and the XML Schema Language The eXtensible Markup La

35、nguage (XML) standard sets 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 mu

36、ltiple widely available XML languages (i.e., Document Type Definition, RELAX NG, and W3C XML Schema), SPA has chosen to use the World-Wide Web Consortium-recommended XML Schema, abbreviated as W3C XML Schema, version 1.0, published in May 2001. 4.1 SPA xTEDS Schema 4.1.1 SPA shall use an XML schema

37、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. 4.1.2 All xTEDS prepared for SPA implementat

38、ions shall conform to the SPA xTEDS schema and the XML schema. 4.1.3 Conformance with the SPA xTEDS schema and the XML schema shall be validated using an XML parser and validator tool. 4.1.4 SPA uses a specific version number convention: Advances in minor versions shall be a compatible superset of e

39、arlier minor versions of the same major version. (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 t

40、he xTEDS elements xsi:schemaLocation attribute. The version of the SPA xTEDS schema standardized in this document is version 2.5. 4.2 xTEDS Format The xTEDS defines communication interfaces between a software application or a hardware device and the rest of the satellite network. 4.2.1 All xTEDS sha

41、ll have three basic parts: a) The header, that names the xTEDS and the schema with which it conforms, b) The component declaration, that provides information on the supported application or device, and c) All the communication interfaces that the device or application supports. 4.2.2 xTEDS informati

42、on shall be presented in the XML format. Every piece of information in this format 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 look

43、s like: - AIAA S-133-7-2013 3 The slash symbol is used to indicate the end of each element. The hyphen (added by the viewing application) shows the beginning of a nested element, while the slash before the element name indicates the end of the nested element. Multiple layers of nesting can be used.

44、4.2.3 All possible xTEDS elements and attributes must be defined in the xTEDS schema. 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. Figure 1 Sample xTEDS showing the basic parts of

45、 an xTEDS, elements, and attributes 4.3 xTEDS Syntax 4.3.1 xTEDS shall conform to the XML syntax. 4.3.2 Several naming conventions shall be followed in building an xTEDS: a) Use self-describing names. These are preferred over short, bandwidth-conserving ones. b) Use mixed case in names. Do not use u

46、nderscores to combine multiple words (e.g., scaleFactor, not scale_Factor). c) Element names begin with an upper case letter (e.g., Variable). d) Attribute names begin with a lower case letter (e.g., name). 4.3.2 Data (bold text in Figure 1) for attributes shall be entered to the right of the equal

47、signs. Other data standardization and conventions are covered in the Common Data Dictionary in Section 4.4. 4.3.3 If a device implements standard interfaces as defined in xTEDS Templates, the devices xTEDS shall refer to the standard it implements using the standardImplemented attribute. The devices

48、 xTEDS duplicates the contents of the xTEDS Template, so that the xTEDS can serve as a self-contained description of the interface. However, it may also extend the xTEDS Template by adding additional variables or by adding attributes that were not specified in the Template. - - - - - - Headerrr Comp

49、onent Declaration (static properties of a device or application) Communication Interface Elements Attributes AIAA S-133-7-2013 4 4.3.4 An xTEDS Template can define that a variables data type be UINT, INT, or FLOAT. In that way, a components xTEDS can define variables in two ways. The first method is by using variable fields. The second method is by using bit fields. Figure 2 shows how a variable element can be defined. Variable Element in xTEDS Template: Variable Element in an xTEDS us