search.noResults

search.searching

saml.title
dataCollection.invalidEmail
note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
THOR: Open-Architecture Edge


Computing for the Next Fight Solving the Tactical Computing Crisis in Degraded, Disconnected, and Contested Environments


The armored force is generating more data than ever — and losing the ability to act on it. Adversary jamming degrades satellite and network connectivity precisely when intelligence, targeting, and situational awareness are most critical. Sensor proliferation floods crews with information they cannot process fast enough to affect the fight. The result is a force that is data-rich and decision-poor at the worst possible moment. This paper examines those operational failures and the tactical computing requirements they impose — and outlines how THOR, Leonardo DRS’s SOSA-aligned 3U VPX embedded computing chassis, delivers the processing density, AI-enabled


Th d f i automation, and architectural flexibility to close the gap.


THE OPERATIONAL PROBLEM: DATA WITHOUT DECISIONS The character of ground combat has changed faster than the computing infra- structure inside armored vehicles. Today’s battlefield is defined by dense sensor networks, electronic warfare across the electromagnetic spectrum, AI-enabled adversary targeting, and multi-domain operations that compress the time avail- able for decision-making. Yet the comput- ing backbone inside many of the Army’s fighting vehicles was designed for an earlier era. The result is a compounding operational failure with three interlock- ing dimensions: the DDIL problem, the cognitive burden problem, and the legacy architecture problem.


The DDIL Problem: You Cannot Count on the Cloud


Modern warfighting concepts increas- ingly assume persistent connectivity – access to cloud-based processing, network-distributed intelligence, and reach-back to higher echelons. That as- sumption fails the moment a near-peer adversary engages. Degraded, Discon- nected, Intermittent, and Limited (DDIL) communications are not edge cases in peer competition; they are the deliberate operational outcome of adversary elec- tronic warfare, GPS jamming, and cyber effects against networked infrastructure. Adversaries have studied U.S. network -centric doctrine and have invested spe- cifically in the capability to deny it.


In a DDIL environment, a vehicle that de- pends on remote processing to generate


28


a common operating picture, classify a target, or execute an electronic warfare response is a vehicle that cannot do those things when it matters most. The proces- sing has to happen inside the vehicle – at the edge – without waiting for a network connection that may not exist. AI infer- ence, sensor fusion, and electronic war- fare decision logic must execute locally, on organic compute hardware, in the oper- ational environment that armored forces actually fight in. Any computing architec- ture that cannot do this is not designed for the fight the Army is preparing for.


The Cognitive Burden Problem: Crews Cannot Process What Sensors Produce


Sensor proliferation has outpaced the human cognitive capacity to exploit it. Modern armored vehicles are equipped with optical sights, radar, acoustic de- tection systems, electronic warfare re- ceivers, and networked data feeds that collectively generate far more information than any crew can process in a tactically relevant timeline. In high-intensity combat – with threats appearing, electronic sig- natures shifting, and the operational pic- ture changing faster than a commander can read a display – the volume of incom- ing data is not an asset. It is a liability.


When crews are consumed by the task of processing raw data, they are not fighting. The cognitive load of sorting sensor inputs, identifying threats from noise, and buil- ding situational awareness manually takes cognitive bandwidth away from the decisions that win engagements: where


to move, when to shoot, how to commu- nicate, and when to break contact. Every second a crew spends interpreting data is a second not spent acting on it. In peer conflict, those seconds are decisive.


The solution is automation. AI-enabled processing that classifies targets, flags anomalies, fuses disparate sensor feeds into an actionable picture, and surfaces the most relevant information – rather than all the information – directly reduces the cognitive burden on the crew. The computing system is not replacing human judgment; it is protecting it. It is ensuring that when the commander makes a decis- ion, that decision is based on processed, contextualized intelligence rather than unfiltered sensor noise. This requires computing hardware capable of running complex AI inference models locally, at the edge, in real time.


The Legacy Architecture Problem: Built for the Last Fight


Legacy computing platforms lack the processing headroom to support AI in- ference, real-time sensor fusion, and electronic warfare simultaneously. They were not designed for it – and no amount of software optimization changes the underlying hardware limitation. Beyond raw processing power, legacy systems carry closed, proprietary integration architectures that make every capability upgrade an expensive, time-consuming undertaking. Adding a new payload means redesigning integration layers, rewriting software interfaces, and requalifying the complete system – a process that takes


CAVALRY & ARMOR JOURNAL Spring 2026


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52