Why UAS Software, Not Hardware, Drives Real Advantage

The Investment Boom Has Outpaced Real Differentiation

Unmanned Aerial Systems (UAS) have gone from a specialist defense niche to one of the most crowded investment themes in the sector. Mainstream venture firms no longer need a contrarian bet to enter counter-UAS, sensors, effectors, or autonomy. That influx of capital is accelerating innovation, but is also producing copycats and narrowly differentiated products. As many platforms now share airframes, components, flight control foundations, and embedded hardware, their differentiation is increasingly perceived as residing in the autonomy or artificial intelligence layer added above that common engineering base.

However, one differentiator remains overlooked: the software stack.

Linux on a companion computer such as Raspberry Pi, a real time OS on the flight controller, flight software such as PX4 or ArduPilot, middleware such as MAVLink, vehicle parameters, and the autonomy layer on the higher levels. Each piece plays a different role, but together they determine how the aircraft senses, interprets, and responds. Two aircraft that look identical may have meaningful differences in this stack.

Why This Is a Problem

What I have witnessed: Across a series of joint exercises, aircraft were observed running PX4, ArduPilot, and proprietary flight control stacks with widely varying firmware versions and configurations. Even aircraft of the same model from the same manufacturer were sometimes evaluated without teams fully accounting for differences in firmware, parameterization, control logic, or software integration.

The engineers did their best, often pulling clues from dense logs under time pressure, and many issues seemed to be stemming from software rather than hardware, but the reality was that the troubleshooting was necessarily reactive.

The difficulty is that software problems are not always obvious in a test environment. Unstable flight, irregular power draw, inconsistent navigation, unexpected failsafe behavior, and degraded communications can all look mechanical or environmental at first glance. The real cause may be estimator settings, a firmware revision, parameter drift, or an interaction between the flight controller and the autonomy layer above it.

Yes, there are other variables such as vehicle loading, component wear, weather, RF interference, operator error, and manufacturing variation that still deserve consideration. The point is that variability in firmware and software configuration is often overlooked in UAS performance evaluation, and in the industry’s current state, difficult if not impossible to assess in a test environment.

The Solution: Normalization, not Standardization

Normalization would solve this.

Standardization – forcing a unified firmware standard – would be counterproductive to the innovation burgeoning within the industry. Different missions require different architectures, security models, control behavior, autonomy levels, payload integrations, and hardware constraints. A small reconnaissance aircraft, an autonomous interceptor, and a long endurance platform should not be expected to share the same software architecture.

Normalization would instead ask for a common framework for identifying firmware versions, software components, parameter configurations, message definitions, update histories, and known behavioral differences. Heterogeneous systems could become more observable and comparable without sacrificing architectural diversity or exposing proprietary source code.

A Normalization Framework for UAS Software

A normalization framework would capture, for each aircraft, the firmware identity, version, compatible hardware configuration, active parameter baseline, update status, known dependencies, and relevant behavioral changes. This information would allow teams to determine software baseline as a sounding board, a starting point from which engineers can analyze individual UAS performance. Such a framework could help distinguish between mechanical degradation, operator-induced stress, environmental effects, and software-driven irregularities.

It could also reduce unexpected command and control behavior, autonomous anomalies, and misleading comparisons between aircraft that appear identical, but are not functionally equivalent. Manufacturers have legitimate reasons to maintain their own firmware. OEM-specific software often reflects deep integration among the airframe, sensors, propulsion system, battery architecture, communications links, payloads, and onboard computers. Those software layers may represent real engineering differentiation and should remain under the control of the organizations responsible for validating and supporting them. Normalization should not be about firmware uniformity, but software traceability.

Fixing the Feedback Loop

An obstacle to creating the kind of normalization necessary for consistent evaluation across models is the limited feedback loop among test organizations, operators, and manufacturers.

Often, operational findings lead back to, and end at, prime or neo-prime, instead of propagating to the wider engineering ecosystem, which means they rarely shape firmware development, maintenance planning, or future configuration decisions. A working industry-wide feedback loop would improve sustainment by allowing telemetry and configuration data feed directly into readiness, reliability, and parts planning. Understanding how an asset is actually operated, and then connecting those operating conditions to component degradation, maintenance needs, and replenishment decisions is at the core of fleet sustainment.

Telemetry Alongside Normalization

In addition, normalization should function alongside telemetry analysis: one to establish how software was installed and configured; the other, to determine how the aircraft actually behaved. Decision-making, whether on maintenance or sustainment, begins with understanding how an asset is actually operated

This process must also function in data-scarce environments, where direct telemetry is incomplete. Machine learning proxies can help fill the gaps, identifying likely operating conditions, configuration differences, degradation patterns, and sustainment risks that warrant further investigation. These should not replace measured data or engineering judgment. Their value is in turning incomplete information into structured theses that can be assessed through a normalized framework, and that can be tested against future telemetry.

As UAS fleets grow larger and more heterogeneous, readiness will depend on understanding how hardware, firmware, configuration, operation, security, and logistics interact. The investment surge into this sector has made hardware differentiation nearly impossible to sustain, which means the software stack is where the real advantage is.

Normalization, as an assessment framework, can improve software visibility where required, while allowing innovation to flourish. It is the path forward to fleet readiness.

Hiram Mac is the founder and CTO of Mantis Technologies, a venture accelerated defense technology software company building the enterprise sustainment layer for unmanned and autonomous assets. His background spans quantitative finance in the hedge fund industry and AI native and algorithmic startups across life sciences revenue management and multi sector retail pricing optimization.