There are many different implementations on Plug-and-Play (PnP) on system level. At least Medical PnP (Med-PnP) and Space Plug-and-Play Avionics (SPA) are somewhat similar. This community focuses around the use of SPA and its implementations on aerospace and other systems, such as unmanned aerial vehicles (UAV), unmanned ground vehicles (UGV), etc.

Article table of contents:

• Introduction to Space Plug-and-Play Avionics (SPA)
• What is NanoSPA?
• What is QuadSat-PnP?
• What is QubeFlow?
• Introduction to SPA protocol and operation (SPA-1)

---

Introduction to Space Plug-and-Play Avionics (SPA)

Space Plug-and-Play Avionics (SPA) is defined as an interface-driven set of standards, encompassing hardware, software, and protocols, intended to promote the rapid affordable design and integration of advanced system buses and payloads. SPA is defined as an interface‐driven set of standards, encompassing hardware, software, and protocols, intended to promote the rapid affordable design and integration of spacecraft (busses and payloads). The SPA standards combine,

1. a core data transport standard, such as I2C (SPA-1), Universal Serial Bus (USB) (SPA‐U),  SpaceWire (SPA‐S), or Optical (SPA-O), with
2. a component‐transparent publish/subscribe software infrastructure, called the Satellite Data Model (SDM), on which software for command, control, data collection, processing, and analysis can be implemented. An electronic data sheet
3. called the extensible Transducer Electronic Data Sheet (xTEDS), is stored with each SPA component (hardware and software) and contains descriptions of all component specific commands accepted, variables produced, and data messages that can be delivered by the component. With thesethree standardized elements, a Plug‐and‐Play satellite can be rapidly designed and assembled from off‐the‐shelf, SPAready components.

Illustration of the SPA domains as given per power consumption, number of devices in a system, and example of their use. ÅAC's SPA compatible Remote Terminal Unit (RTU) interfaces for each domain are shown (nanoRTU™, µRTU™ and RTU).

A draft SPA standard has been prepared for each of these elements (SDM, xTEDS, SPA-1, SPA‐U, SPA‐S, and SPA-O) and, along with the overall SPA Guidebook, they are collectively being reviewed for publication.The common denomiator for SPA is a distributed architecture over different physical layers. Here is a SPA network using USB physical layer illustrated.

Illustration of a Space Plug-and-Play Avionic (SPA) network using USB physical protocol.

SPA has been around since 2004 and continues to develop, with new initiatives in several key areas:

The AFRL Advanced PnP Technologies (APT) contract winners were an-nounced in October 2009. These six contractors (AeroAstro, Broad Reach Engineering, MILTEC, Northrop Grumman, SEAKR, and Sierra Nevada Corporation) will refine SPA concepts for the future commercialization of constructing SPA satellites. One of these contractors will be chosen to build a SPA satellite bus for an actual launch opportunity in 2015. The APT contract value is topped at $250M USD.

The kick-off planning meeting for the latest AFRL SPA testbed, PnPSat 2, was held in October 2009 at AFRL. Numerous contractors are contributing to the development of this testbed, which will be used to develop and test SPA technologies, including the APT concepts.

A SPA-O demonstration is being developed by AFRL that uses a new, optical data transport medium, controlled by the SpaceWire standard (SPA-S). SPA-O will enable very high data transport rates across a SPA net-work/satellite. This demonstration should be ready by July 2010.
At the very core of SPA is a common set of terms that must be shared by all SPA applications to allow for the creation of electronic data sheets that can be understood and accessed by components throughout a SPA system. Terms used in the SPA Common Data Dictionary (CDD) must be easily recognized by the system developers, unique for each vari-able type, and non-duplicating. Based on lessons learned from the development of the first fully PnP satellite, PnPSAT, the CDD is being drasti-cally revised, at the fundamental level.

