AIAA S-133-3-2013 Space Plug-and-Play Architecture Standard Logical Interface.pdf

1、Standard AIAA S-133-3-2013 S-102.2.5-2009 Space Plug-and-Play Architecture Standard Logical Interface 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

2、as follows: 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 electro

3、nic file 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-3-2013 Space Plug-and-Play Architecture Standard Logical Interface Sponsored by American Institute

4、 of Aeronautics and Astronautics Approved November 2012 Abstract The logical interface of SPA is the boundary through which components participate in a SPA system. This document describes the messages that pass across the SPA interface, the circumstances under which those messages flow, and the prot

5、ocols for sequencing those messages. This document does not attempt to describe how the messages are transported from one component to the other. This document and its messages are agnostic to message routing, message delivery, or the network topology. Furthermore, this document does not attempt to

6、describe the details on how these messages are implemented for a mission. The use of these messages can seem vague without a complete implementation or mission-specific example. The SPA Guidebook gives examples and principles on how these messages are used to achieve the capabilities of a fully func

7、tional plug-and-play architecture. AIAA S-133-3-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 a

8、ny form, in an electronic retrieval system or otherwise, without prior written permission of the publisher. Printed in the United States of America ISBN 978-1-62410-231-8 AIAA S-133-3-2013 iii Contents Foreword . vi Introduction vii 1 Scope. 1 2 Tailoring . 1 3 Applicable Documents . 1 4 Vocabulary

9、. 2 4.1 Acronyms and Abbreviated Terms . 2 4.2 Terms and Definitions 2 5 SPA Interface . 3 5.1 SPA Header . 3 5.2 Component Data Capabilities 10 5.3 Component Network Capabilities . 45 5.4 Component Identification . 59 Figures Figure 1 SPA probe request sequence diagram 12 Figure 2 SPA xTEDS request

10、 sequence diagram 15 Figure 3 SPA registration info request sequence diagram 19 Figure 4 SPA subscription request sequence diagram 1 29 Figure 5 SPA subscription request sequence diagram 2 30 Figure 6 SPA subscription request sequence diagram 3 31 Figure 7 SPA subscription request sequence diagram 4

11、 32 Figure 8 SPA data request sequence diagram 37 Figure 9 SPA command sequence diagram . 39 Figure 10 SPA service reply sequence diagram 41 Figure 11 Notification of components to SPA lookup service sequencing diagram 46 Figure 12 Error reporting sequencing diagram 46 Figure 13 Guaranteed delivery

12、request sequence diagram 54 Figure 14 Guaranteed delivery acknowledge sequence diagram 55 Figure 15 Guaranteed delivery message resend upon failure sequence diagram . 56 Figure 16 Guaranteed delivery acknowledgement resend upon failure sequence diagram 56 Figure 17 Restart of failed receiver sequenc

13、e diagram 57 Tables Table 1 SPA standard message header . 3 AIAA S-133-3-2013 iv Table 2 SPA extended message header 6 Table 3 SPA guaranteed delivery extended header 7 Table 4 SPA message sequencing 8 Table 5 SPA footer 10 Table 6 SPA probe request message 11 Table 7 SPA probe reply 12 Table 8 SPA

14、xTEDS request 15 Table 9 SPA xTEDS reply 17 Table 10 SPA registration info request message 20 Table 11 SPA registration info reply 22 Table 12 SPA variable info request . 25 Table 13 SPA variable info request . 27 Table 14 SPA subscription request 32 Table 15 SPA subscription reply . 36 Table 16 SPA

15、 data message 38 Table 17 SPA data request message 40 Table 18 SPA service request . 42 Table 19 SPA service reply message 43 Table 20 SPA request SPA lookup service probe message format . 47 Table 21 SPA network status request message format 47 Table 22 SPA network status reply message format . 49

16、Table 23 SPA time-at-tone message format . 52 Table 24 SPA guaranteed delivery extended header message format 58 Table 25 SPA transport message format 59 AIAA S-133-3-2013 v Foreword This document was developed by the Space Plug-and-Play Architecture (SPA) Standards Working Group as one of a series

17、describing the various components of the standard. The SPA standards were recorded in earlier documentation. This document set separates content along logical boundaries to better organize the volumes (so that developers or domain experts need only reference the documents applicable to their needs)

