Minimize QuadSat


The U.S. Air Force Research Laboratory’s Space Vehicle Directorate (AFRL/RV, Kirtland AFB, NM) has developed technologies to support the rapid development of complex systems (spacecraft in particular) with modular components using plug-and-play (PnP) semantics. The associated series of standards encapsulate both electrical and software protocols and is referred to as SPA (Space Plug-and-Play Avionics). The principles of SPA are scale invariant, meaning they accommodate large satellites and 1U CubeSats equally well. 1)

The governments of the U.S. and Sweden have engaged in bi-lateral harmonization of Plug-and-Play technology and advanced MEMS (Micro-Electro-Mechanical System) miniaturization techniques through a project agreement signed between AFRL and FMV (Swedish Defence Materiel Administration) of Stockholm. The international collaboration is referred to as NAPA (Nanosatellite And Pnp Architecture), the agreement was signed in August 2009. The primary objectives of the program are: 2) 3)

• Harmonize plug-and-play approaches of the two nations

• Establish joint testbeds for exchange of PnP components

• Demonstrate interchangeability between testbeds.

ÅAC Microtec of Uppsala, a Swedish company focusing on robust and miniaturized electronics, MEMS and rapid response technologies, is supporting FMV as the Swedish industry partner - after receiving a contract from SNSB (Swedish National Space Board). The joint development targets possible applications on both nanosatellites and fighter aircraft.

The agreement between AFRL and FMV was signed in August 2009. The 1st order under the contract is to conduct a study and demonstration phase to support the development of the advanced PNP satellite architecture. A subsequent task order is anticipated to include the development of a PNP nanosatellite demonstration bus - referred to as QuadSat-PnP. ÅAC (Ångström Aerospace Corporation) is a spin-off company of ÅSTC (Ångström Space Technology Center) at Uppsala University, Sweden (since 2005). In November 2008, the company changed name to ÅAC Microtec. 4)

A productive collaboration started in which the SPA concept was enriched and expanded through the introduction of a new interface. A commercial technology, referred to simply as MP (Mini-PnP) has been defined as a protocol on the popular I2C (Inter-Integrated Circuit) standard. The space versions of MP, referred to as “SPA-1”, implements a minimalist form of SPA that is vastly more efficient than previous SPA technologies, making it ideal for use in nanosatellites.



AFRL and FMV are jointly performing harmonization and development of Plug-and-Play technology. The Swedish industry partner, ÅAC Microtec, has independently developed a miniaturized PnP packaging technology using advanced MEMS techniques and defined a CSA (Common Scalable Architecture) for RTU (Remote Terminal Units), which is a European term for a standard remote interface. AFRL’s SPA standard uses ASIMs (Appliqué Sensor Interface Modules) which are the equivalent of RTU’s.

Leveraging the most promising work of both nations, an exciting new generic and lightweight PnP technology has been developed for small, low-power components. The generic form of this technology, referred to as MP (Mini-PnP), is readily adapted to a great variety of terrestrial and space applications. A four-pin version (MP4) is based on the popular I2C bus technology, and a two-pin protocol-identical version (MP2) employs a novel data-on-power transceiver to further simplify the physical connection. The space-optimized form, referred to as “SPA-1”, is designed to be SPA compatible, and it is in fact interoperable with other previously developed SPA technologies through a simple gateway.

Since software I2C interfaces can be easily formed in virtually any processor or FPGA, it is possible to quickly adapt many existing components to be MP/SPA-1 compatible. MP and SPA-1 complement the CSA (Common Scalable Architecture) of ÅAC, and these ideas will be tested on AFRL CubeFlow kits. ÅAC’s CSA allows simple transition to SASIC (Structured Application Specific Integrated Circuits) for radhard SPA-1 implementations.

For the last couple of years, AFRL and FMV have been interested in combating the uncertainty and complexity of spacecraft architecture through plug-and-play approaches. Each group has undertaken research programs to study how to make components that can be effectively used across the widest variety of spacecraft designs. In the US, the concept of “responsive space” appeals to the idea of using technology to make it possible to build systems much quicker. One of the approaches created was a concept referred to as space plug-and-play avionics (SPA).

In Sweden, concepts of plug-and-play nanosatellites also began to evolve. In both case, the plug-and-play architectures addressed very powerful conventions that order the meaning of the information contained in interfaces. These conventions are not enforced by humans for the most part, but through silicon and electronic descriptions that can be organized to form systems quickly and effectively. The mutual interest led to the creation of an international program through which AFRL and FMV would harmonize these conventions of PnP. 5)


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 spacecraft (busses and payloads). The SPA standards combine different data transport standards. 6)

