Editor’s Note: This article was originally published in the March 2021 issue of JED. To read past issues in full, visit our magazine archive.
Since pretty much the beginning of the electronics revolution, all the military Services have struggled mightily to keep up with the pace of technology advancement and a constantly evolving enemy threat. Until recently, it has seemed to be largely an insurmountable task without an affordable solution in sight. Although open systems and open system architectures have long been touted as the only possibly successful approach, actual implementation of such pathways have been slow in coming. Today, that is changing, with the Army, in particular, charging ahead with a detailed and mandated new approach to designing, developing and fiielding new and upgraded capabilities through open architectures.
The C5ISR/EW Modular Open Suite of Standards (CMOSS) is the Army’s open system solution for embedded electronic system interoperability and reusability. Based on, and aligned with, the industry/government Sensor Open Systems Architecture (SOSA) consortium’s open standards “to enable, enhance and accelerate the deployment of affordable, capable, interoperable sensor systems,” CMOSS standards will be implemented in systems across the Army for all manner of applications.
CMOSS was started in 2013 by the Army’s Combat Capabilities Development Command (DEVCOM) Command, Control, Communications, Computers, Cyber, Intelligence, Surveillance and Reconnaissance (C5ISR) Center, formerly CERDEC. As emphasized by Ben Peddicord, Chief of the Intel Technology Architecture Branch of the C5ISR Intelligence and Information Warfare Directorate (I2WD), the fiirst important point to note about CMOSS is that it’s not a single standard but a suite of standards, covering everything from hardware form factors and interfaces for embedded computing, to cards and interfaces for RF resources, network connectivity, and all of the software frameworks that drive a host of new capabilities. As such, it in-corporates a number of standards including the Vehicular Integration for C4ISR/EW Interoperability (VICTORY) standard, OpenVPX backplane standard and the Modular Open RF Architecture (MORA) standard, as well as a number of software frameworks such as REDHAWK, the Software Communications Architecture (SCA), Photon, and the Future Airborne Capability Environment (FACE).
Jason Dirner, Architecture Team Leader in the Intel Technology Architecture Branch of C5ISR I2WD, is also a member of the SOSA Steering Committee. He adds that, the profiles being used in CMOSS are aligned with the profiles used in SOSA, as well as the profiles being used by the Navy as part of their Hardware Open System Technology (HOST) standard. The HOST standard development was launched by the Naval Air Systems Command (NAVAIR) in 2014, and is being used in the integrated core processor (ICP) of the F-35, as well as its panoramic cockpit display electronic unit (PCDEU). Says Peddicord, “We have had a strong partnership with the Navy since the start of the CMOSS effort. In fact, the Navy funded a lot of the initial S&T to develop these standards that we call CMOSS.” The Navy, as well as the Air Force, is also represented on the SOSA steering committee. SOSA was actually initiated by the Air Force’s Life Cycle Management Center (AFLCMC) (Wright-Patterson AFB, OH) in 2015. Says Dirner, “The goal has always been to get to the point where you can take the same board, whether a single-board computer or transceiver and use it across all three Services in order to get the reuse and economies of scale.”
A SUITE OF STANDARDS
In terms of hardware, CMOSS is built upon the OpenVPX VITA 65 standards, as well as some of the other VITA standards for certain hardware interfaces. It supports both 3U and 6U form factors plugging into a common ruggedized chassis known as the CMOSS Mounted Form Factor (CMFF). Peddicord notes that the majority of users are focusing on the 3U format. CMOSS also includes infrastructure support and profiles for items such as power supplies, internet switches, and Precision Navigation and Timing (PNT). As described by Peddicord, “In terms of general purpose payloads, we have one preferred profile that is suitable for embedded computing, including things such as processors, DSPs and FPGAs, and one for RF transceiver cards. The same slot is able to support either application simultaneously. Another kind of general-purpose slot would be most commonly used for an I/O intensive single-board computer, which is particularly useful when you have a lot of legacy platform I/O that you need to interface to.”
CMOSS also supports multiple software frameworks to provide reusability and portability of applications. This includes REDHAWK, which is a framework for Software Defined Radio (SDR) designed to support the development, deployment and management of real-time software radio applications that can be seamlessly deployed on a single computer or multiple network-enabled computers. The Software Communications Architecture (SCA) is an open architecture framework that defines a standard way for radios to instantiate, configure and manage waveform applications running on their platform and separating the waveform software from the underlying hardware platform.
The Future Airborne Capability Environment (FACE) is the open avionics standard for making military computing operations more robust, interoperable, portable and secure. Similarly, Photon is a common software framework already in use on some Army vehicles to provide portability of operations with use on many more platforms expected.
As stated by Peddicord, “We’re not requiring a specific software framework for all applications. So, while we’re making sure to provide explicit support and developing support for these portable reusable applications, we’re also allowing for the use of other frameworks as necessary. Also, we have some important software-defined interfaces, particularly for RF devices that fall under MORA that provide standardized ways to access RF resources on a platform. Within SOSA, there’s a working group dedicated to software interfaces, and we’re participating in that – trying to evolve and grow and deepen support for software interfaces.”
Besides hardware and software interoperability, another pillar of CMOSS and SOSA is network interoperability. Says Dirner, “With CMOSS, we’ve adopted the Vehicular Integration for C4ISR/EW Interoperability (VICTORY) standard that provides network-based interoperability using share services, such as Time and Position.That standardizes how services can be discovered, monitored, managed over a network, and how data such as PNT can be shared. MORA, which provides a standardized way to access and control RF resources, was developed as an extension to VICTORY for those network-based interfaces.”
CMOSS MANAGEMENT
As explained by Peddicord, the Army worked with the Navy, Air Force and industry to establish SOSA for the long-term management and development of the standards that would be utilized within CMOSS and to make them sustainable over the long haul. “But, although we transitioned our standards and specifications from S&T development to the SOSA Consortium,” he said, “we retained the CMOSS name, as it provides us the flexibility to meet and address Army program office requirements and timelines that a consortium cannot necessarily guarantee.”
The specific CMOSS implementations of SOSA standards are managed by the CMOSS board of directors, which was established last year. In addition to the DEVCOM C5ISR Center and Program Executive Office Electronic Warfare & Sensors (PEO IEW&S), the board includes senior leaders from: Program Executive Office Command, Control, Communications – Tactical (PEO C3T); PEO Ground Combat Systems (PEO GCS); PEO Soldier; PEO Combat Support and Combat Service Support (PEO CS&CSS); Network Cross Functional Team (N-CFT); Assured Positioning, Navigation and Timing/Space Cross Functional Team (APNT/S CFT); US Army Communications – Electronics Command (CECOM); and Army Test and Evaluation Command (ATEC).
Under the CMOSS BOD are two working-level Integrated Project Teams (IPTs) that execute strategy for the board and manage the CMOSS standards to ensure that the alignment between CMOSS and SOSA is maintained going forward.
Peddicord says there are multiple ways to evaluate and measure the progress of CMOSS acceptance and implementation, “but I would say, we have had for many years multiple demonstrations of capability implemented using CMOSS standards, and demonstrating real live interoperability on relevant applications within the environment. We also participate in events like the Tri-Service Open Architecture Integration Demonstration (TSOAID), where we show interoperability between standards-based implementations from all three Services.”
Other metrics include the acceptance and release of standards by the standards bodies that govern them, such as VITA and VICTORY. Peddicord says, however, that he believes the most important metric is the participation and implementation by industry and their use of the standards without government funding. “This is what we’re starting to see a lot of, with a rapidly growing catalogue and library of both hardware and software products which implement and offer the support for the standards. This makes it easy now for vendors and program offices to build solutions that are standards based. When you see vendors spending their own money, using their own IR&D and their own product development money, that is the strongest metric of successful progress.”
CMOSS IMPLEMENTATION
In terms of the current state of CMOSS implementation in the Army, Peddicord observes there are a number of programs that have explicit requirements for CMOSS with a newly approved requirement for CMOSS Mounted Form Factor (CMFF) through a Futures Command Abbreviated Capabilities Development Document (ACDD). The system incorporates mission command, communications and PNT, as well as EW. Peddicord says an office of primary responsibility has not yet been assigned for it, but “there are a number of program offices that have to work together to make it work – PM Tactical Radio, PM I2S, PM PNT, and PM EW&C. We’re currently working with all of them in planning for that implementation.”
Perhaps not surprisingly, the Army’s PM Electronic Warfare & Cyber (PM EW&C) within PEO IEW&S has taken a clear lead in the Army’s CMOSS implementation initiative with currently four Programs Of Record (POR) requiring its use. As described by COL Kevin Finch, EW&C Project Manager, “If you go back and look at a lot of the EW and SIGINT systems that we’ve fielded over the years, you’ll see that we ended up having an end-of-life projected way out into the future. At the same time, however, we were basically asking the vendors for a black box, so inevitably we ended up facing obsolescence or proprietary elements of the system that inhibited our ability to pace the threat. This framework, that we loosely refer to as CMOSS, is the key for us to be able to overcome this. It allows us to have a software backbone with hardware as a commodity. So, as technology improves, we can simply switch out those hardware elements.” From his point of view, Colonel Finch says he doesn’t view success as fielding a system able to meet today’s requirements. “It’s about being able to effectively upgrade these systems to meet the needs of those we will face 8-9 years from now and to provide seamless interoperability between systems.”
Colonel Finch reiterates Ben Peddicord’s point of emphasis that CMOSS is a suite of standards, and that there isn’t necessarily one overall Army standard. “You may need different parts of SOSA/CMOSS standards depending on what you’re doing,” explained Colonel Finch. As such, PM EW&C’s approach was to gather their engineers together to sort through all of the various standards available through CMOSS, and narrow them down to what is called the EW&C CMOSS standard. This incorporates the VICTORY, MORA, and 3U OpenVPX hardware elements of CMOSS, as well as software frameworks such as REDHAWK and Photon. PM EW&C signed a policy memorandum in 2019 that defined the EW&C CMOSS subset to achieve and ensure platform interoperability.
Colonel Finch describes EW&C CMOSS in terms of four main layers. The OpenVPX backplane layer of EW&C CMOSS defines only the use of the 3U form factor – dropping the 6U variant. Cards developed by third-party vendors according to the OpenVPX standard will be compatible with slots in the CMOSS chassis. But, depending on the application, backplane pinouts must also be correct and comply with a defined coaxial pin assignment for coherent operation across payloads (see Figure 1). Colonel Finch says “We’re already seeing industry do some really interesting things with these 3U cards, for example placing multiple capabilities on the same card.”
Fig. 1a: Payload 14 Position SMPM looking at front side of backplane US ARMY
Fig. 1b: Six (6) User Defined pins (A1, A2, A3, C1, C2, C3) for coherent operation across payloads (e.g., local oscillator distribution) US ARMY
The MORA standard interfaces allow for low-latency sharing of resources and also allow for efficient handling of analog-to-digital conversion. As stated in the EW&C CMOSS standard document, “MORA decomposes monolithic radio systems into high-level devices with well-defined functions and interfaces. Devices include Software Defined Radios (SDRs), RF Conditioning and Distribution (RDC) and Radioheads (RHDs). Signal resources, such as amplifiers, antennas, filters, switches, etc., as well as processing resources, must comply with defined MORA specifications.”
At the application layer level, the Photon software framework is currently being implemented or planned as the software backbone for the vast majority of EW and offensive cyber systems, particularly those performing a heavy level of signal processing.
Colonel Finch points to the communications layer as “the place where the magic really happens. There’s the VICTORY standard, which is really the vehicle plumbing piece and allows you to share PNT data. But, getting the data from Point A to Point B and being able to run on the tactical radio networks is critical to making sure that we have synchronization of capabilities on the battlefield through the Joint Capabilities Integration and Development System (JCIDS). At the Brigade or Division Tactical Operations Center (TOC), if you can’t effectively command and control your components on the battlefield and provide situational awareness in real time, you’re really missing what these capabilities are all about. The JCIDS 4.2 is a very important piece, and we also have a common data messaging format optimized for cyber/electronic warfare known as AppCEMA.”
FOUR PROGRAMS OF RECORD
Among the four PM-EW&C programs of record (PORs) currently implementing EW&C CMOSS is the Multi-Function Electronic Warfare-Air Large (MFEWAL), which provides Brigade Combat Team (BCT) Commanders with an organic airborne offensive EW capability. Developed by Lockheed Martin, the single self-contained EW pod is mounted on a General Atomics MQ-1C Gray Eagle Unmanned Aircraft System (UAS). Based on a Software-Defined Radio (SDR) /Digital Radio Frequency Memory (DRFM) architecture, MFEW-AL processes both The MFEW-Air Large pod will give Army Brigade Combat Teams a much-needed airborne EW capability. LOCKHEED MARTIN pre-programmed signal characteristic and real-time battlefield information.
Colonel Finch says, “Beginning in the fourth quarter of 2018, MFEW-AL was really the first program to implement the new standards with an actual CMOSS chassis out of the lab and operating in a relevant environment. Now we’re building Engineering Manufacturing Development (EMD) pods as we speak and look to go to test early in FY2022.”
TERRESTRIAL LAYER SYSTEM BRIGADE COMBAT TEAM (TLS-BCT)
The Terrestrial Layer System (TLS) is the Army’s next-generation tactical vehicle based system that delivers an integrated suite of signals intelligence, EW and offensive cyber capabilities for the Joint All Domain Operational (JADO) force. When fielded, TLS will be assigned to the Multi-functional Platoon and the EW Platoon organic to the Military Intelligence (MI) Company (MICO) in the Brigade Combat Team (BCT). As per the program description, “It is intended to provide critical situational awareness of the enemy through detection, identification, location, exploitation, and disruption of enemy signals of interest.”
The TLS-BCT program was started in FY20, and according to Finch, is currently past CDR for the B-kit of which the CMOSS chassis is a part. “It will be going out to Ft. Huachuca (AZ) in the second quarter of this year to demonstrate capabilities.” A First Unit Equipped (FUE) date is planned for FY22. In September, the Army said it was developing a larger variant of the TLS for Division-level units. Known as TLS-Echelon Above Brigade (EAB), the Army wants to field this system by the end of 2023.
The MFEW-Air Large pod will give Army Brigade Combat Teams a much-needed airborne EW capability. LOCKHEED MARTIN
Tactical Cyber Equipment (TCE)
Tactical Cyber Equipment (TCE) is a portfolio of systems for the 915th Cyber Warfare Battalion (CWB) to deny, degrade, disrupt, destroy or manipulate threats in support of tactical Cyber-Electromagnetic Activities (CEMA) operations. The back-packable TCE provides configurable spectrum survey and CEMA effects at the tactical edge through swappable capability cards integrated with EW&C CMOSS-compliant platforms, such as the TCE CMOSS Chassis (TCE-CC), MFEW-AL, and TLS. Says Colonel Finch, although the TCE is a man-portable system, operators will also be able to swap out their interoperable application cards with other CMOSS chassis aboard vehicles, such as the TLS, when greater power/range is needed. “We just had a Critical Design Review (CDR) and should have some early prototypes of the chassis in the late summer.”
The Terrestrial Layer System is currently in development with competing solutions from Lockheed Martin (left) and Boeing’s DRT Inc. LOCKHEED MARTIN AND DRT
The fourth POR is a classified CMOSS card to provide an offensive cyber capability. As observed by Colonel Finch, platforms such as the TLS must be able to integrate such capabilities. Being developed by CACI (Arlington, VA), Colonel Finch notes that “this effort, involving a third-party vendor, is an excellent example of the benefits of CMOSS. We didn’t team these guys up, but their card will be able to utilize and integrate with the standard OpenVPX backplane chassis. This is going to be a big milestone, really proving out CMOSS.” At the time of our discussion with him in January, Colonel Finch expected to get a prototype of the card in February, with testing beginning in the fourth quarter of 2021.
The Terrestrial Layer System is currently in development with competing solutions from Lockheed Martin (left) and Boeing’s DRT Inc. LOCKHEED MARTIN AND DRT
BALANCING TRADEOFFS
Although CMOSS is clearly providing great benefits, I2WD’s Peddicord points out that “standards and modular open systems don’t come for free. By definition, when you define and control interfaces, you constrain, to some extent at least, the solutions that are offered. We have certainly been aware of that and have been very successful in only defining interfaces that we have a really strong clear-government-use case for and where the cost-benefit ratio is good. Sometimes people have a misconception regarding how restrictive the standards actually are when, in fact, we’ve left the maximum amount of flexibility possible. We also have a very wide swath of industry participation, including both prime contractors and COTS suppliers, represented within SOSA in developing and agreeing to the standards. They all have a voice, and we’ve essentially had unanimity in the selection of the standards and interfaces that we control.”
Adds Dirner, “While we’re certainly extremely careful to not preclude systems from meeting operational requirements or stifling innovation within industry, it’s also important to remember that one of the benefits of CMOSS, and something we constantly strive for, is not just providing an open architecture, but a commonopen architecture – common not only within the CMOSS ecosystem, but across the community and other complementary standards like SOSA and HOST. In order to get that commonality, you inherently have to start restricting options so that you have the ability to share and reuse capabilities across programs and Services. Ultimately, that’s what is going to allow us as a community to be able to rapidly adapt to a new requirement or new threat, and to be able to hopefully leverage an existing capability, regardless of who developed it, and rapidly integrate it into a system to provide that capability to the soldier.”
Colonel Finch agrees, pointing out that “The big difference between having ‘a standard’ and a collaborative standard is having that open dialogue with industry. We’re not doing this in a vacuum. As commercial standards evolve, we can make the changes to the SOSA standard as well.” Colonel Finch also notes that “by providing an open-standard environment, and not providing capabilities in a proprietary format, we’re also lowering the entry barrier for smaller, thirdparty companies to participate.”
Peddicord sums up his view of the benefits of CMOSS by recalling that, “Coming into the Army as an engineer, I saw lots of exciting technology solutions that could be brought to bear to improve our fighting capabilities and protect our soldiers, but I was very frustrated with the timeline for development and fielding. Sometimes, by the time it actually got there, it was no longer even relevant, leading to a lot of obsolete technology in the hands of soldiers.
“CMOSS and other modular open system approaches, if they are actually meaningfully done, if they are sufficiently clear and defined to provide the access we need, will enable us to much more rapidly update, upgrade, and incrementally change and adapt our solutions. Ultimately, it’s really an important aspect of our ability to maintain parity with adversaries in a world where a lot of the most important technology is now commercially developed and where defense R&D budgets are not sufficient to allow us to be the leaders in many technologies.”
