Development of the next-generation OpenVPX-based embedded system standard: A tri-service convergence of approaches: Part 2 of 3

Story

April 11, 2019

Dr. Ilya Lipkin

Air Force Life Cycle Management Center (ALCMC)

Something exciting is happening in the service representative community. Representatives from three different programs, one from each of the U.S. Department of Defense (DoD) services, have come together with a common objective to solve their respective acquisition problems with an agreed-upon, open architecture standard. Here is Part 2 of a 3-part article covering the SOSA [Sensor Open System Architecture] Consortium’s efforts. Read Part 1 in the March 2019 issue of Military Embedded Systems.

The best way to understand the uniqueness of this tri-service convergence is to provide the historical perspective building from the development of the underlying, enabling technology from the past. The current cutting-edge embedded systems are based on the VPX connector, which began standardization around 2003 with the development of VITA 46. The VPX connector provides the state of the art for high-bandwidth, high-connectivity embedded system backplanes. It is a key enabler that allows 728 pins on an IEC-60297-3 Eurocard 6U format and 280 pins on a 3U format circuit card, with options for replacing connector segments for card-edge RF and optical connections with significantly greater bandwidth. This technology came into its own when the OpenVPX standard was approved as VITA 65 in 2010; the market has grown year by year since then, with broad adoption of OpenVPX, as the market converts from legacy VME-based chassis.

OpenVPX includes a broad range of standard options from which a system designer can choose during development. While these options enable a high degree of flexibility to support a broad range of applications, they also create the potential for dilution of the market for any one design, effectively creating a nonstandard standard through all of the allowed permutations. This, of course, is the risk any developing standard faces if it is created in advance of user adoption and broad enough application.

The stated vision of the HOST [Hardware Open Systems Technologies] hardware standard was to apply existing industry standards to effectively do for the U.S. Department of Defense (DoD) what the release of the IBM PC standard did for personal computing. Specifically, the IBM PC standard [1] provided definition of standard interfaces so that the computer industry could focus and converge on providing capabilities through a market ecosystem which could connect through these interfaces. This definition allowed a range of businesses small to large to develop new capabilities which could be sold at affordable prices, through hardware and software, the development of which could be afforded by the volume that then ensued. In a similar vein, the stated goal of HOST is to allow the industry to stop reengineering existing technologies for new systems (e.g., to slightly different specifications such as environments or pinouts) and refocus the DoD’s and market’s investment in development towards new state-of-the-art technology and value-added new capabilities. The current HOST Tier 2 standard is based on the VITA 65 OpenVPX standard, providing greater specificity as well as adding requirements for basic hardware management (e.g., via VITA 46.11 over the IPMB [intelligent platform management bus] or control-plane Ethernet). It also creates the Tier 3 specification process and requires its use to specify plug-in modules. This tiered structure can be seen in Figure 1.

Figure 1: Application of HOST’s tier structure.

(Click graphic to zoom)

The Tier 3 specification process is under development, with plans to be applied and tested during 2019 by end users of HOST (e.g., the Joint Strike Fighter program office and NAVAIR’s PMA 209 supporting development of a replacement mission computer for a number of legacy platforms). A Tier 3 specification can be thought of as a module-level component specification that includes both the way in which the Tier 2 standard requirements are met as well as the additional requirements for module or payload functionality. The definition of a HOST module also allows for the specification of HOST mezzanines: By proper design and functional decomposition, base HOST plug-in modules can be reconfigured for new payload capabilities through selection of different HOST mezzanines. If properly written, a Tier 3 specification will allow an acquisition authority to create a family of products built from modules specified by Tier 3 specifications. This general acquisition authority can include anyone needing, designing, or building an embedded system (e.g., prime contractor or service platform, system designer or integrator, or contract manufacturer that builds systems to a design for a customer).

A product-line manager can then use the set of Tier 3 specifications that they have selected to satisfy customer performance needs with custom designs built upon standard plug-in modules and mezzanines. This vision can be seen in Figure 2. HOST’s benefits to the customers include lower cost hardware through use of standardized modules (not requiring reengineering for each application) with higher volumes, especially if they can be shared across product lines and/or across acquisition authorities or services. Benefits to industry include higher volume for standard modules (e.g., power supplies, switches, and single-board computers) and greater consistency of their market from which to recoup their development costs.

Figure 2: The vision for HOST.

(Click graphic to zoom)

Moreover, by knowing the interfaces that customers are selecting, new products can be developed to interface into old systems so that upgrades to the newer model becomes simply a little integration work to create new software load and a lower-cost card swap (i.e., much simpler logistics) versus getting approval and funding for a major acquisition program. When combined with efforts such as FACE [the Future Airborne Computing Environment standard] that intend to abstract application software (that ultimately provides capabilities) from the underlying hardware, industry will know the interfaces of the existing modules and be able to use R&D to develop the next generation of technology (e.g., as new processor chips become available or the next in a family of FPGAs gets announced) in order to be able to plan for more frequent technology refreshes. Stated differently, instead of reengineering each custom card for each new application, common interfaces will allow both customers and industry to commoditize common building blocks so that shrinking development dollars can be focused on greater value-added capability creation.

