More than three years ago, a group of industry and government representatives focused on providing high-performance and highly efficient critical embedded computing solutions for customer needs launched the effort to define the Next-Generation Space Interconnect Standard (NGSIS). The initiative aimed to leverage existing commercial open standards to provide cost savings across the life cycle of space programs.
VITA 78 SpaceVPX was initiated to change the paradigm by which the space community conducted its acquisition of new technologies and systems. VITA 78 adopted OpenVPX (VITA 65) as its baseline architectural framework to develop an enhanced set of module and backplane specifications based upon existing commercial standards with added features required for the space community and its applications. It also focused on increasing interoperability and compatibility between manufacturers and integrators, while simultaneously boosting affordability through the use of standard sets of hardware.
Driving factors
Before VITA 78, the industry was struggling with how to move forward with certain embedded computing platform issues that had presented challenges for many years. Industry leaders asked themselves, “Is it cost-effective to continue using legacy space electronics?” Systems had been developed and deployed in space via the same methods for many years; why not just keep doing it the same way?
Several factors posed concerns to the architects of these complex systems:
- Legacy space systems were often point solutions, designed for very specific missions with no real intention of meeting additional goals of other existing programs.
- Reuse was not a priority because of precise mission design goals. The platforms could not be readily reconfigured for new or changing missions.
- Systems did not have the full range of redundancy options (dual-string, M-of-N, etc.) built in as part of the overall architecture. As a consequence of this failure to engineer redundancy and resiliency initially, the provider was forced to add these features in a piece-by-piece fashion.
- Internal interfaces were often proprietary and application-specific, leading to additional costs and development time. Commercially and commonly available interfaces often were not considered due to concerns about reliability or availability.
- Modules were not designed to interoperate at either the hardware or software level. Silos of technology that prevented programs from sharing platforms, mission requirements, and schedules were different enough that no one wanted to take the time to look into where components might be used in the future.
Many if not all of these factors were tolerated given the alternatives. Development schedules were set with systems that agencies expected to be delivered mission-capable and on time. In the background, pressure was mounting to reduce overall cost through reduction in development and acquisition. Deployed experiments with inexpensive computing elements were starting to have successes. Cost reductions and time-to-market pressures were relentless.
Enter VPX
The VPX concept was proposed in 2003. It was originally intended to be a small form factor blade using the current switch serial fabric interconnects. Even at the launch, the forefathers were not sure where the efforts were going to lead.
The specification was extremely open, leaving room for nearly any existing or future switch serial fabric to be implemented as an interconnect structure. This meant that numerous configurations were possible, which quickly led the implementers to launch the OpenVPX effort to develop an architectural framework that could help provide topology guidance to system architects.
The nearly infinite number of configuration combinations, while attractive to a system architect who was not sure of the best topology for their needs, was dragging down the board and system supply chain that could not determine the moving sweet spot of configurations. No one supplier was big enough to drive an industry-wide accepted set of configurations, and no demand-side user wanted to step up and drive the industry. The OpenVPX architectural framework provided the much-needed configuration focus.
Even more improvements and enhancements emerged as systems were deployed, with the most recent example being work nearing completion on system management (VITA 46.11) and a modular power supply standard (VITA 62).
Slowly, to use a space themed cliché, “the stars were starting to align.” VPX had been evolving with improvements to the overall framework, system management, interoperability, and functionality. In the background were industries ready to take advantage of this alignment. Visionaries working on space and other critical embedded systems needing a high degree of fault tolerance saw what VPX had to offer. The small size made it a great choice for size, weight, and power (SWaP)-limited platforms. The topology flexibility meant that they could conceive a configuration that more closely met their application goals.
Fault-tolerant configurations were possible with various mesh topologies that enabled various types of redundancy either with dual strings and multiple levels of backup components. The open systems/open markets approach of VITA members meant that new efforts would be embraced that leveraged the best that VPX and VITA had to offer.
Goals and attributes
The SpaceVPX effort was initiated to develop an enhanced set of backplane specifications that were based upon existing commercial standards with added features required for space applications. Another objective was to expand interoperability and compatibility between manufacturers and integrators, while also increasing affordability through the use of standard sets of hardware.
The developmental goal of SpaceVPX Systems was to achieve an acceptable level of fault tolerance while maintaining reasonable compatibility with the OpenVPX architectural framework and VPX components, including connector pin assignments. For the purposes of fault tolerance, a module was defined to be the minimum redundancy element.
The major fault-tolerance attributes for the target high-reliability applications included:
- Dual-redundant power distribution (bussed), where each distribution is supplied from an independent power source
- Dual-redundant utility plane signal distribution (point-to-point cross-strapped), where each distribution is supplied from an independent system controller to a module that selects between the A and B system controllers for distribution to each of the slots controlled by the module
- Card-level serial management
- Card-level reset control
- Card-level power control
- Dual-redundant data planes
- Dual-redundant control planes
- Fault-tolerant utility plane selection (bussed)
- Power-feed profile with unique keying
- Timing/synchronization/clocks, matched length, low-skew differential timing
As a result of analyzing these factors, the VITA 78 Working Group successfully executed the focus of the SpaceVPX effort and composed a specification to fulfill its purpose.
What is SpaceVPX?
ANSI/VITA 78 defines an open standard for creating high-performance, fault-tolerant, interoperable backplanes and modules to assemble electronic systems for spacecraft and other high-availability applications. Such systems support a wide variety of use cases and potential markets across the aerospace and terrestrial communities. The standard leverages the OpenVPX standards family and the commercial infrastructure that supports these standards.
SpaceVPX bridges VPX standards to the space market by accomplishing the following purposes:
- Address not only interoperability, as OpenVPX does, but also space application needs that are not a part of OpenVPX.
- Define payload, switch, controller, and backplane module profiles to meet space application needs.
- Add features to the utility plane for fault tolerance:
– Point-to-point not bussed to tolerate faults: A failure of a module does not affect the entire system. The meshed network of modules provides multiple strings to eliminate path failures. The system also can be scaled with redundant modules to the degree necessary to gain acceptable fault tolerance for the mission at hand.
– Space Utility Management (SpaceUM) module provides a dual-redundant source for utility plane implementations.
- Define use of SpaceWire for the control plane instead of Ethernet, the preferred choice for OpenVPX. SpaceWire is a standard for high-speed links and networks for use onboard spacecraft (www.spacewire.esa.int/content/Home/HomeIntro.php).
- Promote standard components, interoperability, accelerated development, and deployment for the space market.
Typical use case and essential elements
Figure 1 captures the essence of a SpaceVPX system. Each box represents one module function. The main data flow in most space systems is shown by the blue boxes, typically implemented as payload modules. Any of the four functions can be combined into a specific payload implementation. The properties of this use case follow the circled letters in the figure.
A) Data enters the system through a data in module. The next four letters represent potential data transfers between the main payload functions within a SpaceVPX system.
B) Data from the data in module can be transmitted to the processing module. Processed data from the processing module can be stored in the storage module. Data from the storage module can be routed to the data out module.
C) The processor module can access data from the storage module.
D) Data from the data in module can be routed directly to the storage module. Data from the processing module can be routed directly to the data out module.
E) Data from the data in module can be routed directly to the data out module.
F) Data routed to the data out module can then be transmitted out of the system.
G) For fault tolerance, there is at least one spare of each function. These redundant payloads have the same data routing as the primary payloads so that errors will not reduce capabilities. Though not shown, more than one of each function type can be present, and M-of-N sparing (minimum 1 of 2) can be implemented for any payload type.
H) Redundant external inputs and outputs are available to and from the SpaceVPX system. These are typically cross-strapped between redundant elements.
I) Cross-strapping is available between the primary and redundant payload groups so that any one payload can fail and the remaining payloads can operate with sufficient interconnect for any combination of primary and redundant elements.
Fault tolerance
The SpaceUM module facilitates the fault-tolerance capability in SpaceVPX. A traditional VPX system controller controls utility plane signal distribution to all the logic modules. As shown in Figure 2, each system controller routes identical copies of utility plane signals (for example, resets, reference clocks, and so on) to each active SpaceUM module.
Since each SpaceUM module supports the utility plane selection of up to two (3U) or eight (6U) logic modules, a SpaceVPX system supports up to four SpaceUM modules. The SpaceUM modules then select which set of utility plane signals to route to each logic module. The default OpenVPX routing of these utility plane signals are via busses, which introduce single-point failures between the modules. Fault tolerance is enhanced with the separate radial distribution of the selected utility plane signals to each module. The SpaceUM module is unique to SpaceVPX.
Utility plane power connections are also routed through the SpaceUM modules in a SpaceVPX system. The utility plane power connections consist of at least dual power modules to provide power to the SpaceVPX system. The SpaceUM modules individually select and separately route the resulting module power selection for each logic module. The A/B selection can be internal (autonomous) or external.
Fault tolerance is provided by fault containment between redundant sections of each SpaceUM module. OpenVPX supports a single power mode for each plug-in logic module. SpaceVPX maintains this by moving the power selection into the SpaceUM module.
As shown Figure 2, the system controller manages the utility plane signals in a SpaceVPX system.
A) SYS_CON* and SYS_CONP* provide a fault-tolerant selection for plug-in modules that could be system controllers.
B) Controller modules distribute copies of the system control and reference clocks to each active SpaceUM module.
C) SpaceUM modules use the system controller select signals (either external or internally generated) to select which set of system control and reference clocks to distribute to logic modules.
D) SpaceVPX supports switching of up to 32 6U logic modules using up to four SpaceUM modules, each handling eight logic modules. In this figure, only two SpaceUM modules are needed to support the 14 logic modules. If more than two logic modules were added to this system, the third SpaceUM would be required for the 17th through 24th module, and the fourth SpaceUM would be required for the 25th through 32nd modules. A 3U SpaceUM module supports only two logic modules. Since the SpaceUM modules are simply extensions of the controller, payload, and power modules, no redundancy is required.
E) The SpaceUM module distributes the utility signals to all other logic modules including payloads, data switches, and control switches.
Benefits to customers and vendors
Performance
SpaceVPX provides significantly higher data rates and topology configurability supported by NGSIS through a standard engineered product compared to traditional space interconnect architectures such as MIL-STD-1553, SpaceWire, serial RapidIO, and CompactPCI. The standard also allows implementers to trade off redundancy for performance in accordance with their specific system needs.
Flexibility
Based on the highly configurable Modular Open System Approach (MOSA) architecture, SpaceVPX supports both common 3U and 6U form factors with a wide range of modules and configuration options to allow mission-specific customization.
Affordability
Leveraging and extending existing modern standards provides a significant pay down of technical debt compared to more traditional approaches for space systems development (and other recent space standards efforts) based on custom and proprietary architectures. The maturity of the base standards significantly reduces the cost, risk, and schedule for the non-recurring engineering efforts associated with the development of custom modules.
Furthermore, designers have the capacity to leverage existing reference designs and intellectual property components in custom implementations. The approach potentially enables the use of ruggedized commercial off-the-shelf modules in future space systems with appropriate environments, resulting in a corresponding reduction in development costs and schedules.
Interoperability
The a priori definition of the interface specifications contained in the standard offers several interoperability benefits. This breaks down the traditional stovepipe and associated challenges of interface management by providing a well-defined common interface that allows for conformance verification without a complete system.
Additional potential benefits include:
- Specific design profiles upon which vendors can base their designs and integrators can specify as requirements.
- Reduced integration issues resulting in faster development and deployment time.
- Higher board volumes that produce economies of scale.
- Higher velocity of technology upgrades.
- Support for higher backplane signaling speeds as technology matures.
Addressing market needs
These benefits demonstrate how SpaceVPX addresses the aforementioned driving factors propelling the development of an open standard for backplanes and modules used in space applications.
Systems were originally tightly coupled with proprietary integration schemes, and changes were costly and involved high risk. Open system architecture guidelines and the SpaceVPX standard deliver a loose coupling between hardware and software, making changes easier at a much lower risk. Systems can now be designed for change. Table 1 compares some of the significant differences between the VPX and SpaceVPX specifications.
|
|
Hardware reuse was less attractive because system cost was dominated by non-recurring engineering costs that were much greater than the hardware. A SpaceVPX open architecture strategy drives these costs down because system integration is much easier and entails lower risk.
Prime contractors had a central role for the life of the system, which limited design and mission flexibility. Sole sourcing also stifled competition, keeping costs high. An open architects/open markets approach provides more solutions to choose from a competitive supplier base.
A large and robust ecosystem of suppliers and users ensures that the technology moves forward with the best of the best capabilities. SpaceVPX brings traditional make versus buy advantages to what was previously a closed community (other industries embraced the buy decision years ago).
SpaceVPX current status
The ratification of VITA 78 SpaceVPX Systems was a huge milestone for the working group members. Now begins the work of building an ecosystem of suppliers and users. Multiple VPX vendors have shown interest in supplying products based on the SpaceVPX specification. Though public announcements have yet to be made, rumors are circulating that prototype products could be available as early as Q3 or Q4 of 2015.
Demand is very active. Multiple large programs are developing SpaceVPX strategies. Multiple NASA centers have evaluations underway for adoption of both 6U and 3U formats. The European Space Agency (ESA) has shown interest, as well as multiple tier I and tier II vendors.
Additional work is still needed with SpaceVPX. The VITA 78 Working Group has already started work on SpaceVPX Lite, which defines a lightweight implementation with significant advantages in SWaP-C for 3U module systems. It is “lightweight” with respect to the reduced scope of requirements compared to the SpaceVPX base standard that results in a smaller SWaP-C footprint for deployment.
Systems developers often implement 3U modules when confronted with driving SWaP-C constraints. The SpaceVPX base standard implementation for 3U results in a much larger ratio of support modules to payload modules than for a 6U implementation. The SpaceVPX Lite specification defines a reduced support module to payload module ratio by removing some base standard features while retaining critical requirements necessary to deploy a single-point failure-tolerant system.
SpaceVPX Lite has the following differences with SpaceVPX:
- SYSRESET*, AUX_CLK±, and REF_CLK± are driven from redundant controller modules directly to payload modules.
- SpaceVPX defined REF_CLK1± and REF_CLK2± pins on payload modules are used as secondary AUX_CLK± and REF_CLK±, respectively. OpenVPX Maskable Reset* on payload modules are used as secondary SYSRESET*.
- Redundant controller modules provide eight sets of two new user-defined differential pairs that can be driven to each of eight payload modules. These can be defined as controls to switch in redundant power sources, additional clocks, or specific application-defined signals.
- Power supply on/off, primary/secondary controls are not defined in SpaceVPX Lite.
- Radially distributed system management is not defined in SpaceVPX Lite.
- SpaceVPX Lite does not define a SpaceUM module, but it does support the use of a similar power-only module and system management bus communication with the system controller module using the SpaceVPX Direct Access Protocol or VITA 46.11 System Management.
A SpaceVPX Lite-compliant system meets the basic requirements of providing radial and redundant OpenVPX utility signals SYSRESET*, AUX_CLK±, and REF_CLK± to achieve single fault tolerance. Implementation of single fault-tolerant power distribution to the modules is deferred to the user to define, but the standard does provide radially distributed user-defined signals to enable redundant power control. These signals can be used with new or high TRL existing power distribution modules and/or sources.
A standard for building open platforms
“We are pleased that SpaceVPX Systems has received VITA/ANSI recognition,” said Patrick Collier, senior electrical research engineer, Space Communications Program, AFRL Space Vehicles and VITA 78 Working Group chair. “We were able to pull together the minds of engineers from companies around the world that have a vested interest in developing this specification for the space industry.”
Other application segments are looking at this model to determine the best steps forward. Rugged ground vehicles have many of the same requirements, yet they have unique needs. VPX and the VITA process are just the technology and support system that the industry needs to develop variations of their own.
The openness of VPX originally scared people, but in reality, it is providing a proven alternative for custom solutions. Mass customization is the use of well-defined modules, either hardware or software, that enables a system architect to develop an integrated platform that is both unique and commercial. A modular mass-customization strategy combines the best of an open-modular approach with the ability to tune the architecture to meet a wide variety of very specific or custom needs – all while being cost-effective.
We all look forward to attending the first launch of a space system based on SpaceVPX systems!