18、and to avoid duplication of content between documents in the standard series. This 2013 AIAA standard supersedes all previous documentation of the SPA standards. This particular volume of the SPA Logical Interface Standard contains information not recorded in previous documentation. It is part of a

19、set of 10 volumes describing other components of the standard: SPA Guidebook SPA Networking Standard SPA Physical Interface Standard SPA 28V Power Service Standard SPA System Timing Standard SPA Ontology Standard SPA Test Bypass Standard SPA SpaceWire Subnet Adaptation Standard SPA System Capability

20、 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 University Ken Center PnP Innovations Don Fronterhouse* PnP Innovations Rod Green Design Group

21、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 otherwise, the Lookup Service shall send a SPAxTEDSReply message for each match and one terminating SPAxTEDSReply message. The SPA

22、xTEDS request sequence diagram is shown in Figure 2. 5.2.2.2 SPA xTEDS Request Sequence Diagram Figure 2 SPA xTEDS request sequence diagram 1. The device or application sends a SPAxTEDSRequest message to the component with the RequestType set to either device address or device name. 2. If there are

23、no matches, the Lookup Service sends one terminating SPAxTEDSReply message; otherwise, the Lookup Service sends a SPAxTEDSReply message for each match and one terminating SPAxTEDSReply message. The format for the SPA xTEDS request message is shown below in Table 8. Table 8 SPA xTEDS request Message

24、Name SPAxTEDSRequest Message Opcode 66 SPA Version 1 (Note: “1” indicates the initial version) Summary Description Request xTEDS of a component Field Name Size Offset Value Description DialogIdentifier 0 2 n/a Dialog identifier set by the requester RequestType 2 2 n/a Identifier of field that identi

25、fies the component DeviceAddress 4 4 n/a Address of a device CUUID 16 8 n/a Universally Unique Id of the SPA component DeviceName n 24 n/a Name of a device Name DialogIdentifier Description Dialog identifier set by the requester Full Description Value used to pair SPAxTEDSRequest messages with corre

26、sponding SPAxTEDSReply messages Size 0 Offset 2 AIAA S-133-3-2013 16 DataType uint16 Units n/a DefaultValue n/a Range n/a Name RequestType Description Identifier of field that identifies the component Full Description The identifier of the field in this message that identifies the component whose xT

27、EDS is wanted Size 2 Offset 2 DataType uint16 Units n/a DefaultValue n/a Range Name Description Value SPA_xTEDS_REQUEST_DEVICE_ADDRESS Request based upon the DeviceAddress field 0 SPA_xTEDS_REQUEST_DEVICENAME Request based upon the DeviceName 1 SPA_xTEDS_REQUEST_DEVICE_CUUID Request based upon the S

28、PA Component ID 2 Name DeviceAddress Description Address of a device Full Description Address of a device to request the xTEDS Size 4 Offset 4 DataType uint32 Units n/a DefaultValue n/a Range n/a Name CUUID Description Universally Unique Id of the SPA component Full Description Universally Unique Id

29、 of the SPA component to request the xTEDS Size 16 Offset 8 DataType uint32 Units n/a DefaultValue n/a Range n/a Name DeviceName Description Name of a device Full Description Name of a device to request the xTEDS Size n Offset 24 AIAA S-133-3-2013 17 DataType uint8 Units n/a DefaultValue n/a Range n

30、/a 5.2.2.3 SPA xTEDS Reply Message This message is sent by any component or by the SPA Lookup Service to a component in response to a SPAReqxTEDS message. The Lookup Service shall search registered xTEDS for matching xTEDS. If there are no matches, then the Lookup Service shall send one terminating

31、SPAxTEDSReply message; otherwise, the Lookup Service shall send a SPAxTEDSReply message for each match and one terminating SPAxTEDSReply message. 5.2.2.4 SPA xTEDS Reply Sequence Diagram The SPA xTEDS reply message format is shown below in Table 9. Table 9 SPA xTEDS reply Message Name SPAxTEDSReply

32、Message Opcode 66 SPA Version 1 (Note: “1” indicates the initial version) Summary Description Response to an xTEDS request of a component Field Name Size Offset Value Description DialogIdentifier 2 0 n/a Dialog identifier set by the requester ReplyStatus 2 2 n/a Status code of the message DeviceAddr

