Embedded Compute Is the Other Bottleneck in Defense Autonomy

Embedded Compute Is the Other Bottleneck in Defense Autonomy

Ask a defense autonomy team what is holding them back and the answer usually points at the model. More data, a better planner, one more training run. For several years that was the honest answer. It is becoming less honest, because the algorithm now has to run on a particular board, inside a particular vehicle, on a battery, in weather, and return a result on a fixed schedule whether or not the result is any good.

We have made the case that actuation is where real-world robotics gets hard. Embedded compute is the companion constraint in the same stack, and it is the less photogenic of the two. Nobody films the compute module.

What follows is an industry-level argument built on public rulemaking and public law. It names no system, customer, or program.

A benchmark result is not a fielded capability

Perception and planning workloads are usually characterized on hardware with effectively unlimited power and a fan on it. Move the same workload onto something that drives or flies and four numbers start governing the design: watts available, watts you can shed as heat, the mass and volume of the enclosure, and unit cost at the quantity you actually intend to field. Defense acquisition calls this SWaP-C. It is not a checklist item at the end of the program; it sets the size of the model you are permitted to run at all.

The couplings are unforgiving. A more capable module draws more power, which shortens endurance, which forces a larger battery, which raises mass, which raises the actuator torque needed to move the thing, which draws more power. Thermal is harder still, since rejecting heat from a sealed enclosure into an environment you do not control is a mechanical problem with no software workaround. Teams regularly find that the accuracy they demonstrated on a bench is unreachable at the duty cycle the mission requires, and they find it late, once the chassis or the airframe is frozen.

Cost belongs in the same paragraph. Attritable systems are only attritable if the compute inside them is cheap enough to lose. The Department of Defense’s Replicator initiative, announced publicly in 2023 with the goal of fielding large numbers of all-domain attritable autonomous systems, makes that arithmetic explicit at scale. A compute module priced for a crewed platform prices the concept out of existence when the requirement is thousands of units.

Determinism is a different requirement than throughput

The second constraint draws less attention and causes more grief. A control loop does not care about average latency. It cares about the worst case, on every cycle, indefinitely.

Actuator control, state estimation, and safety interlocks run on hard deadlines measured in hundreds of microseconds. Miss one and the machine does something physical. Modern accelerators and general-purpose operating systems are built to optimize throughput, which they achieve partly by being unpredictable: caches, dynamic clocking, preemption, memory contention, thermal throttling. Every one of those is a mechanism for turning a good average into an occasional terrible tail.

The standard answer is partitioning. Put the hard real-time work on a processor whose timing can be reasoned about, put the inference work somewhere else, and define the boundary between them carefully. That instinct is correct, and the boundary is also where a great deal of integration risk collects, because someone has to reconcile the timing guarantees of two subsystems designed by people with different training. This is embedded engineering rather than machine learning, and those two disciplines are frequently not in the same building, sometimes not even in the same company.

The provenance question arrives at the silicon next

The third constraint is procurement, and it has a date on it.

Section 5949 of the FY2023 National Defense Authorization Act prohibits federal agencies from procuring electronic products or services that include covered semiconductor products from three named Chinese manufacturers, together with their subsidiaries and affiliates. The statutory effective date is December 23, 2027. The FAR Council published a proposed implementing rule on February 17, 2026 under FAR Case 2023-008; the comment period closed that April, and as of this writing no final rule has issued. None of this is legal advice. Read the statute and the proposed rule, then take the questions to your contracts people.

Scope is the whole story here. The prohibition does not stop at buying a bare part from a covered manufacturer. It reaches electronic products that include covered semiconductor products. On an autonomous ground or air vehicle that means the flight controller, the motor drives, the radios, the power management, the sensor front ends, and every microcontroller nobody has ever kept a list of. Answering it requires knowing what sits on boards you did not lay out, bought by vendors from distributors, several tiers below where your visibility currently stops.

Anyone who has started the analogous exercise on the mechanical side will recognize the shape of the work. The DFARS magnet restriction tightens on January 1, 2027 and asks essentially the same question about a different physical input. Two federal sourcing dates, not quite twelve months apart, both resolving to: name the origin of a part four tiers down. That is the provenance problem arriving at the two things an autonomous machine cannot be built without, which are the motors that move it and the computer that decides.

The supply side is moving as well, on a slower clock. The CHIPS and Science Act (Public Law 117-167) appropriated $39 billion in semiconductor manufacturing incentives and stood up a separate defense fund for microelectronics research and development. That is a considered bet that domestic capacity is a national-security input. Fabs take years to build and qualify. December 2027 is fifteen months out.

Firmware is part of the bill of materials

One more item tends to fall between organizations. A compute module is not only its silicon. It is a bootloader, an RTOS or hypervisor, vendor board-support code, and a stack of drivers and binary blobs that arrive with the part and are rarely read by anyone. Provenance analysis stops at the die if you let it, and the die is the wrong place to stop, because the code that runs before your code runs determines what your code is allowed to see.

Who wrote the bootloader. Whether the boot chain is measured. Who holds the signing key, and what an update looks like when the vehicle is in the field and the network is contested. This is ordinary bill-of-materials discipline applied to software, and most programs do not have the answers written down anywhere.

Why we work on this

Sentinel builds embedded compute for robotics under the PAS-EML program area, which exists because of the constraints above. Designing the compute alongside the actuation and the interfaces, instead of selecting it from a catalogue after the mechanical design is settled, means the power budget, the real-time boundary, and the parts list are decisions someone made deliberately and can account for later. We are asserting nothing about anyone’s compliance, our suppliers’ included. Provenance is documented delivery by delivery; it is not claimed in a blog post.

The general point survives without us. For the next two years, the thing most likely to stop a defense autonomy program is not the model. It is the board the model runs on, and a board cannot be retrained after the enclosure is closed.

Sentinel Automata is a U.S. robotics operating company.