In the parlance of “SPA”, a SPA-x interface refers to a connector that would be found on a SPA device allowing the device to join a plug-and-play (SPA) network. The suffix letter refers to a class of interface, driven usually by bandwidth. 7) 8) 9)

• USB (Universal Serial Bus): SPA-U. This was he first SPA interface technology developed. This was because USB already embodied the essential features of plug-and-play (in the personal computer), and the other interface approaches largely did not exhibit plug-and-play characteristics. The data transport (of USB 1.1) is limited to 12 Mbit/s for the entire bus.

• SpaceWire: SPA-S (low voltage (5V) SpaceWire). SPA-S is based on the European SpaceWire standard, building upon the knowledge gained in SPA-U to add the needed plug-and-play protocols. Data rates/link of 400~600 Mbit/s can be supported.

• Optical: SPA-10, also known as SPA-O. SPA-10 is an optical fiber interconnection --in the definition/experimentation phase as of 2010. SPA-O extends the limited transport bandwidth of copper-based transports through the addition of an optical transport system consisting of a number of single- or multi-mode fibers (e.g., twelve) with an industry standard connector (e.g., "MT"). To simplify the ability to accommodate arbitrary wavelengths and protocols, SPA-S is retained in SPA-O as a control plane (as well as electrical power and synchronization signals), allowing for the structured and automated provisioning for a network of SPA-O components.

• I2C: SPA-1. SPA-1 has been commissioned to improve the efficiency of SPA for extremely simple devices.


Figure 1: Overview of some SPA domains (image credit: AFRL)

SPA, as a research program, attempts to tackle complexity through intelligent component and software strategies very similar to those used in commercial systems, but focused on embedded, fault-tolerant platforms. SPA was created primarily in response to the integration barriers caused by disparities in component interfaces. Spacecraft, as a class of complex system, necessarily involves the eventual convergence of many hardware and software components developed by different groups at different places and times. 10)

In space systems, an often exaggerated emphasis is placed on the use of “legacy” components, which are believed “safe” choices because they have been shown to work successful in some previously flown system. Legacy components, though an attractive proposition, do not always involve the same electrical interfaces. Components with such hardware differences, such as the case when a component with a MIL-STD-1553 interface needs to be connected to another component with a RS-422 interface, represent the most obvious form of disconnect, which is resolved by either reprocuring a component with an altered interface (which “destroys” the legacy benefit to some degree) or engineering a glue of hardware and software to bridge the dissimilar components. Software differences seem more subtle, such as the case when two RS-422 components are connected, but cannot work together due to differences in the ad hoc protocols of command and data handling. Once again, the disconnects are resolved through custom engineering, which seems tenable since “it is only software”. On the scale of two components, resolving such disparities can be quite involved, but on the scale of an entire spacecraft, in which many such components must be unified into a coherent whole, it can be more than challenging. It is at one level no wonder that a large spacecraft can experience significant overruns.

In SPA, the attempt is to tackle the hidden layers of complexity underlying complex systems through a set of coping strategies, ranging from standard electrical interfaces and software protocols to self-organization mechanisms that dramatically reduce the need for custom engineering bridges between disparate components. Random arrangements of RS-422 components will likely never work without extensive engineering, but a collection of SPA components could be swiftly aggregated into a network that would self-organize in a way that can be clearly accessed through software of a compatible design (i.e., SPA-aware). Components “serve” their own descriptions to systems, using electronic datasheets. Many components have single connections, a SPA interface containing power, data, command, and timing connections. The overarching attempt is to create a constrained universe with SPA in which hardware and software elements can be freely composed to form systems of nearly arbitrary sophistication with minimal burdens on the humans who must build those systems.

SPA can be divided into two sets of technologies, the first being SPA interfaces and the second being SPA software. SPA interfaces attempt to provide a simple modularity approach for spacecraft components, as depicted in Figure 2, which suggests a correlation between the plug-and-play models used in personal computer and “SPA-enabled” spacecraft.

In the case of the personal computer (PC), a host “platform” can support the addition of a number of ordinary components, such as mice, keyboards, and thumbdrives, using a single (USB) interface. The single interface supports power distribution, command, and data handling. Components in the PC “plug-and-play” through a process that supports the automatic enumeration of components and a brokering mechanism that seeks to match pre-written software drivers to devices. Within the component, an interface chip exists that on one “side” provides a compliant implementation of the USB standard3 and on the other “side” provides a convenient breakout interface. Individual device developers mate their custom components to this breakout interface and physically wrapper the device, resulting in a very simple presentation of a modular component to a user.


