Development of the next-generation OpenVPX-based embedded system standard – A tri-service convergence of approaches: Part 1 of 3
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 1 of a 3-part article covering the SOSA [Sensor Open System Architecture] Consortium’s efforts.
While standards are often driven by new technology trying to fulfill customer needs, this effort was driven by the acquisition community as it sought to reduce costs and development time by applying open-architecture principles in a practical and consensus-driven way. The goal of these efforts is to select the best-of-breed existing architectural frameworks and relevant standards, and to create something where a gap currently exists. Consequently, this tri-service convergence effort set itself up for success since it is driven by the end user in the acquisition community, tied to specific programs, as opposed to other efforts, which have started from the development or supplier community trying to fulfill a need without the direct “pull” from the customer.
The Navy has developed a hardware standard, Hardware Open Systems Technologies (HOST), that focuses the VMEBus International Trade Association’s (VITA’s) standards to fulfill DoD and aviation-specific requirements; while the Army has applied the Vehicular Integration for C4ISR/EW Interoperability (VICTORY ) standard and extended it with additional requirements such as Modular Open Radio Frequency (RF) Architecture (MORA ) and Department of Defense (DoD) VITA OpenVPX  profiles needed for radio frequency (RF) applications under their C4ISR [command, control, communications, computers, intelligence, surveillance, and reconnaissance]/EW [electronic warfare] Modular Open Suite of Standards (CMOSS) initiative. For its part, the Air Force is developing a standard for C4ISR systems under a consortium named Sensor Open System Architecture (SOSA), which is focusing on sensor- and processing-intensive systems, under which a number of applications can be standardized. The foci of development for each of these programs has become the SOSA Consortium which is maintained by The Open Group , a developer of industry standards formed in 1996 and noted for its origins standardizing the UNIX operating system developed in the 1970s by AT&T and more recently the Future Airborne Computing Environment (FACE ) Standard. The end-user community can thus come together and agree upon requirements for their particular applications.
The standard’s need statement
The DoD realizes that it can no longer continue to do business the way it did in the past, with each platform effectively a stovepiped fiefdom where technology was developed to uniquely fulfill their requirements. This situation resulted in repeatedly paying to create the same capability (e.g., a radio) which, in the end, may not interoperate with anything outside the system because its interfaces were developed for a specific purpose and use. The real problem is that we need to develop new capabilities faster, more reliably, and with a long-term life cycle view, since our direct competitors will not wait. Additionally, the key problems of the rising development costs and the need to transition technology faster, coupled with shrinking budgets, requires the DoD to be more agile.
From a DoD acquisition perspective, nimbly deploying a new capability cannot cost hundreds of millions of dollars – or more – when the new capability includes a new platform, when individuals can effectively mount an attack or defense against it by buying or mail-ordering cheap consumer electronics. (Or by analogy to Star Wars, the Death Star was defeated by rogue fighters using cheap, omnipresent R2 units, the rebellion’s smallest but highly functional unit of a modular architecture, which might be likened to a modern-day single-board computer. ) Furthermore, the commercial industry has already shown how new capabilities can be developed at low costs and deployed by applying open architecture approaches that lend themselves to convenient upgrade (e.g., smartphone technology).
The Air Force, Army, and Navy representatives, as well as a majority of the DoD, also understand that capability no longer needs to be or should be tied to expensive platforms. For example, the avionics suite on an airborne platform ought to be developed in a modularized approach so that systems can be conveniently swapped out during system design and development. This approach is especially important to remain competitive against enemies that can outspend the U.S. Of course, the DoD needs to continue to invest in new platforms. While the service life of the DoD’s older platforms can be extended by application of modularity and open architecture principles to allow for effective capability upgrades, this cannot be done indefinitely.
Currently, platform acquisition timelines are measured in tens of years for development before deployment, which does not lend itself to fast capability deployment. With today’s fast-paced technology development, a capability will become obsolete, with a new capability being required before the first platform is delivered by an acquisition program. Consequently, the architectural approach being developed under SOSA lends itself to provide a certain degree of “future-proofing” to a new platform to allow new capability to be added or obsolescence addressed even before it achieves initial capability.
In order to keep up with the increasing pace of technology development, each service’s acquisition community is intimately involved in leading this effort. This cooperation will maximize the value and synergy from working together. For the Air Force, the Air Force Life Cycle Management Center (AFLCMC) at Wright-Patterson Air Force Base in Ohio represents a number of sensor programs, all wishing to develop modular capability maximizing the reuse and sharing of system building blocks across programs. For the Army, the U.S. Army’s Communications-Electronics Research, Development and Engineering Center (CERDEC – Aberdeen Proving Ground in Maryland), has developed its CMOSS suite of standards for C4ISR/EW and communications systems. While CMOSS started out as only a CERDEC product, the synergy with SOSA quickly became clear.
For the Navy, NAVAIR (Patuxent River, Maryland) had begun development of the HOST standard for application on its next-generation mission computing platforms. While HOST added specificity to established, state-of-the-art industry standards, specifically VITA 65 – OpenVPX, it became apparent that the addition of HOST would do the same for the SOSA standard, while again broadening SOSA’s application space by focusing on pure processing systems like an airborne mission computer.
While these independent efforts each started out focused on fulfilling the capability needs for each of their local service customers, the centers realized that by working together under SOSA, they could reduce costs for each other, which is most apparent for hardware (Figure 1). The value proposition from standardization of hardware interfaces is easy to understand: Standardization of hardware modularization creates an environment where plug-in modules can become commoditized so that hardware development costs can be shared across acquisition programs and services. Examples include power supplies, which generally are required by all systems; network switches, which are increasingly used by system designers to relay information within a given system or provide connectivity outside of a system; or single-board computers where integral processor technology becomes outdated and obsolete in a matter of a few years, which necessitates replacement due to obsolescence or updates to add additional capability.
The value proposition from standardization of software is much more difficult to concretely quantify. Standardization of software modularization creates an environment where software (e.g., applications or “apps”) can be shared and reused. Adequate definition of the interfaces allows new apps to be more quickly added/deployed. Consequently, the vision for this standardization of an architectural framework as well as specific interface definition is to allow new capabilities to be deployed more rapidly at lower costs. The challenge these representatives face is to determine how to apply open architecture approaches and industry standards to best fulfill their common as well as specific embedded system needs. Thus, a true tri-service convergence is occurring in the SOSA Consortium to achieve this goal.
 The MORA standard can also be found at the VICTORY website.
 Lt. Col Dan Ward, USAF, “Don’t Come to the Dark Side: Acquisition Lessons from a Galaxy Far, Far Away,” Defense AT&L: Better Buying Power, Sept-Oct. 2011.