AIAA G-133-1-2013 Space Plug-and-Play Architecture Standards Development Guidebook.pdf

《AIAA G-133-1-2013 Space Plug-and-Play Architecture Standards Development Guidebook.pdf》由会员分享，可在线阅读，更多相关《AIAA G-133-1-2013 Space Plug-and-Play Architecture Standards Development Guidebook.pdf（49页珍藏版）》请在麦多课文档分享上搜索。

1、 Guide AIAA G-133-1-2013Space Plug-and-Play Architecture Standards Development Guidebook 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 follows: T

2、he 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 may

3、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 G-133-1-2013 Space Plug-and-Play Architecture Standards Development Guidebook Sponsored by American Institute of Aero

4、nautics and Astronautics Approved November 2012 Abstract This document provides a guideline for spacecraft platform, subsystem, and component (including payload) developers for integrating plug-and-play characteristics into spacecraft structures, avionics, and hardware and software components to pro

5、mote their rapid integration. This guideline will be used as the foundation for Space Plug-and-play Architecture (SPA) standards. The SPA community anticipates adding protocols (e.g., Ethernet as SPA-E) as the PnP capabilities are normalized. AIAA G-133-1-2013 ii Published by American Institute of A

6、eronautics 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 retrieval system or otherwise, without prior written permission of

7、 the publisher. Printed in the United States of America ISBN 978-1-62410-229-5 AIAA G-133-1-2013 iii ContentsForeword v Introduction vii 1 Scope . 1 2 Tailoring . 1 3 Applicable Documents . 1 3.1 Normative References . 1 4 Vocabulary . 1 4.1 Acronyms and Abbreviated Terms . 1 4.2 Terms and Definitio

8、ns 3 5 Architecture 5 5.1 SPA Inside a General Space Architecture . 5 5.2 SPA Inside . 5 6 SPA Goals, Concepts, Principles, and Structure . 7 6.1 Primary SPA Goal: Eliminating Barriers to Rapid Satellite Deployment 7 6.2 SPA Core Concept and Essential Services . 7 6.3 SPA Basic Capabilities 9 7 SPA

9、Implementation 10 7.1 Overview 10 7.2 Spacecraft Software Services From SPA 11 7.3 SPA Networking . 12 7.4 SPA Components (Devices and Applications) . 14 8 Example SPA Implementation . 16 8.1 Turning on a SPA System: What Happens When 16 8.2 Panel Concept . 20 9 SPA Tools 21 9.1 Design Tools 21 9.2

10、Test Tools 24 10 Summary of SPA Standards 27 10.1 General SPA Standards . 27 10.2 SPA Application-Specific Standards 31 Annex A Reference Architectures and Models . 33 A.1 The Data-Centric Plug-and-Play Approach 33 A.2 CCSDS SOIS Model 35 Figures Figure 1 Spacecraft bus architecture (systems view) w

11、ith SPA overlay 6 AIAA G-133-1-2013 iv Figure 2 SPA core concepts 7 Figure 3 The SPA Logical Model . 9 Figure 4 The SPA Services Manager 12 Figure 5 A SPA standard has been defined for each of the SPA system interfaces . 13 Figure 6 The ASIM interfaces the device to the SPA-X network . 15 Figure 7 S

12、PA network phases of operation . 16 Figure 8 The component discovery sequence 17 Figure 9 Device registration sequence 17 Figure 10 Message sequence to identify the Component Addressing Service . 18 Figure 11 Messaging sequence for assignment of logical address blocks 19 Figure 12 A structural panel

13、 concept . 20 Figure 13 SPA port number format . 22 Figure 14 The Test Bypass Interface Network 24 Figure 15 Test-bypass is implemented with a dual ported register file 26 Figure 16 The Flight Software-in-the-Loop typical configuration using two PCs . 27 Figure 17 Component Data Capabilities and Com

14、ponent Network Capabilities . 28 Figure 18 The SPA spacecraft single-point grounding approach 30 Figure A.1 SPA/OSI Layer Model correspondence . 33 Figure A.2 An OSI/SPA mapping 35 Figure A.3 SPA graphic . 36 Figure A.4 SOIS path between application and device protocol stacks 37 Figure A.5 Protocol

