Is space in the future for VNX?
What is the problem with simply using legacy space electronics?
Why would anyone want to try to use commercial off-the-shelf (COTS) hardware for a space electronics application? Everybody knows that legacy space systems are point solutions, designed for a one-off mission funded by a big checkbook and a pen able to write lots of zeroes. Reuse has never been a priority. All the interfaces are proprietary and application-specific. Modules are not designed to be either hardware- or software-interoperable. Large space systems are complicated and expensive. The market is small and captive to a handful of relatively large integrators. Why would anyone want to invest valuable resources to develop a technology that can be only narrowly applied?
These are all seemingly good arguments, except for the fact that they are not completely accurate anymore. Enter CubeSats, SmallSats, MicroSats, and other cute little satellites that hitchhike to space in leftover real estate on delivery vehicles that drop them off into a low earth orbit (LEO). Obviously, that is a bit oversimplified, but there is a growing market for low-cost satellites that are intended to do common or mundane tasks that are indeed suitable for a COTS solution. Figure 1 shows a group of CubeSats being prepared for launch.
VNX SWaP profile well-suited for space
With the VNX (VITA-74) specification in its final year of trial usage before becoming an ANSI specification, there are several “dot specs” that have been proposed by interested users and integrators to further expand the usage base for VITA-74.0 technology. One such proposal is to create an analog of the VITA-78 SpaceVPX specification, except in a small form factor. Let us review what makes VNX a good candidate for SpaceVNX, what some of the additional requirements are needed to achieve the goal, and how the technology might be used for conventional terrestrial applications as well.
VNX extends the VPX bus technology into a smaller form factor by defining two module sizes. The length and width are the same but differ in depth (or “pitch”). The two depths are defined as 12.5 mm and 19 mm. The 12.5 mm module utilizes a 200-pin connector and can currently dissipate as much as 15 W. The 19 mm module utilizes a 400-pin connector and has been shown to be able to dissipate as much as 30 W. VNX modules are designed to be inherently conduction-cooled and quite rugged. VNX-based systems are also substantially smaller and less expensive than 3U or 6U VPX systems. The size, weight and power (SWaP) proposition make VNX an ideal candidate for LEO applications where payload delivery cost is directly related to SWaP. The delivery cost sometimes dwarfs the equipment cost, so every gram is money.
LEO applications, depending upon the actual application type, do not require the same level of radiation hardening as is mandated for equipment in the much harsher environments found in higher earth orbits. This requirement greatly simplifies adoption of COTS hardware into this type of application. At the same time, system reliability is absolutely required, as there are no service calls in space. Therefore, the addition of redundancy requirements and elimination of single points of failure will be prominent in the technical committee’s deliberations. A number of interested companies have already joined the effort, as well as the Air Force Research Laboratory.
Likely issues the committee will address
VITA 74.0 specifically defines the module dimensions, connectors, and pin-out structure. SpaceVNX will explore the system-level implementation of these modules to create mission computers with reliability suitable for space. As seen in SpaceVPX, a set of backplanes must be defined in order to facilitate redundant compute operations. Topologies for this requirement would either be a mesh data backplane providing redundant data paths to duplicate computers or a switched star/redundant star backplane that provides a similar capability. Other architectures, such as a self-healing ring topology, will be studied.
A typical SpaceVNX system will also require redundant system controllers and control switch modules. Since VNX was derived from VPX, the definitions for these functions should convert in a straightforward manner.
Slot and module profile definitions were not a part of VITA 74.0 base specification, but will likely be a large part of the SpaceVNX committee work.
SpaceVNX use cases
Obvious use cases for SpaceVNX include single standalone 1U CubeSat satellites requiring high performance data collection and analysis at a lower cost. A larger variant with networked high-performance computers with a scalable data-collection and processing capability is possible by expanding the card cage to a 1.5U or 2U configuration. The small satellites may also be used as a disaggregated cluster of networked satellites designed for a variety of data collection and analysis applications with a single sensor. The next step would be to use the same network of LEO satellites with multiple sensors, where the networked cluster fuses the data from all active sensors. Figure 2 shows an example of an existing rugged VNX system.
Adaptation of VNX for space use
Since VNX is a module standard, the package that holds and buses the modules together can be in whatever size and shape it needs to be in. The resemblance between a 1U CubeSat and the VNX Reference Chassis is remarkable. All the technology is available in other specifications just waiting to be integrated into a nice tidy package that looks like it can be utilized to save size, weight, power, and cost (SWaP-C). The same technology can be used to make small space and terrestrial systems more resilient and fault-tolerant, improve the networking and interoperability of related subsystems, and provide a new solution to an evolving LEO small-satellite marketplace.
Creative Electronics Systems (CES) •