Standards-driven innovation: A perspective on SpaceVPX

Story

June 23, 2022

In pursuit of technological excellence, microelectronics developers must continuously innovate compelling solutions that enable advancement of their target applications. Identifying and defining the best purpose-built solutions demands input from multiple sources and skillsets.

While creating truly novel technology is exhilarating and, if widely adopted, will reap proportionally large gains, it is also accompanied by numerous high-risk factors. One such risk is market acceptance and adoption rate due to the unique nature of novel solutions. When a technology developer doesn’t have a single major application upon which to focus, like an iPhone, an alternative approach is required such as targeting standards. Consider the ubiquitous nature of MIL-STD-1553, which has been deployed in nearly every military aircraft and satellite since the 1970s. Investing in MIL-STD-1553 solutions over the decades would have brought returns many times over, simply by the use and adoption rate of the technology.

Reliable and highly capable interface components based on standards like MIL-STD-1553, SpaceWire (ECSS-E-ST-50-12C), RS-485 (EIA/TIA-485), and CAN Bus (ISO 11898-x), among many others, have served generational military and space systems. Although these interface components provide a strong ecosystem of solutions supporting a multitude of systems and applications, they do not, by themselves, drive the system level interface requirements. Instead, the system architectural definition determines which components are required. Broadly adopted system definitions – preferably those which are developed and ratified through an industry standardization body – can clearly highlight opportunities to innovate component-level solutions enabling effective implementation of the open system standard.

SpaceVPX (VITA 78.0) is a great open system-level standard that carries integra­tion flexibility, high-performance signal- and sensor-processing potential, and exceptional fault resiliency. Unit-level form factors include 3U and 6U with standard and extended length options and as many as 32 logic module slots. The standards group gave a lot of consideration toward defining the platform with no single-point failures in mind, so that redundancy is infused through the system. Yet, realizing all the promise of SpaceVPX depends heavily on the component ecosystem capable of fulfilling the demanding platform requirements including those unique to power supplies, utility modules (SpaceUM), chassis controllers, Serial RapidIO and SpaceWire switch cards, and ultimately payload cards.

High-level SpaceVPX overview

The SpaceVPX system is typified by redundant groups of slot cards, or modules. As shown in Figure 1, the module groupings fall into either the Primary (Side A) or Secondary (Side B). Within a module grouping, there are three module classes: power-supply modules, logic modules, and utility modules/SpaceUM. While the power-supply and utility modules serve very distinct roles within the SpaceVPX system, Logic modules span a range of purposes and can be refined into subgroups.

Payload modules represent the slot cards that perform the system application functions and will vary widely based on the program requirements. The controller module performs chassis-management functions and communicates throughout the system on the utility plane and control plane. Finally, the data switch module provides crossbar switching of the high-bandwidth data plane communication between all payload modules.

[Figure 1 | Graph shows a SpaceVPX system high-level module overview.]

Keeping in mind fault tolerance via redundancy is a staple of the SpaceVPX specification, cross-strapping control, utility, and data plane communication links are essential.

Interfaces and responsibilities within a SpaceVPX module

It might be helpful to further delve into the interfaces and responsibilities within each SpaceVPX module. Standing in the shoes of the module designer frequently illuminates problems where readily available component solutions are insufficient to effectively meet the system requirements. These capability gaps represent great opportunities to define and develop innovative component solutions that will enable more effective implementation of the SpaceVPX requirements. Let’s look at the power-supply and SpaceUM modules.

SpaceVPX system power-supply units (PSUs) receive external power from the satellite power bus or other specific architecture-defined voltage domain. Each power supply is responsible for generating up to seven voltage rails: +12 V/VS1, +12 V/AUX, +3.3 V/VS2, +3.3 V/AUX, +5 V/VS3, -12 V/AUX, and VBAT.

While there are not many major blocks in the power supply, the complexity is in the details, particularly when considering the limited availability of radiation-hardened (rad-hard), space-qualified, high-power-density, isolated converters capable of delivering >100 W with high efficiency. If, as is typical, the average efficiency of the 500 W supply is 85%, the module will need to thermally dissipate 75 W. That is no easy feat; especially in a 3U form factor module operating in the vacuum of space.

