Common Issues in Late-Stage Defense Design

Defense requires a highly specialized Hardware-Software Co-Design approach: Thermal Management for Continuous Inference: AI accelerators (FPGAs, GPUs, ASICs) generate significant heat. Overheating rapidly degrades both the accelerator's performance and the stability of the nearby RF components. Action: Design the PCB with thermal vias and large copper pours beneath hot spots. Integrate a custom heat sink or, for high-power radar, a liquid cooling solution directly into the chassis mount to ensure the AI engine can sustain maximum computational throughput for extended missions. Phase II: Hardware-Software Co-Design for AI Implementation This is where the AI algorithm is tailored to the custom hardware architecture. AI Model Quantization and Optimization: Standard AI models (trained in Py Torch/TensorFlow) often use {32-}floating-point precision. Embedded military hardware typically uses or {16-\ integer precision for efficiency. Action: Perform quantization-aware training (QAT) to compress the model weights and activations, reducing the Memory Footprint and the required (Floating Point Operations). This makes the model feasible for deployment on resource-constrained Edge AI accelerators (e.g., custom ASIC or optimized FPGA logic). Data Path Optimization: The processing pipeline must be designed to minimize data movement. Approach: Implement a Direct Memory Access (DMA) pipeline where digitized radar data flows directly from the ADC to the AI accelerator memory without passing through general-purpose CPU cores. This allows the AI to perform real-time target detection and classification (e.g., identifying a threat drone vs. a bird) with ultra-low latency ({< 100 \{ ms}}$). Software-Defined Radar (SDR) and Adaptive AI: The AI isn't just for target classification; it controls the radar itself. Implementation: Use the AI output to dynamically adjust the radar waveform, Pulse Repetition Frequency (PRF), and beamforming parameters in real-time. For instance, if the AI detects jamming, it can instruct the SDR to switch frequencies or employ Space-Time Adaptive Processing (STAP) to filter out interference, making the radar system adaptive and resilient. Phase III: Integration and Verification The final step ensures the system meets strict defense standards {MIL-STD-810}$ for environmental stress and {MIL-STD-461} for EMI/EMC). Closed-Loop System Integration: Verify that the end-to-end latency—from radar signal reception to AI inference, to autonomous countermeasure decision—is met. This often requires specialized Hardware-in-the-Loop (HIL) simulations. Environmental Qualification: Subject the finalized PCB/System to rigorous testing (vibration, thermal cycling) to ensure the physical RF and digital components, including the solder joints, maintain integrity in harsh operational conditions. The modern defense approach requires the PCB designer to understand Deep Learning, and the AI engineer to understand.

Most defence innovation discussions still treat sustainment as a secondary issue. That is the problem. We talk about what systems can do, how fast they can be acquired, how cheaply they can be produced, and how impressive they look in demonstrations. But we rarely stay with the question long enough to ask what happens after those systems are actually used. Because that is where the real test begins. This piece looks at sustainment not as a support function, but as the condition that defines whether capability exists at all. It breaks down what happens after day one, when systems start to degrade, fail, and diverge from their initial state. When logistics are no longer predictable. When energy becomes a constraint. When software starts to drift. When recovery and repair determine whether something is lost or returned to use. The uncomfortable reality is that modern systems, especially autonomous and unmanned ones, do not reduce the sustainment burden. They increase it. More systems means more batteries, more updates, more configuration states, more spare parts, more logistics pressure, and more exposure to disruption. The idea that lower-cost systems can simply be replaced at scale ignores the practical constraints of moving, integrating, and sustaining them under contested conditions. And this is where most capability conversations still fall short. Attrition is treated as a problem to minimise rather than a baseline to design for. Repair is treated as secondary to replacement. Protection is focused on platforms rather than on the infrastructure that keeps them operational. Procurement evaluates entry, not endurance. But what decides outcomes is not what works once. It is what continues to function when conditions are no longer controlled, when losses are constant, and when the system is under pressure across every layer at the same time. Sustainment is not about keeping everything alive. It is about keeping enough of it working, trusted, and integrated to still matter. And that is not a technical problem. It is a system design problem. If we keep optimising for introduction instead of endurance, we will continue to mistake initial capability for real capability. And we will keep being surprised when it fades. #defenceinnovation #militarylogistics #autonomy #sustainment

"One by one, they started to fail." That's how a VP of Engineering described watching multiple satellite sensors fail critical tests. Each instrument—built by different contractors—passed initial checks but crumbled during thermal and vibration testing. The root cause? No thorough design reviews had been done early in the process. They'd inherited the sensors from another organization and never verified the review status. By the time problems surfaced in final testing, it was too late for simple fixes. "We were finding problems that should have been caught in design," she told me. The recovery effort became an all-hands scramble across multiple teams and contractors. This isn't just one program's nightmare—it's an industry-wide pattern. When hardware teams skip early verification steps or inherit "validated" designs without proper checks, expensive surprises emerge at the worst possible moment: final test. Question for the community: How many "inherited" designs have burned you in late-stage testing? What would catching those issues 6 months earlier be worth?

There is a lot of talk in the product development world about “shifting left”. That is, pulling risk forward in Stage Gate (from right to left). It makes a ton of sense – the whole point of Stage Gate is to address as many risks as possible early in the process. Yet, data from Siemens MBD maturity assessments shows that 30%-70% of program schedules and resource time are still consumed by late stage issues. Why do you think companies are struggling to pull risk forward – even when they are aware of the benefits? Here’s two drivers we see a lot in our work with dozens of F500 manufacturing orgs: 1- Design reviews are not robust enough The middle of Stage Gate (stage 2 + 3 in most processes) is really design review heavy. It follows that the amount of risk you can address in these stages is directly related to how robust your reviews are. We just ran a survey of 250 engineering leaders that confirms this: On average, leaders believe 59.6% of late stage errors could be prevented by significantly improving the quality of design reviews. 2- Cross functional stakeholders are not included in the early stages The reason that many errors aren't caught until the first builds is because that’s often the first time manufacturing and suppliers have a chance to provide feedback in a meaningful way. At best, in a typical environment, a supplier will do a review of a 2D drawing. But that often happens well after most of the review cycles (which all take place in 3D and are limited to people with CAD licenses). By democratizing access to CAD, CoLab is enabling our customers to bring cross functional stakeholders (inside the business and across the supply chain) into early reviews in parallel to the core engineering team. It sounds simple, but it’s consistently one of our customer’s most loved capabilities. Reviewing smaller bits early and in parallel is also the single biggest cultural change we see impacting velocity and quality. What are some other ways orgs are successfully shifting risk to the left? #engineering #stagegate #NPD