Figure 2: Analogy between personal computer and spacecraft based on plug-and-play principles (image credit: Microcosm Team)

In the SPA analogy (right half of Figure 2), the spacecraft (as a platform) supports the addition of modular components, which are automatically recognized when connected to the spacecraft. The recognition is possible by encapsulating the component with an ASIM (Appliqué Sensor Interface Module), which plays a role similar to the USB interface “chip” in a mouse or keyboard. The ASIM contains an internal microcontroller, state machines, and memory and is intended to provide a convenient breakout interface to the “raw” custom circuitry of typical spacecraft components. When “wrapped” with an ASIM, a spacecraft component is referred to as a SPA component. All SPA components are self-describing through an electronic datasheet contained in the ASIM. The electronic datasheets in SPA are called xTEDS (extended Transducer Electronic Datasheets). The xTEDS is a powerful abstraction for a driverless form of plug-and-play, intended to provide some insularity from operating systems, since there are not dominant standards for aerospace. The xTEDS can be thought of as a “service description” for components, and in fact, functions not detailed in the xTEDS are effectively invisible to SPA.

While SPA interfaces simplify the mechanisms for defining and networking PnP devices, a specialized software infrastructure is at the heart of the SPA concept. The fundamental software system is called the SDM (Satellite Data Model). SDM is a set of software components that provide a unified plug-and-play mechanism for “discovery and join”, which involves registering components and services and implementing a “look-up service”, which allows the producers and providers of these services to be located by software components that need them through schema queries (improved regular expression support has been recently added). SDM is comprised of four modules. The data manager implements the “registry” and look-up service functionality. Other SDM modules include the task manager, network manager, and processor manager. The SDM architecture is intended for distributed implementation, meaning that components can be dispersed throughout a network of processors within a SPA system. The data manager is the most important module, and while multiple copies may exist within a network, a single copy is active at any instant (other copies can be rapidly and automatically activated with an intrinsic dynamic mastering protocol).


No of pins






Test bypass



SpaceWire (8-pin LVDS)


28 V (2-pin) @4.5 A


RS-422 (2-pin)




USB (4-pin)


5 V (2-pin)* @ 4.5 A


RS-422 (2-pin)




I2C (2-pin)


5 V (2-pin)* @ 2 A

Use 5 V return




25 (12 fibers)

12-fiber optic cable


part of SPA-S with 30 A max

Part of SPA-S

Part of SPA-S


Table 1: Summary of SPA interfaces (Ref. 3)

Each of the standards features a component¿transparent publish/subscribe software infrastructure, called the SDM (Satellite Data Model), on which software for command, control, data collection, processing, and analysis can be implemented.

An electronic data sheet, called xTEDS (extensible Transducer Electronic Data Sheet), is stored within 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 the above given standardized elements, a PnP (Plug-and Play) satellite can be designed and assembled from off¿the¿shelf, SPA-ready components. These SPA components form a simple, but expressive “universe” of building blocks that can occur in several forms as shown in Figure 3. Most spacecraft components in a SPA system would be normal SPA devices, as shown in Figure 3a.


Figure 3: Illustration of various SPA components (image credit: AFRL)

Internally, the component contains a raw device, which could be reaction wheel, thermometer, camera, basically any traditional component of a spacecraft (even a structural panel). To be “SPA ready”, the device is “wrapped” using an RTU, which launders a custom device into a uniform SPA interface. The RTU handles the device by supplying its power and native command structure, while presenting an electronic description with an electronic datasheet embedded within the RTU.

The second type of SPA device, a SPA command and data handling (C&DH) computer (Figure 3b), runs a SPA network. The SPA C&DH runs SDM, which manages the discovery and brokering of services, commands, and data between SPA components.

The third type of SPA device is a SPA switch/router/hub (Figure 3c), which facilitates the extension of SPA networks into larger networks.

Finally, a fourth type of SPA device, the bridge (Figure 3d), operates as an adapter between two different SPA performance tiers. For example, a bridge can connect SPA-U devices into a SPA-S network.


MP (Mini PnP) standard:

MP refers to networks of very simple devices based I2C/SMBus (System Management Bus) standard. MP is intended to support very compact / low-power self-describing devices that can be automatically discovered and registered into a MP network. MP hosts can be implemented on a wide variety of targets, from simple microcontrollers to complex data handling processors.

