The Thermal Management Requirements Gap: Why Thermal Is Still Treated as an Afterthought in Early Systems Engineering

A power electronics engineer at a major defense prime once described the moment he knew the program was in trouble: “We had just finished the preliminary design review, and the thermal engineer walked into the room with a spreadsheet. He said he’d run the numbers on the architecture we’d locked, and the junction temperatures on three of our FETs would exceed spec in the sustained engagement scenario. We had six weeks to CDR.”

The architecture didn’t change. The program absorbed an unplanned redesign of the cooling circuit, added a cold plate that violated the original mass budget, and delivered six months late. The thermal engineer had been on the team the entire time. He just hadn’t been in the room when the architecture was decided.

This story is not unusual. Across aerospace, defense, and EV programs, thermal management is systematically underspecified at the system requirements level — and then emerges as a major design driver during detailed design, precisely when changing architectural assumptions is most expensive. The thermal problem isn’t primarily technical. It’s a requirements problem.

What “Underspecified” Actually Means

When systems engineers say thermal requirements exist early in a program, they usually mean one of three things: a maximum operating temperature pulled from a predecessor program, a general statement about compliance with MIL-STD-810 or equivalent, or a thermal dissipation budget allocated from a power budget without tracing back to mission scenarios.

None of these are adequate as system-level thermal requirements.

A system-level thermal requirement has to specify what the system must do thermally, under which operating conditions, for how long, and with what margin. It has to be traceable to a mission or use case. It has to be allocated — meaning the system-level budget is decomposed to subsystems in a way that accounts for interactions, not just summation. And it has to be verifiable, which means there’s a defined test or analysis method attached to it.

What programs typically capture instead is something like: “The system shall operate within a temperature range of -40°C to +85°C.” That sentence appears in thousands of requirements documents across the industry. It defines an environmental envelope. It says almost nothing about how the system generates, moves, or rejects heat — or whether the architecture chosen can actually survive under the thermal loads the mission will impose.

A thermal engineer who has worked on multiple defense electronics programs put it plainly: “The environmental temperature spec is the beginning of the thermal requirements conversation, not the end of it. We need to know the power dissipation profile across every operating mode, the duty cycle for sustained operations, the airflow and mounting assumptions, and the allowable junction temperatures at the component level. None of that makes it into system-level requirements on most programs. We get it later, from the hardware team, when they’re already making decisions.”

Why This Happens: The Organizational Root Cause

The deferral of thermal requirements isn’t negligence. It follows from how systems engineering organizations are structured and how requirements authorship is assigned.

Systems engineers who own concept development and requirements capture typically have backgrounds in systems architecture, control systems, or software. Thermal analysis requires specialized expertise — heat transfer, fluid dynamics, materials — that sits in a dedicated thermal or mechanical engineering function. Because thermal engineers are specialists, they’re consulted rather than embedded in the early requirements process. They come in when there’s something to analyze, not when there’s something to specify.

The result is a structural lag. System requirements are written by people who don’t have the thermal background to write them well, and reviewed by thermal engineers who arrive after the document is baselined. The thermal engineers then inherit those requirements as constraints, rather than shaping them as authors.

This lag is amplified by tooling. In most programs, system requirements live in documents — Word, PDF, or a document-centric requirements management tool like IBM DOORS. These tools are organized around sections and paragraphs, not around system behavior or cross-domain relationships. A thermal requirement that needs to trace to a power dissipation estimate, a mission scenario, a packaging constraint, and an environmental specification simultaneously is nearly impossible to manage in a document structure. So it doesn’t get managed that way. It gets written as a sentence in Section 3.4 and decoupled from everything that would give it engineering meaning.

The Aerospace Pattern: Frozen Architecture, Late Thermal Surprises

In aerospace programs — particularly in avionics and power management systems — the thermal problem typically surfaces at PDR or CDR. By that point, the system architecture is established: card and chassis configurations are defined, interconnects are laid out, cooling approach (conduction, forced air, liquid) is selected. What’s not fully characterized is the thermal behavior of the architecture under the full range of mission profiles.

The analysis that would have flagged the problem — detailed thermal modeling of the power dissipation under sustained high-load scenarios — wasn’t completed before the architecture was locked because the power dissipation estimates weren’t stable enough to drive it. And those estimates weren’t stable because the requirements didn’t define the operating modes clearly enough to drive power budgets. The gap traces back to the requirements phase every time.

One avionics systems engineer described the pattern: “We’d do a thermal assessment in early concept, but it was based on historical data from similar systems. The assumption was that if we were in the same ballpark on power density, we’d be thermally similar. Then detailed design starts, and the actual power maps look different from the historical reference, and suddenly we’re chasing margin we don’t have.”

The downstream cost in aerospace is not just schedule. It’s mass. When thermal requirements aren’t established early enough to drive architecture, teams add thermal mass late — heat spreaders, additional cold plates, interface materials — that weren’t in the weight budget. On weight-critical platforms, those additions cascade into structural and propulsion impacts that multiply the original cost.

The Defense Electronics Pattern: SWaP-C Collisions

Defense programs have a thermal problem that aerospace programs share but rarely state as directly: the Size, Weight, Power, and Cost (SWaP-C) constraint is set at the program office level, often before thermal implications are understood, and then treated as inviolable through requirements.

