years and consumes resources the pro- gram cannot afford.


The operational consequence is a force that conceptually understands Multi-Do- main Operations but cannot execute its digital requirements at the vehicle level. The doctrine is right. The computing infra- structure is not.


WHAT THE ARMORED FORCE ACTUALLY REQUIRES


Closing the gap between operational re- quirements and vehicle-level capability demands computing infrastructure that meets five criteria simultaneously – not as aspirational goals, but as fielded per- formance specifications:


First, edge processing autonomy. The sys- tem must execute AI inference, sensor fusion, and electronic warfare logic lo- cally – without network connectivity – because DDIL environments are the operational baseline, not the exception. Cloud-dependent architectures are not viable for armored force operations against a peer adversary.


Second, AI-enabled cognitive offload. The system must automate the data pro- cessing burden that currently consumes crew attention: classifying sensor returns, prioritizing threats, fusing multi-source inputs into an actionable picture. The crew’s cognitive bandwidth is a finite war- fighting resource. The computing system exists to protect it.


Third, processing density within SWaP constraints. The system must deliver GPU -class AI inference, high-throughput


sensor fusion, and signals processing – simultaneously – within the size, weight, and power envelope that armored vehi- cle design permits. Performance that can- not fit in the vehicle is not performance.


Fourth, open-architecture modularity. The system must allow new processors, accelerators, and mission payloads to be integrated as the threat evolves – with- out chassis redesign or full system re- qualification. Technology insertion that takes years is not insertion; it is obso- lescence management.


Fifth, survivable military qualification. The system must function through the shock, vibration, electromagnetic interference, and power transients that define armored vehicle operations. Commercial hardware engineered for controlled environments will not survive contact.


THOR: THE OPEN-ARCHITECTURE ANSWER


Leonardo DRS developed THOR – Tacti- cal, High-Performance Embedded Com- puting, Open Architecture, Rugged – to answer each of these requirements di- rectly. THOR is a SOSA-aligned 3U VPX embedded computing chassis designed around open commercial standards and qualified for deployment in the most de- manding operational environments – from armored vehicles and tactical platforms to other rugged government and industrial applications. It is high-performance edge computing infrastructure, engineered to the environmental and performance de- mands of operators who cannot afford the system to fail.


THOR AT A GLANCE


Form Factor: 3U VPX Embedded Com- puting Chassis


Architecture: SOSA-Aligned, MOSA- Compliant


Internal Data Rate: Up to 100 Gbps


Compute Support: Intel, Arm SBCs; AI/ ML GPUs; RF/DSP modules


Standards: MIL-STD-810 · MIL-STD- 1275 · MIL-STD-461 · ATPD-2404


Configurations: Configurable Chassis Kit | Fully Integrated Subsystem


Applications: AI targeting, sensor fusion, EW, C2, secure communications


Processing at the Edge – Without the Network THOR’s core design principle is that the vehicle must be computationally self-suf- ficient. In a DDIL environment, the chassis executes the full range of AI inference, sensor fusion, and electronic warfare processing on organic compute hard- ware – no cloud dependency, no reach -back requirement, no degraded mode. The chassis supports Intel®, Arm®, high- performance GPU accelerators for AI and machine learning inference and RF and digital signal processing modules for EW and secure communications. Internal data rates reach up to 100 gigabits per second, providing the throughput required to process, fuse, and present sensor data at the pace of contact rather than lagging behind it. When the network goes down, THOR keeps working.


Spring 2026 CAVALRY & ARMOR JOURNAL


29


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