15、stacks for SPA applications on the left; SPA ASIMs on the right . 37 Tables Table 1 Letter code as it corresponds to the document 22 Table 2 Letter code for bus voltage. 23 Table 3 Letter code for mechanical and thermal devices. . 23 Table 4 Letter code for connectors and cabling. . 23 Table 5 Lette

16、r code for test bypass interfaces. . 24 AIAA G-133-1-2013 v 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. T

17、he invention of Plug-and-Play (PnP) capabilities is now assumed for any modern terrestrial computer system. PnP capability is defined in various publicly available technical standards. It is the purpose of the AIAA to capture, in this Space Plug-and-Play Architecture (SPA) Guidebook and associated t

18、echnical standards, technical approaches to adapt the various computer PnP capabilities to small spacecraft and the space environment. This Guidebook provides a general description of a data centric spacecraft model used to form the on-board PnP network. Various views are used to clearly indicate ho

19、w this works. A common ontology is described to allow for a profile specific Common Data Dictionary (CDD) so that a stable set of terms may exist. Interfaces between devices are described to simplify the implementation of PnP at the device level. Finally, those PnP protocols identified to date are g

20、enerally described, as are the adaptations needed for space application. The detailed requirements for each of these topics are listed in the respective AIAA SPA standards listed below. SPA Networking Standard SPA Logical Interface Standard SPA Physical Interface Standard SPA 28V Power Service Stand

21、ard SPA System Timing Standard SPA Ontology Standard 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 Sierr

22、a Nevada Corporation Scott Cannon Utah State University 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 AIAA G-133-1-

23、2013 vi Ronald Kohl R.J. Kohl it stores the logical address block, UUID, and physical address of each manager Component hardware or software that can be used in a SPA system Device hardware item that could be used in a SPA system AIAA G-133-1-2013 4 Extensible transducer electronic data sheet machin

24、e-readable representation of data provided, messages accepted, services provided, and physical characteristics (e.g., size, weight, and power) for a specific component within a plug-and-play network; xTEDS is conceptually based on the IEEE 1451 standards family Plug and play ability to connect a dev

25、ice to the larger system and have the two work together with little or no set-up required (e.g., automated system recognition and data exchange) Registers a set of 256 8-byte registers in dual ported memory Router a device on a SPA network with multiple ports that may be attached to either another S

26、PA router or a component endpoint SPA application a software SPA component SPA component an endpoint whose interface conforms to the SPA standards and does not connect to another SPA object via a different port; SPA components are both devices (hardware) and applications (software) SPA device a hard

27、ware SPA component SPA lookup service responsible for accepting component registration and providing data source route information for components requesting a particular type of service (or returning an acknowledgment if the service is not available) SPA manager responsible for performing discovery

28、for a particular subnet. It maps incoming packets to the correct SPA endpoint on the subnet, encapsulating the SPA packet with the correct protocol header. In the reverse direction it removes the protocol header and possibly adds a new header conforming to the subnet the packet is about to enter. It

29、 is also responsible for topology discovery and reporting within the subnet. SPA network an addressable and routable physically connected infrastructure composed of standard SPA transports for the purpose of transporting SPA messages between SPA endpoints and SPA gateways; the SPA network is made av

30、ailable as a SPA service to SPA components through a standard interface Test bypass host a test computer that recognizes, configures, and drives the test bypass routers and ASIMs while in a test configuration Universal serial bus familiar serial bus used by personal computers, which supports automat

31、ed enumeration and plug-and-play NOTE See http:/www.usb.org AIAA G-133-1-2013 5 5 Architecture 5.1 SPA Inside a General Space Architecture SPA sits on top of existing space architecture. SPA uses a federated approach to integrate with existing space architecture in areas such as launch systems and g

32、round systemsthose systems are not affected by SPA. In the area of spacecraft systems SPA only affects internal spacecraft aspects; SPA does not affect spacecraft external interfaces. In addition, SPA affects design, fabrication, integration and all aspects of test in a spacecraft lifecycle (see Fig

33、ure 1). SPA is not intended to affect spacecraft mission operations or end of life, but it can have a positive impact on spacecraft health through the operational phase. Because SPA does not address spacecraft external interfaces, SPA systems, services, data, and standards are constrained to describ

