NASHUA, N.H. - For years, the military electronics industry's discussion of open architectures has centered on a relatively straightforward proposition: Defense systems should not be locked into a single supplier's hardware, software, or proprietary interfaces.

That proposition is now moving into a more complicated phase.

Open architectures are moving beyond standards development and demonstrations into production, flight testing and deployment activities. At the same time, the electronics inside those systems are becoming substantially more demanding. Direct radio frequency (RF) processing, high-speed networking, artificial intelligence (AI), heterogeneous computing, dense FPGA resources and increasingly sophisticated cooling architectures are putting new demands on the physical standards that make modular systems possible.

And not every military system has the same requirements. A rugged combat vehicle, a long-life aircraft, a small uncrewed aircraft and a commercial-derived robotic system can have radically different requirements for size, weight, power, cooling, sustainment and technology refresh.

The result is a more fundamental question for military electronics engineers: How open does a system need to be, and what does "open" actually mean?

New Department of Defense (DoD) guidance offers a useful starting point. Standardization Decisions for a Modular Open Systems Approach, or SD-28, describes standards as enablers of a Modular Open Systems Approach (MOSA), rather than as an objective in themselves.

The document identifies five MOSA principles, including modular design, defined key interfaces, the use of widely supported consensus-based standards, and certification of conformance. It also makes clear that an open standard by itself does not create a MOSA system. The architecture, interfaces, technical data and licensing rights must also support the intended objectives.

In other words, the goal is not simply to make military electronics conform to more standards. The goal is to create systems in which modules can be changed, upgraded and supplied by multiple sources without forcing the government to redesign the entire system.

From architecture to infrastructure

The Army's Common Modular Open System Standards (CMOSS) Mounted Form Factor (CMFF) illustrates where the concept is heading.

The Army is developing a common chassis and associated capability cards intended to replace some of the separate, stovepiped electronics boxes traditionally installed on combat vehicles. The architecture is intended to accommodate capabilities such as communications, electronic warfare, command and control, and assured positioning, navigation, and timing.

The Army has tied CMFF development to MOSA and Sensor Open Systems Architecture (SOSA) standards to help ensure that capability cards and chassis can interoperate and that multiple vendors can participate in future capability development.

That is an important transition. An open architecture is no longer merely a desirable characteristic in a requirements document. It is becoming part of the infrastructure through which the military develops, integrates, and upgrades electronics.

The Air Force's Collaborative Combat Aircraft (CCA) program provides another example, although at a very different level of the system hierarchy.

The Air Force has implemented the government-owned Autonomy Government Reference Architecture across multiple CCA vendor platforms. RTX's Collins Aerospace and Shield AI have integrated the architecture into mission-autonomy systems associated with the YFQ-42 and YFQ-44, respectively, and the Air Force has used flight testing to demonstrate that mission software can be decoupled from specific vehicle hardware.

For Chris Fadely, computer software engineer and manager of EIZO Rugged Solutions, the distinction between platform classes is becoming increasingly important.

"There is a clear shift in prioritization over to smaller compute platforms to complement the highly interoperable ecosystem already defined by VPX," Fadely says.

VPX, he says, will continue to have an important role in demanding environments, but that does not mean every platform should automatically adopt the same architecture.

"While VPX will continue to be the sweet spot when it comes to rapid iteration in truly rugged environments, there are environments where the economics and risk assessment simply do not justify its use," Fadely says.

That distinction could become increasingly significant as military programs expand the use of smaller uncrewed aircraft and robotic platforms. The engineering priorities of those systems can differ substantially from those of platforms expected to remain in service for decades.

"There are times to plan for long-term stability and sustainment, and times where the urgency dictates us to deploy new capabilities much faster," EIZO's Fadely says.

Some programs need decades of support and backward compatibility. Other systems may be designed around shorter development and technology cycles in which rapid insertion of new computing, sensing, or autonomy capabilities is more important.

"Open architectures need to not just support both models, but also clearly define when an architecture should be used," Fadely says. "There can’t be a single standard to rule all mission sets."

The hardware is getting harder

Platform differences are only part of the challenge. At the electronics level, open architectures are also facing increasingly demanding processing requirements.

Craig Petrie, vice president of Molex's Aerospace & Defense Solutions division, sees technologies increasingly converging.

"There is a convergence of compute, FPGA, and Direct RF," Petrie says. He describes open standards evolving "from single-function payload profiles toward unified, ultra-high-density architectures, typically for harsh-environment applications."

High-throughput backplane optical and RF interconnects are helping connect those processing resources. Petrie points to VITA 66, VITA 67 and VITA 87, along with high-speed Ethernet data planes and the longer-term VITA 100 family.

The result is an architecture in which direct-RF sampling FPGAs can feed x86 processing resources across high-speed data planes rather than treating each processing function as an isolated subsystem.

Petrie also sees open architectures moving into smaller form factors.

"Beyond standard 3U/6U OpenVPX, open-standard architectures are pushing down to SFF standards, including VNX+ (VITA 90) to bring MOSA compliance to dismounted warfighters, UAVs, and space-constrained tactical edge payloads," he says.

VNX+ illustrates the effort to extend modular open architectures into smaller, SWaP-constrained systems while retaining defined mechanical, electrical, optical, and RF interfaces.

That trend illustrates one of the central challenges facing open systems: Standards have to keep pace with electronics while remaining practical for the platforms using them.

At the same time, higher processing performance creates physical problems that an interface specification alone cannot solve.

