1、 1 Standard AIAA S-133-8-2013 S-102.2.5-2009 Space Plug-and-Play Architecture Standard Test Bypass 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
2、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 electronic
3、 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-8-2013 Space Plug-and-Play Architecture Standard Test Bypass Sponsored by American Institute of Aeron
4、autics and Astronautics Approved August 2013 Abstract This document describes the function and application of the test bypass mechanism for systems based on the Space Plug-and-Play Architecture (SPA). The test bypass function supports hardware-in-the-loop testing with simulated component data. Incor
5、porating test bypass into SPA components allows for rapid component assembly, integration, test, and system verification. AIAA S-133-8-2013 iii Published by American Institute of Aeronautics and Astronautics 1801 Alexander Bell Drive, Reston, VA 20191 Copyright 2013 American Institute of Aeronautics
6、 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 ISBN 978-1-62410-236-3 AIAA S-133-8-2013 iii Contents Foreword .
7、 v Introduction vii 1 Scope 1 2 Applicable Documents . 1 3 Vocabulary 1 3.1 Acronyms and Abbreviated Terms 1 3.2 Terms and Definitions . 2 4 Test Bypass in SPA Systems 3 5 Usage 9 6 Test Bypass Message Protocol . 11 6.1 NOOP Operation . 13 6.2 PUT Operation 13 6.3 WRITE Operation 14 6.4 GET Operatio
8、n 14 6.5 SETMASK Operation 15 6.6 CLRMASK Operation 15 6.7 SETECHO Operation 16 6.8 CLRECHO Operation 16 6.9 ENGAGE Operation 17 6.10 DISENGAGE Operation 17 6.11 WELENGTH Operation . 17 6.12 RDFLAGS Operation . 17 6.13 FLAGMSG Operation 18 Annex A AFRL Implementation of Test Bypass 179 Tables Table
9、1 Typical variable table for angular rate measuring device . 9 Table 2 Type/length definitions for individual variables . 10 Table 3 Mask and echo combinations . 10 Table 4 Test bypass OpCodes 11 Table 5 Test Bypass OpCode Marshalling Layouts 12 Table 6 NOOP Field Definitions 13 Table 7 PUT Field De
10、finitions . 13 Table 8 WRITE Field Definitions . 14 Table 9 GET Field Definitions . 14 AIAA S-133-8-2013 iv Table 10 SETMASK Field Definitions 15 Table 11 CLRMASK Field Definitions . 15 Table 12 SETECHO Field Definitions . 16 Table 13 CLRECHO Field Definitions . 16 Table 14 WELENGTH Field Definition
11、s . 17 Table 15 RDFLAGS Field Definitions . 17 Table 16 FLAGMSG Field Definitions 18 Table A.1 Device class codes 19 Table A.2 Vendor ID codes . 20 Table A.3 System and subsystem identification codes . 21 Figures Figure 1 The test bypass interface network 3 Figure 2 ASIM test bypass dual ported memo
12、ry implementation 4 Figure 3 The ASIM microcontroller interfaces a native component to the SPA data network . 5 Figure 4 The ASIM microcontroller interfaces a native component to the SPA data network: device native data buffer 6 Figure 5 The ASIM microcontroller interfaces a native component to the
13、SPA data network: processed data buffer . 7 Figure 6 The ASIM microcontroller interfaces a native component to the SPA data network: xTEDS output message data buffer 8 AIAA S-133-8-2013 v Foreword This standard was developed through a partnership of the Air Force Research Laboratory Space Vehicles D
14、irectorate, the Air Forces Office of Operationally Responsive Space, numerous government contractor teams, independent contractor teams, and academic experts. The Test Bypass standard is one piece of the Space Plug-and-Play Architecture (SPA), which is a system that aims to reduce the cost and timel
15、ine of getting spacecraft into operational use. SPA incorporates the use of design tools, standard interfaces for hardware and software, and standard, modular structures and wiring. Test Bypass functionality allows for rapid testing and verification of components and systems. SPA components may or m
16、ay not support a bypass function. This standard provides instruction on implementing Test Bypass for those components that do support it. This particular volume of the SPA Physical Interface Standard contains information not recorded in previous documentation. It is part of a set of 10 documents des
17、cribing other components of the standard: SPA Guidebook SPA Networking Standard SPA Logical Interface Standard SPA Physical Interface Standard SPA 28V Power Service Standard SPA System Timing Standard SPA Ontology Standard SPA SpaceWire Subnet Adaptation Standard SPA System Capability Guide At the t
18、ime 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 Net Engineering Group
19、 Jane Hansen HRP Systems Doug Harris The Aerospace Corporation, ORS Office Paul Jaffe U.S. Naval Research Laboratory Stanley Kennedy* Comtech Aero-Astro Ronald Kohl R.J. Kohl see IEEE 1451 family for examples. AIAA S-133-8-2013 3 4 Test Bypass in SPA Systems A Space Plug and Play Architecture (SPA)
20、compliant system allows components (hardware devices and software applications) to be joined in a self forming data exchange network to eliminate the need for customized component interfaces. The goal of this approach is to greatly increase the speed and lower the costs of spacecraft assembly, integ
21、ration, and test (AI xTEDS-described commands are processed into device-specific variables and written to the device using the native behavioral model. The reader is referred to the SPA Ontology Standard (AIAA S-133-7-2013) for more detailed explanation of the xTEDS concept and standards. R e a d D
22、e v i c e N a t i v e D a t a W r i t e D e v i c e N a t i v e C o m m a n d sP r o c e s s d e v i c e d a t a i n t o x T E D S d e s c r i b e d v a r i a b l e sT r a n s l a t e c o m m a n d s i n t o n a t i v e b e h a v i o r m o d e lL o c a l M e m o r yF o r m a t i n t o x T E D S d e
23、s c r i b e d S P A M e s s a g e sC o n v e r t c o m m a n d s i n t o d e v i c e s p e c i f i c v a r i a b l e sS e n d S P A D a t a M e s s a g e s t o s u b s c r i b e r sR e c e i v e S P A C o m m a n d M e s s a g e sH a r d w a r e D e v i c e w i t h N a t i v e D a t a I n t e r f a
24、c eL o c a l M e m o r yS P A D a t a N e t w o r kA SI M F u n c ti o n sL o c a l M e m o r yFigure 3 The ASIM microcontroller interfaces a native component to the SPA data network If the simulation provides detailed data just like it is read from the device, then Figure 4 represents how DPM can b
25、e used to inject simulated device data which is then processed in the same way as actual device data. This is the preferred way to implement TB since it provides maximum processing of data by the ASIM and therefore maximum verification of data latency and correctness of ASIM code. It should be noted
26、 that DPM is depicted as a block, but each register of the 256 available can be used where appropriate. AIAA S-133-8-2013 6 Similarly, Figures 5 and 6 represent how models that provide data more representative of processed (Figure 5) and final message variables (Figure 6) can be integrated into ASIM
27、 code using DPM registers and the Test Bypass Interface (TBI). R e a d D e v i c e N a t i v e D a t a W r i t e D e v i c e N a t i v e C o m m a n d sP r o c e s s d e v i c e d a t a i n t o x T E D S d e s c r i b e d v a r i a b l e sT r a n s l a t e c o m m a n d s i n t o n a t i v e b e h a
28、 v i o r m o d e lD u a l P o r t e d M e m o r yF o r m a t i n t o x T E D S d e s c r i b e d S P A M e s s a g e sC o n v e r t c o m m a n d s i n t o d e v i c e s p e c i f i c v a r i a b l e sS e n d S P A D a t a M e s s a g e s t o s u b s c r i b e r sR e c e i v e S P A C o m m a n d M
29、e s s a g e sH a r d w a r e D e v i c e w i t h N a t i v e D a t a I n t e r f a c eL o c a l M e m o r yS P A D a t a N e t w o r kA SI M F u n c ti o n sL o c a l M e m o r yT e s t B y p a s s I n te r fa c eFigure 4 The ASIM microcontroller interfaces a native component to the SPA data network
30、: device native data buffer NOTE. The test bypass interface (TBI) is used to inject model data into the device native data buffer. AIAA S-133-8-2013 7 R e a d D e v i c e N a t i v e D a t a W r i t e D e v i c e N a t i v e C o m m a n d sP r o c e s s d e v i c e d a t a i n t o x T E D S d e s c
31、r i b e d v a r i a b l e sT r a n s l a t e c o m m a n d s i n t o n a t i v e b e h a v i o r m o d e lL o c a l M e m o r yF o r m a t i n t o x T E D S d e s c r i b e d S P A M e s s a g e sC o n v e r t c o m m a n d s i n t o d e v i c e s p e c i f i c v a r i a b l e sS e n d S P A D a t a
32、 M e s s a g e s t o s u b s c r i b e r sR e c e i v e S P A C o m m a n d M e s s a g e sH a r d w a r e D e v i c e w i t h N a t i v e D a t a I n t e r f a c eD u a l P o r t e d M e m o r yS P A D a t a N e t w o r kA SI M F u n c ti o n sL o c a l M e m o r yT e s t B y p a s s D a t aFigure
33、5 The ASIM microcontroller interfaces a native component to the SPA data network: processed data buffer NOTE. The test bypass interface (TBI) is used to inject model data into the processed data buffer. AIAA S-133-8-2013 8 Figure 6 The ASIM microcontroller interfaces a native component to the SPA da
34、ta network: xTEDS output message data buffer NOTE. The test bypass interface (TBI) is used to inject model data into the xTEDS output message data buffer. AIAA S-133-8-2013 9 5 Usage Test Bypass is a cooperative implementation between the TB host and the ASIMs. The TB host connects to each TB router
35、 using a RS422, 460.8 Kbps serial connection. It is a requirement for the TB host to have one serial port for each concurrent router to be controlled. For PnPSat-2, the PsNic card implements six RS422 serial ports. Others may be substituted or added as appropriate. In order to facilitate dynamic con
36、figuration of the TB host software, the ASIM can deliver a TB variable table that describes the variables that are mapped to DPM registers and are available for bypass/ echoing. It is the TB hosts option to make use of the TB variable table. The device management code in the ASIM must write and then
37、 read from the DPM registers so that the TB hardware can bypass and echo the data. There are two library functions that access the TB dual ported memory, DPM_Read and DPM_Write. As long as the device code performs a write followed by a read, the variable hosted by the DPM register can be bypassed an
38、d echoed from external control. The device code never knows if its being bypassed or not. This implementation removes the need for special ASIM test code. All test logic resides in the TB host computer as shown in Figure 1. In order to facilitate the TB hosts configuration process, the ASIM makes sp
39、ecial use of DPM register 0. DPM register 0 is the only register initialized to SETECHO after power is applied by the hardware. This facilitates the ASIMs default sending of a TB heartbeat, typically at 1 second intervals. The heartbeat is a PUT on register 0 with a value of 1 and is 8 bytes in leng
40、th. The TB host software recognizes the heartbeat and may request the ASIMs variable table with a value of A5A5A5A5A5A5A5A5 written to register 0. When the ASIM sees this request, it sends its variable table through register 0, 8 bytes at a time. The last fractional write is zero filled. Finally, to
41、 signify the end of the variable table, B6B6B6B6B6B6B6B6 is sent from the ASIM to the TB host. A typical variable table for a device is shown in Table 1. Table 1 Typical variable table for angular rate measuring device Register Id 1 byte Type/Length 1 byte Direction 1 byte Name N bytes, 0 1 UINT08 F
42、romAsim DevicePowerState 2 FLOAT32 ToAsim AsimTemperature 3 FLOAT32 ToAsim AngularRateX 4 FLOAT32 ToAsim AngularRateY 5 FLOAT32 ToAsim AngularRateZ 254 UINT08 NA 08,13,01 255 UINT08 NA After receiving the TB variable table, The TB host typically then sets mask and echo flags on the DPM registers in
43、the table that facilitate the direction specified for that register. Finally, DPM register 0s echo is disabled and the masked registers are ENGAGED. DPM Register 0 is reserved for initialization and register 254 and 255 are reserved for identification data. DPM Register 255 in the variable table is
44、used to send the ASIMs UUID as a 32 character hex string AIAA S-133-8-2013 10 representation of the 16 byte UUID. DPM Register 254 contains DeviceClass, VendorId, and SubsystemId. Use of this data is not mandated. In Table 1, the length field can be either type or length. Length is sufficient if the
45、 variable name is in the devices xTEDS, but type is required for other variables. Type can have the values listed in Table 2. Table 2 Type/Length definitions for individual variables In Table 1, Direction indicates the default direction the variable moves; either to or from the ASIM. It is used to s
46、et the mask and echo bits on the DPM register. However, the TB host can change the mask and echo bits to suit its needs, even if they differ from the variable table. The various combinations of echo and mask bits are listed in Table 3. Table 3 Mask and echo combinations Direction Mask Echo Not bypas
47、sed False False To ASIM True False From ASIM False True Bi-directional True True Type/Length Value Length1 1 Length2 2 Length4 4 Length8 8 UINT08 17 INT08 18 UINT16 19 INT16 20 UINT32 21 INT32 22 FLOAT32 23 FLOAT64 24 UINT64 25 INT64 26 AIAA S-133-8-2013 11 6 Test Bypass Message Protocol Test Bypass
48、 is a routed data protocol that is single-ended on the host side and multi-ended on the device-under-test (DUT) side of the connection. Any packet traffic travelling from the host to a device must carry a routing byte as the first byte of the packet. Test Bypass assumes only one TB router between th
49、e host and the target device. Current second generation SPA hardware supports a total of 11 endpoints; with expansion in the protocol it is possible to support up to 255 devices. The baud rate for TB messaging is 460.8 kbaud, with 8 data bits, NO parity, one stop bit, and no flow control. Byte values of 1-11 will route to an endpoint, whereas a byte value of 0 will route to the TB router itself. TB implements packets that are discriminated with an OpCode. This OpCode is the second byte
