Why autonomy upgrades stall at integration – and how MOSA fixes it
StoryMarch 02, 2026
Autonomous operations can range from small drones to autonomous surface vessels, with the real competitive edge shifting from who builds the best platform to who can upgrade it fastest. Open architectures promise plug-and-play tech insertion – with the hard part being the “glue”: the interfaces, timing, thermal and power behaviors, and configuration control that decide whether a new payload, compute card, or comms module drops in cleanly or triggers months of requalification. Designs that take a modular open systems approach (MOSA) help solve those interconnect challenges.
Defense teams want a simple outcome: Keep the platform in service, then insert better technology as it becomes available – which is where a modular open systems approach (MOSA) comes in and why it was mandated by the U.S. Department of Defense (DoD). But many upgrade plans fail during integration. A module may meet a standard on paper, yet still cause timing issues, thermal stress, data mismatch, or power conflicts once installed.
That is the central challenge in autonomous systems. Airframes and hulls can stay in service for years, while compute components, software, and sensors can change every year. If an architecture cannot absorb fast subsystem change, programs lose time, money, and relevance.
This is why MOSA choices now shape every layer of design: single-board computers (SBCs), real-time operating systems (RTOS) platforms, connectors, and backplanes.
Starting with a stable platform
Mitch McDonald, president of Red Cat subsidiary Teal Drones (South Salt Lake, Utah), says that the Teal/Red Cat process begins with fixed interface boundaries.
“We design autonomous systems around stable, well-defined mechanical, electrical, and data interfaces so capabilities can evolve without redesigning the core platform,” McDonald says. “That discipline applies across our portfolio, from small UASs [uncrewed aerial systems] to maritime USVs [uncrewed surface vessels].”
He says that Red Cat treats the vehicle as the long-life baseline and updates mission technology inside controlled boundaries. “Our drones and maritime platforms are treated as durable baselines. The airframe or hull remains stable, while compute, sensors, autonomy software, and communications modules integrate through controlled interface boundaries.”
That model supports backward-compatible upgrades: McDonald points to new payload work that integrates with existing systems, so that users can improve capability without replacing the aircraft. He says the same approach extends to flight control, navigation, communications, and internal compute; these aspects also apply to the company’s Blue Ops maritime systems.
Leveraging open standards
This kind of technology implementation depends on concrete standards, says William J. Pilaud, chief solutions architect at LCR Embedded Systems (Audubon, Pennsylvania).
“For autonomous defense systems, the application of MOSA principles points to the SOSA [Sensor Open Systems Architecture, or SOSA, Technical Standard] and VITA 46/VPX architectures, open Ethernet-based data fabrics, and modular, container-friendly software frameworks,” he says.
Pilaud notes that standards also drive hardware selection decisions. “They directly influence hardware selection – driving the use of SOSA conformant single board computers; high-speed backplanes with deterministic, low-latency fabrics; and ruggedized connectors capable of supporting high bandwidth and harsh environments.”
RTOS design is changing
Hardware can be modular, but if software is tightly locked to one platform, upgrade speed still suffers. This design aspect, Pilaud says, means that open architecture changes how teams design real-time software stacks.
“An open systems approach fundamentally shifts RTOS design from tightly coupled, platform-specific implementations to modular, standards-based architectures,” he explains. “Instead of hardwiring applications to proprietary hardware, modern RTOS environments must support portable middleware, containerized services, and well-defined APIs that allow autonomy stacks to evolve independently of the underlying compute.”
Hard real-time behavior is still mandatory, he adds: “Deterministic performance remains nonnegotiable, but it’s now paired with partitioning, secure boot, and real-time virtualization. This enables mixed-criticality workloads – AI inference, sensor fusion, and control loops – to run concurrently while preserving timing guarantees and rapid upgradeability.” (Figure 1.)
The upshot? RTOS selection is now both a performance choice and a life cycle choice. In short, MOSA is not only a policy objective. It is a component-selection framework that helps keep future upgrade options open.