The power constraint in SWaP-C is a thermal constraint. Power that the system consumes becomes heat that the system must reject. If the power budget is set without modeling what that power level means for the thermal architecture — at the specific form factor, in the specific mounting and airflow environment — then the SWaP-C requirement is specifying something the thermal architecture may not be able to satisfy.

This collision happens on nearly every program where SWaP-C is aggressive. The requirement is allocated, a design is built to meet it, and the thermal engineer runs the numbers and finds that the power the system is allowed to consume cannot be safely rejected at the required junction temperatures without a cooling approach that violates the size or weight constraints. Something has to give, and by the time the analysis confirms it, the program has already committed to a direction.

A thermal engineer who has supported multiple airborne defense electronics programs described this directly: “SWaP-C is set by operational requirements. I understand why it’s treated as sacred. But if you give me a 2U chassis with a 300W power budget and tell me it needs to operate at 70°C ambient with conduction cooling only, I can tell you before you write a single line of code or spin a single board that you have a problem. The physics don’t negotiate. But I need to be in the conversation before the number is set, not after.”

The EV Pattern: Cell-Level Thermal Requirements Missing from System Architecture

Battery electric vehicle programs present a version of the same problem with different physics. In EV development, the battery thermal management system (BTMS) is a significant architectural element — it influences packaging, electrical architecture, fluid routing, and software. Getting it right requires thermal requirements that are grounded in cell-level behavior under the full envelope of charge and discharge cycles, ambient conditions, and aging states.

What typically happens instead is that the system-level thermal requirements for the battery system are driven by cell manufacturer datasheets and general limits on cell temperature during charge and discharge. These are necessary but insufficient. They don’t capture the spatial temperature gradients across the pack under high-rate discharge, the behavior of the thermal interface materials over thousands of cycles, or the interaction between battery thermal management and cabin HVAC under competing load conditions.

When these gaps reach detailed design, the consequences include repackaging of the module layout to address hotspot distributions, redesign of the cooling plates, or, in the worst cases, late discovery that the thermal architecture can’t meet the fast-charge temperature constraint at end-of-life without active pre-conditioning — a feature that wasn’t budgeted into the power management software.

A principal engineer at a North American EV startup described the organizational version of this problem: “The battery team and the thermal systems team were working from different documents. There wasn’t a shared model. We found out at the cell testing phase that our cooling plate design had optimized for average temperature rise, but cell-to-cell gradient under the 2C discharge condition was outside spec for three of our module configurations. That drove a redesign that cost us four months.”

What a Proper Thermal Requirements Approach Looks Like

Fixing the thermal requirements gap doesn’t require new physics. It requires treating thermal as a first-class system-level concern from the first day of requirements capture.

Start with thermal scenarios, not thermal limits. Before writing a thermal requirement, define the thermal scenarios: what operating modes exist, what power dissipation each mode produces, how long each mode is sustained, and what the ambient conditions are across the mission envelope. These scenarios should be captured at the system level and traced to mission or operational requirements. Every thermal requirement should reference the scenario it’s derived from.

Allocate thermal budgets to subsystems before architecture is frozen. Once system-level thermal scenarios are defined, the heat rejection budget should be allocated to subsystems using the same discipline applied to power budgets or mass budgets. That allocation should account for thermal interactions — you can’t independently allocate thermal margin to two subsystems that share a heat path. The allocation exercise will expose architectural constraints early enough to influence decisions.

Embed thermal engineers in requirements authorship. The organizational fix is as important as the technical one. Thermal engineers should be co-authors of system-level requirements that have thermal implications, not reviewers of documents drafted by others. This requires deliberate process change and management support.

Make thermal requirements traceable and bidirectional. A thermal requirement that isn’t traced to the mission scenario that drives it, the subsystem that must satisfy it, and the analysis method that verifies it is a sentence, not a requirement. Modern graph-based requirements management tools make this traceability tractable in a way that document-based tools cannot. When a thermal requirement changes — because the power budget shifts or a new operating mode is added — a connected model surfaces the downstream impacts immediately. A document doesn’t.

Tools like Flow Engineering, which use a graph-based model to connect requirements across disciplines, make it practical to build the kind of thermal-to-architecture traceability that programs need. When a power dissipation estimate is updated, the thermal requirements that trace to it are immediately visible, and the engineer can assess whether the change breaks margin. That kind of live traceability is what allows thermal to stay connected to architectural decisions throughout the program, rather than drifting into a separate analysis lane.

The Moment That Actually Matters

The thermal management requirements gap is solvable. The physics are well understood. The analysis methods exist. The tools to manage traceability are available. What has been missing is the organizational will to treat thermal as a systems engineering problem from day one, rather than a thermal engineering problem that shows up when detailed design gets uncomfortable.

The defense electronics engineer from the opening of this article reflected on what would have changed the outcome on his program: “If we’d had a thermal scenario document that was part of the system requirements baseline — power modes, duty cycles, ambient envelopes, all traced to the operational requirements — the thermal engineer would have had what he needed to run the analysis before PDR. He could have told us the cold plate constraint before we locked the architecture, not after. Six weeks from CDR, we had no options. Six months before PDR, we had options.”

That’s the gap. It’s not in the thermal analysis. It’s in when the thermal analysis is given something real to analyze — and whether the requirements that drive it are written before the decisions are made.