Advanced packaging capabilities and increasing availability of better technologies like gallium nitride (GaN) mean improved parts; further, when more rail wattage is required, the GaN converters can also be placed in parallel.

An additional untapped area of potential innovation within the power supply is integration of “smart” functions enabled through incorporation of power management bus (PMBus). PMBus provides many useful, converter-oriented, functions capable of dynamically adjusting regulator parameters such as output voltage, current limits, switching frequencies, and ramp rates to name a few. Furthermore, PMBus offers a rich set of fault detection and response controls as well as numerous status and telemetry features.

Communicating over an I²C physical layer – which is already a common physical layer within SpaceVPX by virtue of the intelligent platform management bus (IPMB) used on the utility plane – PMBus affords the power-supply designer to add a small, low power, host controller to configure, control, and gather housekeeping information from PMBus-enabled converters while reporting all relevant information back to the SpaceVPX chassis controller over utility plane. Although host controller solutions are available, no space-qualified DC/DC converter is presently offered with PMBus capability, representing a prime opportunity to innovate.

Disassembling the SpaceVPX SpaceUM

The SpaceUM is perhaps the most challenging module within the SpaceVPX system to design because of its vast responsibilities that must be handled with limited availability of miniaturized, purpose-built, radiation-hardened components. Some of the primary tasks levied upon the SpaceUM include

1. Muxing all primary/redundant power rails to each logic module (max eight modules per SpaceUM)
2. Routing IPMB communications between the selected side A/B chassis controller and fanning them out in a “star topology” to each logic module
3. Repeating and fanning out system reset, reference, and auxiliary clocks to each logic module

Figure 2, a simplified high-level diagram of the SpaceUM module, depicts the two independent system controllers and a single block representing the redundant power supplies feeding utility plane signals and all six duplicate power rails to the SpaceUM card, respectively. The SpaceUM replicates all of its inputs to each SpaceVPX logic/payload slot – up to eight slots per SpaceUM card. For simplicity, the diagram only shows signals and power going to a single logic/payload slot card. A sideband set of selection signals are used by the SpaceUM card to select which system controller and power supply it will pass through to the backplane.

[Figure 2 | A high-level block diagram shows the layout of the SpaceUM module.]

From a component supplier viewpoint, there are a number of interesting functions to serve. Starting with the chassis controller fanout block, the three utility plane signal sets appear fairly simple. At closer inspection, the quantity of signals required for fanout can become I/O-intensive. For example, the IMPB includes four I²C signals per slot. With as many as eight logic/payload slots plus the system controller, the fanout device requires 36 I2C-capable I/O, which quickly outstrips the resources available on all space-qualified microcontrollers. Additionally, the fanout device needs the ability to manage I²C protocol flow control between the system controller and targeted logic/payload slot cards. While the commercial/terrestrial microelectronics solutions include I²C fanout devices, the same cannot be said for rad-hard solutions.

After the utility plane signals have been buffered and fanned out, each side A/B signal grouping must be multiplexed to the plug-in modules through the backplane interface. The IPMI interface is particularly tricky because the I²C signal characteristics must be retained with bidirectional capability. Unfortunately, the space industry is not presently supported with a true I²C router or multiplexor. Yet, the problem may be solved with transmission gate bus switches. The ideal solution would be transmission gate (T-gate) multiplexors, which don’t presently exist in space-qualified formats either, but there are space assured single-pole/single-throw bus switches that can be configured to serve the multiplexing function.

By selecting appropriate channels on the bus switching device, single-pole, single-throw bus switches can be used in a multiplexing configuration. Due to the low series impedance (5 ohms typical) of transmission gates, they offer very fast propagation delay with a high degree of input-to-output signal characteristic matching and natural bidirectional signal transfer.

The next utility plane challenge is routing four differential clock domains to the plug-in modules. The side A and B system controllers provide a differential system clock, auxiliary clock, and two reference clocks. The SpaceUM modules must receive these clocks and fan them out to each plug-in module using a clock-management device.

The last major responsibility of the SpaceUM modules is switching a plethora of power rails to the plug-in modules, or “power-muxing.” Switching a single power rail to a given load is rather simple and straightforward. All that is required is a shunted power MOSFET [metal-oxide-semiconductor field-effect transistor] and gate driver. However, SpaceVPX demands much more.