MP is supported in two different “protocol-identical” interface options:

- A four-wire version of MP (MP4) implements the physical layer of I2C (SMBus. Though I2C is considered to be a “two-wire standard” (being clock, or “SCL”, and data, or “SDA”) all I2C devices must in fact have four pins in order to supply power.

- A two-wire version of MP (MP2) implements the I2C (SMBus protocols over the power pins through an innovative AC modulation scheme, providing the true two-pin interface standard.

The two interfaces are not mutually exclusive within a system or even the same MP network, as adapters can be used to convert MP4 into MP2 and vice versa.


The ideas of SPA for nanosatellites have been demonstrated in teaching configurations based on the adaptation of CubeSats to accommodate SPA-like modularity, which is referred to as CubeFlow. These configurations are useful for studying SPA firsthand, and Sweden is exploring distribution of CubeFlow in Europe. More ambitiously, the ideas of SPA are being mapped into entire functional spacecraft. The first of these is referred to as QuadSat-PnP-1.


QSP-1 (QuadSat-PnP-1)

QSP-1 is a nanosatellite project funded by the US/Swedish collaboration project. In parallel with the collaboration, ÅAC Microtec of Uppsala in Sweden received a contract from the SNSB (Swedish National Space Board - known as Rymdstyrelsen) to develop and space qualify a set of miniaturized power conversion components (Ref. 3). 11)

The guiding principles for the QuadSat-PnP-1 system architecture is the use of the SPA (Space PnP Avionics) standard based on the ÅAC “SPAready” avionics building blocks and innovative designs, including use of screened commercial components. All SPAready devices feature radiation tolerant architectures and components, while add-ons and payloads are protected using LCLs (Latch-up Current Limiters), allowing these parts to be of lower grade, i.e., commercial components.

ÅAC Microtec examined a more aggressive possibility, that of building a full-fledged SPA-based satellite. Hence, QSP-1 became an idealized embodiment for both functionally demonstrating these DC/DC power converters, as well as a platform for demonstrating space qualification.

The QuadSat concept was developed by the University of Applied Sciences in Bremen, Germany, in collaboration with OHB System's subsidiary LuxSpace (Luxembourg) to offer a low cost standard and versatile platform for nano- and microsatellites ranging between 5 kg to 25 kg. QuadSat’s are typical modern satellites with modular and scalable parts which can easily be transformed into different shapes and missions. It draws its influences from nanoSPA/Cubeflow, Uppsala University/Ångström Space Technology Centre (ÅSTC's) NanoSpace concept, and ESA's (European Space Agency) NanoSat CDF (Concurrent Design Facility) study.


Figure 4: Illustration of the QuadSat-PnP-1 nanosatellite design (image credit: QSP-1 consortium, Ref. 3)

Legend to Figure 4: (a) is a depiction of the nanosatellite with the solar panels deployed; (b) is a depiction of the nanosatellite without the solar panels, showing the “pizza box” tray style construction.

The QSP-1 spacecraft features include the following components:

• Sun sensors

• Magnetometer

• IMU (Inertial Measurement Unit)

• Magnetorquers

• S-band transmitter

• UHF receiver

• 2 x satellite communication links

• Camera

• Redundant OBC

• AIS receiver

• PnP Distributed Power Control Unit (DPCU-U and DPCU-1)

• PnP Main Power Distribution Unit (MPDU)

• Miniaturized (MEMS) Point-of-Loads

• PnP TDRS (Tracking and Data Relay Satellite) software defined radio modem

• PnP INS (Inertial Navigation System).

The architecture of the QSP-1 is based on that used in the highly successful Rubin nanosatellites developed by OHB System AG (Bremen, Germany). It is powered by fixed solar arrays (Figure 4a) mounted around the body of the spacecraft, which is formed from a stack of “pizza box”-like trays (Figure 4b). This modular construction is very advantageous to the geographically disperse design teams involving participation from Germany, Sweden, and the US.

QSP-1 features a “4-tray” architecture:

The trays are built from aluminum, nominally sealed with the satellite payload and bus components, except for connectors on the sidewalls as shown in Figure 5.


Figure 5: QSP-1 tray construction. (a) Unpopulated tray; (b) spacecraft architecture based on 4-tray configuration (image credit: QSP-1 consortium)

The tray organization includes:

1) A power tray, which contains satellite electrical power subsystem, battery array, as well as the two UHF transceivers and the Iridium transceiver