[Figure 1 | LCR Embedded Systems’ VE02 packs two 4-slot VPX/SOSA aligned payload sections into a single SAVE envelope for Army ground vehicles, with separate cooling paths and dual conduction-cooling/forced-air assist to support high-power size/weight/power (SWaP)-constrained applications. Courtesy of LCR Embedded Systems.]
Why integration still breaks
Even with robust standards and modern RTOS design, integration failures still happen. McDonald notes that the risk is concentrated where subsystems meet.
“Integration challenges typically appear at system boundaries,” McDonald says. “Even when components align to open standards, differences in timing, data formats, synchronization, thermal behavior, or fault management can affect system performance.”
He stresses the operational impact in autonomy programs. “Those boundary conditions directly impact perception accuracy, navigation stability, and command-and-control reliability.”
Pilaud describes the same issue from a VPX/SOSA perspective. “Even when SOSA/VPX modules and backplanes comply with MOSA principles, differences in firmware maturity, timing assumptions, thermal profiles, and power management can introduce subtle instability in tightly coupled autonomous systems,” he says.
Both Pilaud and McDonald call for strong integration discipline, with Pilaud recommending “rigorous interface control, conformance testing, and system-level validation,” and McDonald emphasizing “disciplined integration testing and configuration control” across power, thermal, software, and mission-data paths.
McDonald also points to IP-ownership risk at integration layers. “If interface definitions or integration layers are owned externally, iteration cycles can become dependent on third-party development timelines, which increases integration complexity and slows capability evolution.”
Connectors and backplanes are strategic choices
This boundary challenge leads directly to interconnect decisions. Rodney Doss, industry standards manager for Samtec (New Albany, Indiana), says connector choices are often set early because they define what the system can carry.
“Work groups often begin with connectors to understand the signal between module and backplane, then work their way back from there,” Doss says.
He says groups usually focus on three things: “performance, ruggedness, and availability.” In autonomy programs, that can quickly become a bottleneck.
“The complex and smart features of these systems require the highest performances available such as PCIe Gen 6, with as many pin counts as they can fit into the small spaces they have available,” Doss says.
He says open-standard connector definitions make module interchange possible across vendors. By designing in connectors, these standard definitions help in three ways.
“First, it defines the footprint and placement requirements of the board assembly so module designers know how much room they have to work with to design their widget,” Doss says. “Next, it solves the connectivity needs, so that a system integrator can trust a module will plug into their system regardless of vendor. Finally, it allows the groups to define the pin maps of the connector so that all modules will communicate the same within the system, even if their module works completely different internally.” (Figure 2.)

[Figure 2 | Samtec’s AcceleRate HD SI Evaluation Kit gives system designers and signal-integrity engineers a standalone, robust test platform for characterizing AcceleRate HD high-density 4-row strip connectors in high-speed, high-cycle applications. Courtesy of Samtec.]
MOSA and SWaP discipline
Once interconnects and interfaces are stable, MOSA can support another major need: controlling size, weight, and power (SWaP). Autonomous platforms cannot absorb unlimited SWaP growth, and Teal’s McDonald says that MOSA helps teams avoid that trap.
“MOSA helps prevent overbuilding and uncontrolled growth,” he says. “Not every drone or USV needs to carry every capability, and not every improvement should require structural redesign.”
He describes, for example, battery upgrades that improve performance while preserving the existing interface, or maintaining payload modularity across multiple airframes through common boundaries.
Pilaud makes the same point at system scale. “MOSA principles help manage SWaP constraints by enabling modular scaling rather than overdesign. Instead of building monolithic systems sized for peak future requirements, open architectures allow designers to rightsize compute, I/O, and acceleration at the module level.”
Life cycle relevance over decades
When upgrades stay inside defined subsystem boundaries, programs can add capability without triggering platform-wide redesign. For program offices, life cycle value is often the strongest MOSA argument.
“Life cycle management is central,” McDonald says. “Airframes and maritime vessels may remain in service for many years. Sensors, compute hardware, autonomy software, and communications systems evolve much faster.”
He says that stable interfaces support incremental modernization, which can reduce recertification scope and limit operational disruption.
Pilaud adds that an open systems approach “keeps autonomous systems relevant by decoupling platform life cycles from technology-refresh cycles.” He says that this approach supports module-level insertion of new processors, artificial intelligence (AI) accelerators, and networking technologies without the need for full redesign.
Today’s defense industry recognizes that standards are essential, but they are not enough by themselves. Programs also need clear interface ownership, strong configuration management, and disciplined validation.
“MOSA increases flexibility and accelerates capability growth, but it requires disciplined systems engineering, clear interface ownership, and strong configuration management to ensure the full system performs reliably and remains upgradeable over time,” McDonald says.
The Black Widow short-range reconnaissance drone was built on modular open systems approach (MOSA) principles. Courtesy of Red Cat.
