CMOSS: Building-block architecture brings speed, cost benefits

Story

November 29, 2021

The C4ISR/Electronic Warfare Modular Open Suite of Standards (CMOSS) enables engineers and developers of systems used by the warfighter to move toward much faster technology insertions and refreshes, with a corresponding reduction in long-term life cycle costs.

The C4ISR/Electronic Warfare Modular Open Suite of Standards (CMOSS) is a modular open systems architecture (MOSA) intended to converge select Army warfighting capabilities – such as mission command, movement and maneuver, and fires – into one system vs. integrating a multitude of separate capability “boxes” into vehicles.

CMOSS is one of the Department of Defense’s (DoD’s) “successes in its early MOSA push,” says Nick Borton, machine intelligence hardware architect for SRC Inc. (Syracuse, New York). “It set the stage for how a standard architecture can shape the market, and reduce costs and integration times. Even though CMOSS was started by the Army, other branches of the armed forces are leveraging it to develop new systems.”

The main benefit of open standards for the warfighter is that they enable much faster technology insertions and refreshes. “Getting needed technology and capabilities into the hands of the warfighter in a timely manner is where CMOSS hits the mark well,” Borton says.

Other benefits are “maintainability, serviceability, supply chain logistics, and all of the other things that come with more modularity,” says David Jedynak, general manager for Curtiss-Wright Defense Solutions’ Parvus Business Unit (Austin, Texas). “You get cost benefits when you’re lumping together what were previously separate systems – because you don’t need a separate chassis and power supply for each one of them once they’re all in one box. You also start to get cost savings in size, weight, and power as well.”

Reducing vendor lock

Another reason the government is pushing so hard on open architecture adoption is to reduce vendor lock, which gives the DoD more flexibility in upgrading and fielding new technology.

“[CMOSS] avoids lock-in and provides a better performing product an opportunity to get selected instead of being eliminated from consideration because it doesn’t meet all the proprietary locked-in interfaces,” Jedynak points out. “The problem of surrounding a technology with nonstandard interfaces, so no one else can get in with their solution without an NDA and access to the interface/software, all goes away.”

This type of situation is good, he continues, because it enables companies to focus on their core intellectual property instead of constantly reinventing the wheel.

CMOSS impact on long-term life cycle costs

All MOSA initiatives, including CMOSS, are also intended to reduce long-term life cycle costs.

“Today’s systems are continuously challenged with product life cycle management (PLM) issues as they age,” says Mark Hutnan, vice president of business development for Abaco Systems (Huntsville, Alabama). “Many systems require parts that are at their end of life and unavailable – requiring additional costs to find parts on the secondary market, or paying for production lines to reconfigure and restart to build old components. SOSA/CMOSS alignment enables rapid tech insertion and upgrades since older and newer generations of components should be compatible, and greatly reduces long-term life cycle costs.”

Costs to replace obsolete components, whether hardware or software, will decrease “By establishing a market around the mechanical interfaces of the plug-in cards, and on the wire interfaces of the software capabilities, already-developed products that meet most of the needs will already be around,” Borton notes. “Up-front development costs won’t be present to the same degree within a CMOSS ecosystem. Integration time and some enhancements may be needed, but much of the development cycle should be short-­circuited from a system maintainer’s perspective.” (Figure 1.)

[Figure 1 | Soldiers with the 3rd Brigade Combat Team, 101st Airborne Division (Air Assault) at Fort Campbell (Kentucky) perform prototyping activities and operational assessments, all of which will inform mobile and tailorable command-post solutions, including C5ISR/EW Modular Open Suite of Standards (CMOSS) and Modular Open Radio Architecture (MORA) going forward. U.S. Army photo/Justin Eimers/PEO C3T.]

CMOSS origins

Like many other open architecture initiatives CMOSS came to be because the end user wanted more commonality. “In the beginning, at various Army-related conferences, we saw high-level leadership express the desire to see a board- and backplane-modularized way of converging radios and processing and sensors rather than a bunch of standalone boxes,” says Jedynak.