2) A payload tray containing a number of AIS receivers

3) An interface / launch vehicle interface tray, which contains additional bus guidance components, OHDB (On Board Data Handling) computer and an Orbcomm transceiver

4) A SPA-based payload tray containing a number of miniaturized power conversion components, SPA interface modules, and the TDRS transponder.

The QuadSat-PnP-1 avionics block diagram is illustrated in Figure 6, including the power hierarchy. SPA-1 network uses +5 V and maximum 1 A per port while SPA-U uses +5 V and maximum 3 A per port. The MPDU (Main Power Distribution Unit) operates with a main power bus at 12 V. The architecture is planned to be single string and does not comprise redundancy except for the main power distribution unit.


Figure 6: Block diagram of the QuadSat-PnP-1 avionics (image credit: QSP-1 consortium, Ref. 5)

PnP payload tray:

The QSP-1 involves a mixture of SPA-1 and SPA-U technologies. The logical organization of the architecture in the PnP payload tray is reflected in the Figure 7 block diagram. The PnP experiments predominately focus on the testing of a number of power control blocks, power converters, latchup current limiters, and the interface modules (RTUs) that themselves implement the SPA functions, along with a number of simple payloads that demonstrate the ability to interface with SPA and perform simple orbiting experiments.


Figure 7: Illustration of the QuadSat-PnP-1 electrical architecture (image credit: QSP-1 consortium)


Figure 8: Physical arrangement of the PnP components in the PnP tray (image credit: QSP-1 consortium)

Legend to Figure 8: (1) TDRS software-definable radio (SDR modem with SPA-U interface. (2) MPDU (Main Power Distribution Unit). (3) Distributed Power Control Unit (DPCU)-1 with four SPA-1 ports. (4) IMU (Inertial Measurement Unit) SPA-U node with DRTU interface. (5) DPCU-U with four SPA-U ports. (6) Miniaturized rad-hard point of load SPA-1 node with nano RTU interface. (7) Nano-RTU.

The primary power distribution in the tray is handled by the MPDU (Figure 9), which receives primary power as input from another tray in the satellite containing the primary satellite power batteries and connections to the solar arrays. The MPDU performs the role locally of an EPS (Electrical Power Subsystem), providing uninterruptible power to the RTU-Lite (which operates as the central computer for the PnP system) and meters power to all other sections of the tray. From the standpoint of SPA, the MPDU is the top of the QSP-1 power hierarchy. It meters out power to other SPA devices, in a standard way. It also supports configurable, auxiliary power which can be set up programmably, for example through xTEDS specification.


Figure 9: Illustration of the QuadSat-PnP power hierarchy which is compliant with SPA and automatically detects and installs power protection and power distribution using xTEDS (image credit: QSP-1 consortium)

The MPDU is therefore always powering the RTU-Lite “brain”, which in turn provides commands to turn on other parts of the power hierarchy through the MPDU. Below the MPDU, hierarchically, are a number of regional power brokering modules, referred to as DPCUs (Distributed Power Control Units). The DPCUs are capable of supporting several SPA devices, and are specialized according to the type of SPA interfaces. There are DPCUs, for example, specific to SPA-U devices (DPCU-U) and some specific to SPA-1 devices (DPCU-1) This hierarchical approach is very attractive in that it is power to scale (separately) the top-level module (MPDU), which can be sized to accommodate different satellite bus classes, as well as the DPCUs, which can be added in an a la carte fashion to accommodate the number of SPA components are needed to create a system.

QuadSat-PnP will be a low-cost, high performance microsatellite for technology demonstrations and future science missions. Based on ÅAC’s highly miniaturized avionic and power components, QuadSat-PnP-1 will be the first nanosatellite in the world featuring flexible support for MNT (Micro/Nano Technology) derived platform subsystems and payloads. The QuadSat concept has been developed to offer a low cost standard and versatile platform for nano- and microsatellites ranging between 5 kg to 25 kg. 12)

The QuadSat-PnP-1 spacecraft has a mass of ~ 15 kg, a size of 25 cm x 25 cm x 20 cm, providing power of ~ 15 W. 13) 14)


Launch: A launch of QuadSat-PnP-1 is planned on a PSLV launcher of ISRO in 2012.

Orbit: Sun-synchronous orbit, altitude = ~ 700 km, inclination = 98.2º, period ~ 99 minutes.


The mission phases for QuadSat-PnP-1 consist mainly of five active phases:

• Phase 1, Safe Mode, System commissioning: Establish communication over intersatellite communication links and download basic housekeeping information.