33、ess 4 4 n/a Address of the device xTEDS n 8 n/a xTEDS of the requested device Name DialogIdentifier Description Dialog identifier set by the requester Full Description Value used to pair SPAxTEDSRequest messages with corresponding SPAxTEDSReply messages Size 2 Offset 0 DataType uint16 Units n/a Defa

34、ultValue n/a Range n/a Name ReplyStatus Description Status code of the message Full Description Status code indicating the reply type to the request message Size 2 Offset 2 DataType uint16 Units n/a DefaultValue n/a AIAA S-133-3-2013 18 Range Name Description Value REPLY_VALID Request was valid, and

35、 the xTEDS field is valid 0 xTEDS_CANCEL The previously transmited xTEDS is going offline or is no longer valid 1 ADDRESS_NOT_FOUND When sending the message to a registration service, this response indicates the address has not been registered 2 ADDRESS_INVALID When sending the message directly to a

36、 component, this response indicates that the request address does not match the component 3 CUUID_NOT_FOUND When sending the message to a registration service, this response indicates the CUUID has not been registered 4 CUUID_INVALID When sending the message directly to a component, this response in

37、dicates that the request CUUID does not match the component 5 DEVICENAME_NOT_FOUND When sending the message to a registration service, this response indicates the devicename has not been registered 6 DEVICENAME_INVALID When sending the message directly to a component, this response indicates that th

38、e request devicename does not match the component 7 Name DeviceAddress Description Address of the device Full Description Address of the device that this xTEDS applies to Size 4 Offset 4 DataType uint32 Units n/a DefaultValue n/a Range n/a Name xTEDS Description xTEDS of the requested device Full De

39、scription xTEDS of the requested device Size n Offset 8 DataType uint8 Units n/a DefaultValue n/a Range n/a AIAA S-133-3-2013 19 5.2.3 Querying for Data This message family (messages that support the application layer of SPA) supports the ability for a SPA component to query for desired data, comman

40、d providers, and service providers. The responses indicate matching providers. SPA provides three key query capabilities. The first is the ability to query for an item based on its name or qualifiers. Second is the ability to request metadata on a specific variable. The third is the ability to retri

41、eve an entire xTEDS, which is described in Section 5.2.2. 5.2.3.1 SPA Registration Info Request Message The SPA Regristration Info Request message is sent by a component to the SPA Lookup Service in order to request information about currently registered providers (see Figure 3). Writers of applicat

42、ions should be aware that less specific queries can return more information. For example, a query that specifies only a particular kind of device will return responses for all messages of all such devices on board. Similarly, a query that makes no specifications (all specifications are optional) wil

43、l return responses for all messages in the spacecraft. Sometimes such a prolific response is useful; for example, a telemetry application may query for all messages with a qualifier that indicates housekeeping data. If multiple Lookup Services are present on a spacecraft, they may exchange catalogs

44、by issuing more or less specific queries to each other. When multiple specifications are present in a query, they combine conjunctively, so the result is the intersection of the results that would be returned if each specification were present individually. 5.2.3.2 SPA Registration Info Request Sequ

45、ence Diagram Figure 3 SPA registration info request sequence diagram 1. The device or application shall send a SPARegistrationInfoRequest message to the Lookup Service with the reply type field set to current, current/future, or current/future/cancel. 2. If there are no matches, then the Lookup Serv

46、ice shall send one terminating SPARegistrationInfoReply message; otherwise, the Lookup Service shall send a SPARegistrationInfoReply message for each match and one terminating SPARegistrationInfoReply message. AIAA S-133-3-2013 20 3. If the reply type field in the original SPARegistrationInfoRequest

47、 message was set to current/future and in the future if a match becomes available, then the SPA Lookup Service shall send a SPARegistrationInfoReply message for the match and one terminating SPARegistrationInfoReply message. If the reply type field in the original SPARegistrationInfoRequest was set

48、to current/future/cancel and a match becomes unavailable, then the Lookup Service shall send a SPARegistrationInfoReply message indicating that the match is no longer available. 4. To cancel a subscription generated by a previous SPARegistrationInfoRequest message the device or application shall sen

49、d a SPARegistrationInfoRequest message identical to the original SPARegistrationInfoRequest message but with the reply type field set to cancel. The format for the SPA Registration Info Request message is shown below in Table 10. Table 10 SPA registration info request message Message Name SPARegistrationInfoRequest Message Opcode n SPA Version 1 (Note: “1” indicates the initial version) Summary Description Request information about currently registered providers Field Name