Petrie says customers have shifted from prioritizing raw compute performance at any cost toward "strict SWaP-C optimization (Size, Weight, Power, and Cost)," along with standardized cooling and other system-level considerations.

Thermal management is becoming particularly important as processors and FPGAs become more powerful.

"Pushing high-power embedded x86 processors alongside dense FPGAs stretches traditional conduction cooling (VITA 48.2) to its limits," Petrie says, "necessitating wider adoption of liquid cooling (e.g., VITA 48.4/48.8)."

The problem is not simply one of adding more processing capacity. Engineers must fit power delivery, high-speed signaling, thermal management, mechanical packaging, and electromagnetic performance into standardized envelopes.

The evolution of interconnects illustrates the same problem. The VITA 46.32 effort is addressing VPX connectors capable of supporting data rates to 53 gigabits per second for protocols including 200GBASE-KR4 Ethernet and PCI Express Gen 5.

As data rates continue to increase, the physical interconnect becomes an increasingly important part of the open-system architecture. Molex's Petrie expects the evolution to extend beyond conventional copper connections.

"As backplane speeds transition toward 100G/200G per lane and VITA 100 implementations, standard copper trace physics hit loss barriers," he says, "requiring standardized optical engines integrated directly on-package."

From interchangeable hardware to distributed systems

The evolution of open systems also is changing what engineers mean by modularity.

The early promise of open systems was often expressed in terms of hardware interchangeability: remove one card and install another; replace one supplier's module with another supplier's compliant module; upgrade a processor without redesigning the entire chassis.

Those capabilities remain important, but modern military systems increasingly depend on software, networking and heterogeneous computing as well as physical modules.

Petrie identifies "Heterogeneous AI/ML orchestration" as an emerging requirement. Existing profiles can accommodate discrete processing cards, he says, but dynamic workload balancing among x86 processors, FPGAs and dedicated AI accelerators creates requirements for higher-level software and middleware standards.

The Air Force's CCA effort provides a related example at the platform level. The government's Autonomy Government Reference Architecture is intended to separate mission autonomy software from particular aircraft, allowing software capabilities to move across different vehicle architectures.

Fadely sees the same broader change emerging from the intersection of military autonomy and commercial robotics.

"SOSA focused heavily on the lower-level hardware interactions while also trying to accommodate the wider interactions between systems and software as it is defined today," he says.

Looking ahead, Fadely argues that the defense industry needs to examine developments in commercial robotics and consider how those technologies might fit into military architectures.

"I think more focus needs to be placed on where robotics in the commercial space are heading and how we can better adopt those technologies," says the EIZO engineer.

He sees an increasingly important distinction between traditional uncrewed military platforms and the rapidly developing commercial robotics market.

"While both are still in their relative infancy, the wall between what we traditionally call an 'unmanned' and what the commercial world increasingly considers a 'robotics' needs be better explored and defined," Fadely says.

That distinction is likely to matter because commercial robotic systems can evolve according to very different cost and technology-refresh assumptions than traditional defense platforms.

For Fadely, the result is a gradual expansion of what open architecture needs to accomplish.

"Over the next three to five years, I expect open standards to increasingly move beyond defining interchangeable hardware and toward enabling modular, distributed, software-defined and autonomous systems," he says.

Putting open systems to the test

Perhaps the most significant development for current open architectures is less about a new connector or standard than about the transition from development to actual use.

Several military programs designed around SOSA and CMOSS specifications from the beginning are moving from development toward initial production and deployment. That will give the industry something it has largely lacked during years of standards development: substantial feedback from systems operating under real program and mission conditions.

Fadely describes the transition as a key moment for the open-systems community. He notes that the industry is reaching an important point as mission systems designed around these concepts from the beginning begin moving toward "first real-world shipments."

The significance is not simply that systems built around open standards are entering production. Operational use will begin to expose where the standards work well, where they create unnecessary constraints, and where specifications need refinement.

"That means we are going to start receiving much more meaningful real-world feedback," Fadely says, "and there is bound to be important items encountered which can hopefully further refine the specifications in the future."

That feedback loop may be particularly important as engineers attempt to balance standardization against rapidly changing technology.

"While the runway has been cleanly laid out with years of preparation, only once the systems are being used in their actual environment will we see where we stand," Fadely says.

The DoD's SD-28 guidance points in a similar direction by identifying certification of conformance as one of its five MOSA principles. An open standard that exists on paper but does not produce interoperable implementations does not necessarily deliver the intended benefits of modularity, competition, or technology insertion.

At the same time, standards cannot remain static while the underlying electronics change.

Petrie's comments on high-speed interconnects, optical connectivity, cooling and heterogeneous processing illustrate how quickly the physical and computational requirements of military electronics are changing. 

Fadely's distinction between long-life, highly rugged systems and smaller, rapidly evolving platforms gets to the heart of that issue. A system expected to remain in service for decades may place a premium on backward compatibility, configuration control, and long-term sustainment. A smaller autonomous platform may place greater value on rapid technology insertion and the ability to adopt new commercial-derived computing and sensing capabilities.

Standards such as SOSA and CMOSS are moving into real systems. Interconnect and cooling standards are evolving to accommodate increasingly demanding electronics. Smaller form factors are extending open architectures toward tactical-edge and autonomous applications. Software is also becoming a more important part of the definition of modularity.

The result is not a single architecture for every military system. Instead, open systems are becoming a way to manage very different kinds of change.