After a few years, it became clear no one was connecting the dots to a pathway forward. “So in 2013, we started pulling people aside to talk to them about the OpenVPX standard for embedded computing systems as a rugged backplane approach they could leverage to achieve their goals,” Jedynak continues. “This was early on, and it turned into the Army’s hardware/software convergence approach.”

This is in fact how VPX became the hardware portion of the hardware/software convergence. “The software bits of it came from the user community,” he adds. “And the hardware portion came from the open architecture COTS [commercial off-the-shelf] vendor community.”

Development on the Army side was done as a phased approach for a few years, “where they demonstrated things within the lab and then represented what it would look like on a vehicle,” Jedynak says. “It eventually evolved from being called ‘hardware/software convergence’ to ‘C4ISR/Electronic Warfare Modular Open Suite of Standards,’ and then to simply ‘CMOSS.’ It all started in 2013, and eight years later, things are really rolling forward.”

MOSA/SOSA/CMOSS connection

CMOSS is example of MOSA, which has become an imperative for all three armed services. On January 7, 2019, the DoD Service Acquisition Executives for the Army, Navy, and Air Force released a joint memo stating that MOSA-supporting standards should be included in all requirements, to the maximum extent possible.

“MOSA is a philosophy that says: ‘Thou shalt do it in accordance with an open approach.’ Standards like SOSA or Vehicle Integration for C4ISR/EW Interoperability (VICTORY) are instantiations to meet the need to use a modular open systems approach,” Jedynak explains. “MOSA is an approach and lots of standards fit within that umbrella.”

The Under Secretary of Defense “endorses MOSA as ‘an integrated business and technical strategy’ to achieve competitive and affordable acquisition and sustainment over the system life cycle,” Hutnan says. “In the development of DoD systems, MOSA is an acquisition and design strategy consisting of technical architectures, which adopts open standards and supports a modular, loosely coupled, and highly cohesive system structure.”

The Army’s answer to MOSA is CMOSS, which aims to consolidate warfighting capabilities. “CMOSS efforts are being led by the Program Executive Office for Command, Control, Communications-Tactical (PEOC3T),” Hutnan adds. “CMOSS is a MOSA that uses published standards – OpenVPX, MORA, VICTORY, Redhawk, etc. – as opposed to a vendor’s proprietary standards.”

The Air Force, for its part, created Open Mission Systems (OMS): “The OMS initiative leverages open standards such as SOA, UCI, and FACE – all for normalizing command and control mission information for avionics systems,” Hutnan points out.

The Navy’s version is Hardware Open Systems Technology (HOST), which divides hardware into three tiers: platform (airframe, vehicle), system enclosure, and boards. The latter two are subsets of OpenVPX, Hutnan notes.

“Each service made solid progress advancing open systems principles, but each achieved results through different stove-piped initiatives, often sharing common open standards like OpenVPX,” Hutnan says.

To bring all DoD service approaches to MOSA together, and to couple it with the Defense Industrial Base (DIB), the DoD solicited industry to get consensus on an integrated technical architecture. “The result was the formation of the Sensor Open Systems Architecture (SOSA) Consortium, which is managed by The Open Group,” Hutnan says.

The SOSA Consortium helps “the government and the DIB to collaboratively develop open standards and best practices – enabling enhanced, accelerated development, and deployment of affordable, interoperable sensor platforms and systems,” he adds.

“The SOSA standard effort is somewhat similar,” Jedynak says. “I want to be careful because I don’t want to speak on behalf of other people, but the people leading CMOSS connected with people leading open architecture efforts for other services, like the Air Force, and shared their experiences and lessons learned and asked: Could there be some synergy? And that’s where the people who started CMOSS helped kickstart the SOSA activities and then ‘aligned strongly.’” (Figure 2.)

[Figure 2 | The Curtiss-Wright CMOSS/SOSA Starter Kit (CSSK) is a pre-integrated four-slot SWaP-optimized 3U VPX system that combines a VICTORY network module (aligned with SOSA profile: 14.4.14 DP/CP Switch), A-PNT module (aligned with SOSA profile: 14.9.2 Radial Clock), single-board computer (aligned with SOSA profile: 14.2.16 I/O Intensive), and 3U VPX power-supply unit.]