34、e spacecraft subsystems, assemblies, and components at interfaces and the interfaces themselves. It is important to note that SPA sits on top of existing space architecture even within the spacecraft. This replication of the federated approach mentioned previously allows SPA to take advantage of gen

35、eral advances in space systems development without the need to recreate SPA at each turn. Partially for this reason there is an expected connection between general spacecraft architecture and SPA that is not necessarily well defined from a standards perspective. There has been discussion on developi

36、ng SPA Application Program Interfaces (APIs) to more clearly constrain the connection from general spacecraft architecture to SPA, but as of this publication there is no clear consensus on exactly what such a standard should require. There are computer/software architecture models that have been app

37、lied to space systems. Annex A discusses the OSI model and the CCSDS SOIS model. 5.2 SPA Inside Different views present themselves within SPA, although the primary view is data-centric. SPA clearly describes specific viewpoints under the architecture. The SPA standards contain requirements primarily

38、 related to the following views: System View o Physical Interfaces, including mechanical and electrical interfaces are described in the Physical Interfaces Standard (AIAA S-133-4-2013) o Testing capabilities for SPA compliant spacecraft components, used primarily during spacecraft integration, are d

39、escribed in the Test Bypass Standard (AIAA S-133-8-2013) Services View o Power is described in the Power Service Standard (AIAA S-133-5-2013) o Timing is described in the System Timing Standard (AIAA S-133-6-2013) o Spacecraft internal computer network establishment and form are described in the Net

40、working Standard (AIAA S-133-2-2013) Data-Centric View o The necessary data and data structure for components is described in the Ontology Standard (AIAA S-133-7-2013) o Spacecraft design adaptation of existing space or computer technology protocols are described in the Subnet Adaptation Standards (

41、e.g., SpaceWire Subnet Adaptation; AIAA S-133-9-2013) o Spacecraft internal computer network traffic structure and interaction is described in the Logical Interface Standard (AIAA S-133-3-2013) AIAA G-133-1-2013 6 Figure 1 Spacecraft bus architecture (systems view) with SPA overlay As an example, th

42、e SPA Logical Interfaces Standard defines data structure as message content and format between networking managers and components in the logical interface. Message sequences describe how data flows strictly among the networking managers. The SPA Networking Standard describes some of the network mana

43、ger to component from a services perspective. Both views are necessary to establish complete requirements for such capabilities as component detection and component registration. Therefore, care should be taken to understand the complete set of requirements in the context of systems, services, and d

44、ata. SPA Standards are structured in a federated fashion. The following example outlines future innovations that could replace the network and transport layers of the protocol stack. The SPA Logical Interface Standard may be viewed as a layer in the protocol stack between the application and network

45、 layers. The SPA Networking Standard may be viewed as a description of a way to implement the network and transport layers. The documents are structured due to a possibility that the network and transport layers could be replaced in the future without affecting the logical interface. This may be an

46、enabler in the development of standardized SPA application programming interfaces (APIs). In Section 5.1 of this guide, SPA is defined as having an explicit dependence on spacecraft computational capabilities such as might be provided by a computer operating system (OS) or discrete services which ef

47、fectively fill that function. The SPA compliant bus subarchitecture can be federated and/or distributed; balancing the positive or negative aspects of each is left to the spacecraft designer. This means that under this dated rendition of SPA standards, compliant components can be used on any SPA com

48、pliant spacecraft, but each spacecraft designer will still need to create his/her own SPA compliant spacecraft control electronics suite. The remainder of this guidebook discusses core concepts of SPA in some detail and how those concepts AIAA G-133-1-2013 7 are translated into systems, services, an

49、d data-centric constructs. These systems, services, and data-centric constructs are further described in a sample (exemplar) implementation at the spacecraft systems level, subsystems level, and component level. SPA relevant tools that may be used in the design, fabrication, integration, or test phases are also discussed. Finally, the SPA standards are described. 6 SPA Goals, Concepts, Principles, and Structure 6.1 Primary SPA Goal: Eliminating Barriers to Rapid Satellite Deployment SPA, without stand