Power muxing requires reverse current blocking on each redundant power rail, which is generally addressed with a second series shunted ideal diode FET (increasing reliability or power) to block current flowing from the selected supply through the load switch and back into the nonselected power supply. Further, the muxing action requires a selection switch on each rail to connect the commanded supply to the desired payload slot. All combined, a power mux requires up to four power switches and a gate driver/controller for each switch.

Additional considerations affecting the power switching portion of the SpaceUM module include fault detection, isolation and recovery (FDIR); inrush current limiting; current monitoring; and (if desired) housekeeping information on each switched power rail. Depending upon the current class allocated to each plug-in module, the conductive voltage drops through the switching action can create very difficult design constraints toward meeting the regulated voltage tolerance on each load as well. This is particularly challenging on the 3.3 V and 5 V domains where voltage tolerance is more stringent and current demands are generally higher than what is allocated on the 12 V supply rails.

The space industry offers a fairly broad spectrum of 3.3 V and 5 V power-switch solutions and a slightly narrower range of 12 V switching components. There are no -12 V switch solutions available, leaving it to SpaceUM designers to develop their own discrete -12 V power muxing circuitry.

Focusing on the space-assured power-switching solutions, the designer has several differentiating factors to trade. On the 3.3 V and 5 V rails, some solutions integrate the switching FETs within the controller itself, which favors smaller implementation footprints, but is often current-limited to <10 amps. If the plug-in module is specified for higher current, these devices need to be paralleled up. An additional consideration is fault protection and housekeeping (telemetry) requirements, which are somewhat limited or nonexistent on most of the components.

Alternatively, using devices like the UT05PFD103 (5 V rail) and UT36PFD103 (12 V rail) smart power-switch controllers (SPSCs) empowers the designer with current class agnosticism, extensive FDIR capability as well as integrated voltage and current monitoring telemetry (Figure 3). Using the PMBus interface on the SPSC, the SpaceUM chassis controller fanout-management component can leverage a single I2C port to directly configure, command, control, and gather extensive status and telemetry from every power rail controlled by the SPSCs.

[Figure 3 | Smart power-switch controllers enable an agnostic stance on current class, extensive FDIR capability, and integrated telemetry for integrated voltage and current monitoring.]

Still, the perfect SpaceVPX power-switching solution does not exist today. Retaining the manifold advanced features of the SPSCs with embedded power switches supporting >20 amps of current delivery would be a great move toward miniaturizing the SpaceUM power-switching functions. Moreover, adding the power MUX function within a single controller could cut the footprint overhead per switched rail in half. For low-voltage, high-current, power rails the conductive voltage drops must be minimized, which begs for n-channel or GaN power switches for these rails. Finally, a -12 V power-switching solution is an imperative to round out the full SpaceVPX power muxing requirements.

Walk a mile in the designer’s shoes

SpaceVPX promises a powerfully flexible, scalable, and fault-resilient platform enabling the highest degree of compute and sensor processing in an open, plug-in module, oriented system. Delivering on the potential benefits offered by SpaceVPX requires an extensive ecosystem of advanced space-assured components. The space-industry supplier base has innovated many purpose-built solutions to enable successful SpaceVPX implementations, yet more technology innovation is needed to see SpaceVPX realize its full potential.

By standing in the SpaceVPX designer’s shoes, component suppliers can quickly learn where the limitations lie. The extent to which component suppliers invest in SpaceVPX-enabling technologies will in turn facilitate more SpaceVPX deployments, resulting in a win-win proposition for both the component suppliers and the system integrators, ultimately providing programs with a flexible, reliable, and scalable platform to implement advanced sensor, artificial intelligence (AI), and computationally intensive applications more quickly and cost-effectively.

Tim Meade serves as a systems design engineer for the CAES Space Systems Division. During his more than 20 years at CAES, Tim has held space semiconductor marketing and development positions in the areas of applications engineering, application engineering management, product management, and systems architectural design. He played an integral role in growing the company’s semiconductor and system solutions footprint beginning with development of CAES’ first space-qualified embedded controller circuit cards, which have deployed on FalconSat-1, CNOF/S, and the International Space Station. Tim studied at the University of Colorado at Colorado Springs where he earned a BS in electrical engineering and an MBA in technology management. Readers may email the author at [email protected].

CAES • https://caes.com/