Creating standards tends to be long and difficult process, but it enables the reduction of C4ISR system size, weight, and power (SWaP) and ensures commonality across multiple platforms by making it possible to share hardware and software components. It allows additional standards to be built on top of those, which is what the various military-related consortiums are doing to improve interoperability, as well as reduce development, deployment, and costs. On top of that, advanced systems can be delivered more quickly using the latest technology.
Some of these higher-level standards include Future Airborne Capability Environment (FACE), Sensor Open System Architecture (SOSA), Hardware Open Systems Technologies (HOST), and C4ISR/EW Modular Open Suite of Standards (CMOSS).
The Open Group hosts many of the standards, including those from the FACE and SOSA Consortiums. SOSA was initiated by the U.S. Air Force’s Life Cycle Management Center (AFLCMC) at Wright-Patterson AFB in Ohio and incubated in the FACE Consortium in 2015.
The HOST standard was initiated by the U.S. Navy’s Naval Air Systems Command (NAVAIR) at Patuxent River in 2014. HOST has been used in the integrated core processor (ICP) for the joint strike fighter (JSF) F-35, as well as for its panoramic cockpit display electronic unit (PCDEU).
CMOSS was started by the U.S. Army's Communications-Electronics Research, Development and Engineering Center (CERDEC) at Aberdeen Proving Grounds in 2013. It’s designed to bring about the reduction of C4ISR SWaP in embedded military systems while ensuring commonality across multiple platforms through sharing of hardware and software components.
1. OpenVPX backplanes like this one from Elma Electronic are the basis for military COTS standards.
CMOSS currently incorporates the Vehicular Integration for C4ISR/EW Interoperability (VICTORY) standard that provides network-based interoperability using share services such as Time and Position and OpenVPX (Fig. 1), a hardware form factor for fielding capabilities such as cards in a common chassis. Also included are the Modular Open RF Architecture (MORA) for driving functional decomposition to share resources like antennas and amplifiers and software frameworks that include REDHAWK, the Software Communications Architecture (SCA), and Future Airborne Capability Environment (FACE) to enable software portability.
The idea for all of these standards is not to have just one part of the system compatible with a number of boards. It’s also that these compatible boards work together, providing more options as well as simplifying system design and upgradability.
Kontron’s VX305C-40G 3U VPX server blade (Fig. 2) is designed to handle SOSA-compatible XMC modules. The board has a 12-core Intel Xeon D with up to 32 GB of DDR4 ECC memory. It has a 40G Ethernet data plane and dual 10G Ethernet ports. The x8 PCI Express (PCIe) XMC slot is for the SOSA XMC module. It supports the I/O Intensive slot definition (SLT3-PAY-1F1F2U1TU1T1U1T-14.2.16).
2. The I/O Intensive definition (SLT3-PAY-1F1F2U1TU1T1U1T-14.2.16) is on shown on the right.
The SOSA OpenVPX standard backplane definitions specify how XMC modules would connect through a compatible carrier board. An example is Pentek’s Model 71813 XMC module (Fig. 3) that’s built around the Xilinx Kintex Ultrascale FPGA. The Option -204 includes the P16 XMC connector with 28 pairs of LVDS connections to the FPGA for custom I/O. In addition, there’s a front-panel MPO optical connector option supporting four 12-Gb/s lanes to the FPGA.
3. SOSA modules like Pentek’s Model 71813 XMC module (left) are designed to work with OpenVPX-compatible VPX boards that provide standard connections to the backplane.
The SOSA standard also defines compute-intensive slots (Fig. 4): the Primary RF/Compute Intensive (SLT3-PAY-1F1U1S1S1U1U2F1H-14.6.11-0) (left) and a Secondary RF/Compute Intensive (SLT3-PAY-1F1U1S1S1U1U4F1J-14.6.13-0) (right) slot interface.
4. SOSA also defines a Primary RF/Compute Intensive (SLT3-PAY-1F1U1S1S1U1U2F1H-14.6.11-0) (left) and a Secondary RF/Compute Intensive (SLT3-PAY-1F1U1S1S1U1U4F1J-14.6.13-0) (right) slot interface.
In theory, compatible boards could be swapped in and out with only software changes. Having standard backplanes and XMC interfaces allows for easier specification of development projects as well as specifying upgrades and replacements. While backplanes will remain custom, their design should be greatly simplified since a more limited subset of OpenVPX possibilities can be employed.