CMOSS and refinement of RF application standards

The Army has historically implemented C4ISR [command, control, communications, computer, intelligence, surveillance, and reconnaissance] capabilities as a multitude of separate “boxes” on individual platforms. This approach makes it difficult to upgrade capabilities or keep pace with commercial technology due to complex integration challenges, lack of competition, and proprietary interfaces. In many cases stovepiped systems consume more size, weight and power (SWaP) than is currently available, thus necessitating expensive and time-consuming vehicle redesigns.

CMOSS [C4ISR/EW Modular Open Suite of Standards] defines a Universal A-kit (or wiring harness for interconnection) that eliminates the need for platform-specific integration as capabilities can be fielded as cards in a common chassis and components that use existing cabling. The concept of a Universal A-kit is a game-changing approach as it ensures commonality across multiple platforms, while allowing for rapid insertion of the latest C4ISR capabilities. Built upon open standards, this Universal A-kit enables the soldier for the next fight while providing significant cost savings during the procurement and sustainment phases of the life cycle.

CMOSS revolutionizes sustainment as logistics tails can be smaller due to common spares, while unit costs can be reduced by greater competition and economies of scale. Sustainment organizations will no longer need to purchase enough spares to last 30+ years as they can perform modernization through spares and upgrade to the latest hardware every five to ten years or less.

CMOSS defines an open architecture that reduces the SWaP footprint of C4ISR systems by enabling sharing of hardware and software components. Well-defined components with open interfaces not only allow rapid technology insertion to keep pace with emerging needs, but they also permit capabilities that are innovative but unplanned to be quickly implemented. The open architecture consists of a suite of layered standards that are individually useful and can be combined to form a holistic converged architecture.

The CMOSS suite of standards shown in Figure 3 includes:

Network-based interoperability using VICTORY [2] [Vehicular Integration for C4ISR/EW Interoperability] to share services such as time and position
Hardware form factor using OpenVPX to field capabilities as cards in a common chassis
Functional decomposition using the MORA [Modular Open Radio Frequency Architecture] to share resources such as antennas and amplifiers
Software frameworks such as REDHAWK [3], Software Communications Architecture (SCA [4]), and FACE to enable software portability

Figure 3: The CMOSS suite of standards.

(Click graphic to zoom)

The linkage between VICTORY and MORA can be more easily seen in Figure 4.

Figure 4: CMOSS ties VICTORY and MORA.

(Click graphic to zoom)

CERDEC is working with industry and academic partners to define and mature the CMOSS standards by developing reference implementations within the converged architecture. These activities include coordination with the Tank Automotive Research, Development and Engineering Center (TARDEC) to integrate and demonstrate the reference implementation on a tactical vehicle.

CERDEC is leveraging CMOSS to develop capabilities within its portfolio; these activities will not only further mature the architecture, but will also facilitate technology transition to programs of record. CERDEC is actively working with the acquisition community to include CMOSS requirements in current and emerging programs.

A critical component to the success of any open standard is its sustainment. To that end, CERDEC is actively participating in the associated standards bodies to address emerging requirements and technology. CERDEC is also collaborating with other services to align open architecture activities and enable procurement of common hardware and capabilities: CMOSS has been included in the Air Force’s Sensor Open System Architecture (SOSA) standard and has been aligned with the Navy’s HOST standard.

SOSA and convergence of end-user embedded system requirements

As a cooperative industry forum, SOSA’s stated goal is to lower the life cycle cost of technology development and deployment and reduce the time it takes to get new capabilities deployed faster than the traditional, stovepiped platform approach. This cooperation includes the underlying technology which enables and/or provides the next capability, both hardware (e.g., plug-in modules) and logic (e.g., software and firmware). These goals are similar to those for HOST and CMOSS – that is, all three efforts are effectively trying to achieve the same goals of lower cost and faster transition of capability – so consequently SOSA became a logical overarching organization upon which these two efforts could converge. As an Open Group consortium, SOSA has also benefited from what has been learned from past open architecture initiatives that have been successful, as well as learning how to avoid the mistakes of past unsuccessful standards. For example, SOSA incubated under the FACE Consortium in order to leverage lessons learned, membership structure, and develop valuable initial processes that took FACE years to develop and accumulate. Under the FACE Consortium, SOSA was able to come up with a common ecosystem between avionics and sensor domains, further improving interoperability of both efforts.

References

[1] https://en.wikipedia.org/wiki/IBM_Personal_Computer

[2] Reference to the public version of the VICTORY standard

[3] https://redhawksdr.github.io/Documentation

[4] http://www.public.navy.mil/jtnc

Mike Hackert is program sponsor at NAVAIR [Naval Air Systems Command], Ben Peddicord is chief of CERDEC [Combat Capabilities Development Command (CCDC) C5ISR Center/formally the Communications-Electronics RD&E Center] Intel Technology and Architecture Branch, and Dr. Ilya Lipkin is lead manager for SOSA at the AFLCMC [Air Force Life Cycle Management Center].

NAVAIR | www.navair.navy.mil
CERDEC | www.cerdec.army.mil
AFLCMC | www.wpafb.af.mil/aflcmc