On August 28th 2009, U.S. and Sweden signed a bi-lateral project agreement to work on nanosatellites and Plug-and-Play "NAPA" under which ÅAC Microtec AB represent the Swedish industry. Under this agreement have ÅAC developed and verified a whole range of products and services around SPA.

Until 2015 are at least $750M USD investedthroughout different SPA programs in the US, ranging from CubeSats to large 400 kg military satellites.

What is NanoSPA?

NanoSPA is the joint application of two critical concepts, SPA and CubeSats. Nanosatellites (nanosats) represent a broad class of satellites in the range of 1‐10kg whose most popular member is the CubeSat family. The CubeSat standard was defined by California Polytechnic State University and Stanford University as a way for academia to participate in space science and research. The smallest CubeSat has dimensions of 10x10x10 centimeters and weighs no more than a kilogram. It is often called a “1U” CubeSat, meaning one unit. CubeSats are scalable in 2U (20×10×10 cm) and 3U (30×10×10 cm) increments. Since CubeSats are all 10x10 cm (regardless of length) they can all be launched using a common deployment system, the Poly‐Picosat Orbital Deployer (P‐POD). The CubeSat has been widely embraced by business and academia, with over 100 known development efforts. Most users fill their CubeSats with primarily custom content, exclusively optimized for a mission application. NanoSPA will target development of a more tightly standardized, though modular, class of CubeSats using a NanoSPA bus. Due to the limited size, the more compact SPA-1 and SPA‐U interfaces has been selected as the NanoSPA data transport standard. The payoff for choosing the NanoSPA version of the CubeSat will be simpler satellite design and faster readiness for flight.

Two photographs of a 3U NanoSPA satellite. Left, Assembled. Right, Open. Images courtesy of COSMIAC.

What is QuadSat-PnP?

QuadSat-PnP™ is a strategic collaboration between University of Applied Sciences Bremen (UoB) , OHB System, and ÅAC Microtec. The platform uses a "QuadSat" form factor where one standard unit 1U is (25 x 25 x 2.5 cm). ÅAC is providing the SPA PnP avionics and distributed power systems to the QuadSat-PnP platform. QuadSat-PnP is a scalable design and is much more capable than a typical QubeSat.

Illustration of a 3U QuadSat-PnP satellite. Image courtesy of University of Applied Sciences in Bremen.

What is QubeFlow?

CubeFlow will be a set of web based tools for developing NanoSPA satellites. When fully realized,this web portal will enable spacecraft developers to rapidly design, assemble, and integrate a launch ready NanoSPA. While SPA provides standards for rapid integration, CubeFlow will provide the tools that support requirements definition, mission design, creating xTEDS for components, testing designs and software, and many other support functions. CubeFlow is currently being developed by AFRL through a research contract with the Space Dynamics Laboratory (SDL) of the Utah State University Research Foundation (USURF). The web tools within QubeFlow is currently ITAR classified.

Introduction to SPA protocol and operations (SPA-1)

The SPA-1 protocol is based on the open source and ITAR Mini Plug-and-Play (MP) protocol. MP is based on the I2C protocol, however, the I2C protocol does not natively support auto numeration. This has been added to the MP protocol through multi-master initialization.

The MP protcol is simple and have the following format. [OPCODE 1 Byte, message length 2 Bytes, payload length in Bytes]. The following commands and responses are supported.

Address resolution is implemented by performing a general call. All MP devices start with address 0x11 as an initial address. Devices becomes "multi-master" and "walk-up" address space until they find an open address and claim it.

Illustration of MP device registration in an MP/SPA-1 network.

The mechanism to permit extraction of electronic datasheets (xTEDS) from a MP device is illustrated here. The host parses the xTEDS and register the device services for use by other devices and applications.

Illustration of xTEDS retrieval/interogation from MP device.

MP implements a Command ("write"), Response ("read"), and General call as a continous cycle using non-weighted round-robin, visiting all known devices and looking for new ones.

Illustration of MP network round-robin operation.