• Phase 2, SPA Mode: Perform check out of distributed avionics architecture and SPA integrity (initiate SPA OBC/RTU (Linux) control of spacecraft). Establish communication over S-band or VHF (fast telemetry downlink). Download separation images and SPA telemetry.

• Phase 3, Payload checkout mode, perform check out of all payloads.

• Phase 4, Nominal Mode, Run payload and download data over time. In parallel to Phase 4, an optional experimental phase 5 will be conducted.

• Phase 5, Nominal Mode with commanding (take pictures, upload and retransmit (relay) data packets for testing, TBD).


Sensor complement:

A description of the sensor complement will be provided when available.

1) Fredrik C. Bruhn, Robert Lindegren, James Lyke, Benjamin Hendersson, Josette Rosengren-Calixte, Rickard Nordenberg, “International Harmonization of Plug-and-Play Technology for Modular and Reconfigurable Rapid Response Nanosatellites,” Proceedings of the Symposium on Small Satellite Systems and Services (4S), Funchal, Madeira, Portugal, May 31-June 4, 2010

2) James Lyke, Josette Calixte-Rosengren, “Overview of the Nanosatellite And Plug-and-play Architecture (NAPA) Project Agreement,” Plug-and-Play: Making the Complex Simple through Architecture, NSO (Netherlands Space Office) PnP roundtable meeting, Sept. 17, 2010, URL:

3) Fredrik C. Bruhn, Per Selin, Indulis Kalnins, James C. Lyke, Josette Rosengren-Calixte, Rickard Nordenberg, “QuadSat/PnP: A Space-Plug-and-play Architecture (SPA) Compliant Nanosatellite,” Infotech@Aerospace 2011, St. Louis, Missouri, USA, March 29-31, 2011, paper: AIAA 2011-1575, URL:


5) James Lyke, Jesse Mee, Fredrik Bruhn, Gael Chosson, Robert Lindegren, Henrik Lofgren, Jan Schulte, Scott Cannon, Jacob Christensen, Bryan Hansen, Robert Vick, Alonzo Vera, Josette Calixte-Rosengren, “A Plug-and-play Approach Based on the I2C Standard,” Proceedings of the 24th Annual AIAA/USU Conference on Small Satellites, Logan, UT, USA, Aug. 9-12, 2010, paper: SSC10-VII-7, URL:

6) Jim Lyke,, Don Fronterhouse, Scott Cannon, Denise Lanza, Wheaton Byers, “Space Plug-and Play Avionics,” AIAA 3rd Responsive Space Conference, April 25–28, 2005, Los Angeles, CA, USA, paper: RS3-2005-5001, URL:

7) Keith Avery, Nathaniel (Shane) Francis, James Lyke, Patrick Collier, “Optical Networking for Aerospace Systems Provisioned through Plug-and-play Avionics,” Proceedings of the 24th Annual AIAA/USU Conference on Small Satellites, Logan, UT, USA, Aug. 9-12, 2010, SSC10-XI-9

8) Louis Marketos, “Leveraging the Space Plug-and-Play Avionics (SPA) Standard to Enable Constellation-Level Collaborative Autonomy,” URL:


10) L. J. Hansen, P. Graven, D. Fogle, J. Lyke, “The Feasibility of Applying Plug-and-Play Concepts to Spacecraft Guidance, Navigation, and Control Systems to meet the Challenges of Future Response Missions,” 7th International ESA Conference on Guidance, Navigation & Control Systems 2-5 June 2008, Tralee, County Kerry, Ireland, URL:


12) “ÅAC Microtec satellite project creates new opportunities for testing of innovations and new space science,” April 27, 2010, URL:

13) Craig Kief, Steve Suddarth, “CubeFlow, SPA and the revolution of small satellites,” Proceedings of the CalPoly 2010 CubeSat Developer's Workshop, San Luis Obispo, CA, USA, April 21-23, 2010, URL:

14) Christopher McNutt, James Lyke, “CubeFlow: A Modular Open Systems Architecture for CubeSats,” Proceedings of the 7th Responsive Space Conference, April 27-29, 2009, Los Angeles, CA, USA, paper: RS7-2009-4003

The information compiled and edited in this article was provided by Herbert J. Kramer from his documentation of: ”Observation of the Earth and Its Environment: Survey of Missions and Sensors” (Springer Verlag) as well as many other sources after the publication of the 4th edition in 2002. - Comments and corrections to this article are always welcome for further updates.