The Importance of the Modular Open Systems Architectures Initiative
The objectives of MOSA—to improve system capabilities, compatibility and cost—are predicated on a tight collaboration between government and industry. Although each service branch of the military has a model or view of what they need in their standards to produce the systems they require, a common goal of interoperability has re-shaped the military electronics landscape over these past few years.
Interoperability is an important concept when looking to gain an advantage in executing compute processes through the hardware that is being used to build embedded systems.
What do we need in order to connect things in a system that the DoD may use? The major elements include a network system infrastructure and the communications being driven across high-speed Ethernet. But there are several other elements embedded in the architecture that need consideration. These can include synchronization and precision timing signals for navigation, system management to monitor modules for health and power systems that enable the modules to operate.
The Open Group Sensor Open Systems Architecture™ (SOSA) is the governing standard that makes use of other open standards, which fall under the SOSA umbrella, and all adhere to the MOSA approach. One of these, OpenVPX, or VITA 65, is essentially the hardware standard for DoD modules aligned to SOSA.
Quick Review of OpenVPX’s Main Element
Let’s look under the hood of OpenVPX. Managed by VITA, it is a family of proven, VITA-based open standards. The first thing to note is that it defines specific slot module profiles to limit the ways that components can interface, reducing potential incompatibility. System management is handled through VITA 46.11, a standard that covers chassis and system management concepts.
Similarly, a common way to apply power to the system is defined, allowing for standard PSU modules that can address the need for both 3U and 6U systems. OpenVPX normalizes the power module interface definition through a subgroup, VITA 62, so there is consistency across LRUs.
Support for higher power modules through new cooling techniques are part of OpenVPX, too. Through the SOSA hardware standard, the modules are also aligned with CMOSS and HOST, covering the needs of the Army, Navy and Air Force.
OpenVPX keeps up with industry changes
The needs of a market don’t stand still. Take Ethernet and PCIe for example. From 1980 to 2020, Ethernet has gone from 10 MB to 1 GB, and then from 10 to 25 and up to 100 GB, as the need for faster speed keeps increasing. (Figure 2)
PCIe is how we move data across modules and systems. It started at 2.5 Gigatransfers, then 5, now 8, and is moving into the realm of 16 Gigatransfers a second. These two trends enable embedded designers to implement faster designs within OpenVPX. The industry is doing this by adopting the standards and implementing the backplane technology necessary to build advanced military systems.
To plug different cards together and ensure interoperability, there needs to be a consistent way to pin them out, and map them, so there’s alignment with the signals and ultimately, for the boards to be interconnected via a backplane. OpenVPX provides a method to communicate or interface the cards together, in a consistent way, so time is not spent on making elements work together. Instead, development efforts can focus on building out system functionality.
Let’s consider some other works that have shaped OpenVPX over the last few years. Out of an initiative through the US Army, a hardware convergence architecture was formed that brought in new concepts, such as higher speed interconnects, to network connected communications. The use of new fiber optic and RF connectors, radio plot schemes for timing and a look towards higher power densities in the module were also brought into the VPX fold.
Responding to Trends in System Design
Two additional trends include systems becoming more complex as well as the increased need for synchronization to standardize the way timing is done amongst the cards. OpenVPX has taken on that challenge and defined a radial clock strategy and timing slot. This timing card produces timing information and generates clock signals that can be distributed down the backplane.
Higher bandwidth requirements have put pressures on system backplanes, which now need to operate 2.5x faster than even a year or two ago. This has evolved into new high-speed backplane implementations that leverage new signal integrity and simulation models and connectors that go from 10 to 25 Gb, with switching speed supported by the connectors. (Figure 3)
As time goes on, modules have moved from 40 W to 60 W and up towards 130 W, depending on the need per module. Doing this in a conduction cooled way is difficult and causes us to have to look at other approaches. Air flow-through (AFT), VITA 48.8, pushes more air through a module to be able to cool it in a modified conduction cooled sort of way, by driving air through the modules to vent the cards and take heat away. Liquid flow-through (LFT), VITA 48.4, is another new cooling standard providing a roadmap to allow solutions requiring more power to use liquid cooling capabilities.
Continued Development in Open Standards Architectures
OpenVPX is a living standard, moving forward with new challenges as the technological needs of military platforms evolve, constantly addressing how new technologies can be incorporated into a rugged system to implement requirements mandated by the DoD.
In summary, future DoD systems are being affected or driven by the modular open system architecture approach and the need for current technologies. These are impacting new systems and will affect future designs, chassis, backplanes, power requirements, etc. This brief look under the hood of what OpenVPX provides shows it’s a supported, active standard that is here today and will grow to meet DoD future system needs. It fits nicely with MOSA and higher-level standards of SOSA, CMOSS and HOST as well as provides a hardware standard that allows MOSA to achieve its goals.
Over the past several years, the Modular Open RF Architecture (MORA) has evolved to address the challenges of increasingly complex radio frequency (RF) systems through an open standards-based infrastructure. With several industry partners working together to develop a collaborative framework, MORA’s interoperability and modularity has been realized, resulting in successful demonstrations of multiple manufacturers’ technologies working together. So, we asked some of our open standards partners: What’s next for MORA-based systems and the embedded computing community, now that interoperability demonstrations have been successfully deployed?
Looking back we can now see a shift in how development platforms are designed and how they are used by our integrator customer base. That shift is making it easier and less expensive to perform the development stages of a deployable system project and put solutions into the hands of the warfighter faster than ever before. Development hardware can also be shared between projects, or inherited by subsequent projects. This saves not only on lab budget, but the time to order and receive all new hardware for a new development project.