Not everything is a perfect fit across standards, but more commonality exists than ever before. Some portions of CMOSS “are nearly in direct alignment with SOSA and need very little modification to fit in,” says Borton. “In other areas, SOSA decided to take a different direction, and a system will need some ‘parallel play’ going on.”

CMOSS influence on SOSA

SOSA adapts the best of many open architectures and standards. CMOSS is no ­different. “Plug-in card profiles were initially imported from CMOSS,” Borton says, and “the system management module was inspired by CMOSS concepts, and the front-end modules (emitter/collector and conditioner/receiver/exciter) use Modular Open Radio Frequency Architecture (MORA) as their communications technology binding.”

One important thing to keep in mind, Borton adds, is that while SOSA specifies components that can be together to make a sensor system, SOSA doesn’t specify the sensor system itself. “Those SOSA components, whether infrastructure or modular functionality, can reside side-by-side with non-SOSA components such as CMOSS,” he elaborates. “It’s up to the designer, with all of the factors they’re balancing, to determine how much SOSA (or CMOSS) a sensor system is comprised of.”

CMOSS appears to benefit everyone. “The government gets a stronger, healthier set of standards. And the industry gets more opportunities – essentially the pie is getting bigger,” Jedynak says. “There’s more alignment and it’s good for lots of players – including existing players within the VPX market, but also for smaller companies that want to provide a special technology to the battlefield without delivering an entire turnkey system. It opens up more opportunities for people to bring their solutions that fit into this building-block architecture. Instead of a winner-takes-all way of doing things, more people are involved because it’s more modular and an open standard.”

CMOSS-compliant product demand

Demand for CMOSS started picking up in 2018 and since then, requirements for CMOSS have only increased, according to SRC.

“Now we’re seeing CMOSS built into the solicitations for numerous ground vehicle programs such as Optionally Manned Fighting Vehicle (OMFV) and Terrestrial Layer System (TLS),” Borton says. “As a sensor innovator, SRC is involved with many of these programs. Also, Army Capability Sets introduce CMOSS requirements in their 2023 increment. Demonstration events such as Tri-Service Open Architecture Interoperability Demonstration (TSOA-ID) and Network Modernization Experiment (NetModX) further reinforce the importance of CMOSS.”

The Army is driving significant requirements for SOSA/CMOSS alignments into current programs needing tech upgrades and emerging “first start” programs, Hutnan says. “Programs on the Army’s list of ‘Top 31 +4’ modernization initiatives are seeing requirements for CMOSS in early requests for information and subsequent requests for proposals. Some examples of both Army Aviation and Ground Programs with emerging requirements for CMOSS alignment include Aviation/Air and Missile Defense – Future Vertical Lift, Rotary Upgrades (H-60, AH-64), Air & Missile Defense, Next-Gen Combat Vehicle, Abrams Upgrades, A-PNT, Long-Range Precision Fires (LRPF), and Directed Energy.”

CMOSS for embedded computing designs

CMOSS also affects embedded system designs. Backplane I/O composition “has the largest impact on embedded compute,” Borton says. “In the age of multichannel gigasample converters in one slot, getting the data in and out of the receivers/transmitter and the associated compute chains, and getting data in and out of plug-in cards, is fundamental.”

Each card has access to a typically full-star Ethernet link(s) to any other card within the chassis and more localized PCIe connectivity to several local card slots. “Depending on backplane configuration, the PCIe bandwidth may be greater than Ethernet can provide. This can greatly influence a system or card set design. Depending on which data movement path you take (and the sheer amount of potential receiver data) could drive a need to have enough compute in the slot to decimate the data down sufficiently before passing it on over one of those interfaces,” Borton notes.

In 2019, Abaco Systems decided to include SOSA/CMOSS alignment in its product roadmaps. “We now have a portfolio of 3U/6U VPX SOSA/CMOSS aligned offerings for single-board computers, graphics cards, digital signal processing, and networking,” he adds.