Is space in the future for VNX?

technology was fine-tuned for use in space by the (VITA-78) Working Group. Now the lessons learned from this exercise are being applied to , the variant of VPX.

What is the problem with simply using legacy space electronics?

Why would anyone want to try to use commercial off-the-shelf () 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 , SmallSats, , and other cute little that hitchhike to space in leftover real estate on delivery vehicles that drop them off into a (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 .

21
Figure 1: A group of CubeSats, prelaunch.
(Click graphic to zoom)

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 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

.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 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.

21
Figure 2: The ROCK-3 mission computer, a rugged VNX system from CES.
(Click graphic to zoom)

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.

Wayne McGee is the Vice President of Sales and General Manager for North American Operations for Creative Electronic Systems (CES). Wayne has served in various senior management positions in his career and has more than 30 years of experience in the VME, , , and VPX markets. He is also the chairperson for the VNX VITA-74 Marketing Alliance. Before joining CES, Wayne worked for companies such as Motorola Computer Group, VMIC, SBS Technologies, and GE Intelligent Platforms. He holds a BSEE from the University of South Carolina. Wayne can be reached at wayne.mcgee@ces-noam.com.

Bill Ripley is the Director of Business Development for the North American Operations of Creative Electronic Systems (CES). Bill has served in various consulting, business development, product management, sales, and marketing roles in the embedded computing marketplace for more than 15 years, not only with CES, but also with Themis, GE Intelligent Platforms, and SBS Technologies. Prior to these engagements, he spent 23 years with Bell Helicopter performing electronic design and integration of avionic, flight-control, electrical, and electronic-warfare systems on a variety of commercial and military aircraft including the CV/MV-22 and M609 tilt-rotor aircraft, as well as the OH-58D, AH-1W, M412 CFUTTH, M407, and M222 helicopters. Bill holds a BSEE from the University of Texas at Arlington. Readers can reach Bill at bill.ripley@ces-noam.com.

Creative Electronics Systems (CES) •

www.ces-swap.com