Thermal Feasibility Checker — methodology

Contents

1. What it decides, and what it does not
2. Inputs
3. The four checks
4. Verdict rule
5. Cooling classes, enclosure classes and margins
6. Vendor limit table and sources
7. Alternatives and remediation
8. Evidence classes and confidence
9. What invalidates a result
10. Method changelog

1. What it decides, and what it does not

The checker answers one design-review question: for this module, at this power, in this enclosure class, with this cooling class, at the hottest ambient the site sees — is the thermal design worth building? It returns FEASIBLE, MARGINAL, NOT FEASIBLE, REQUIRES VALIDATION or UNKNOWN.

It does not predict a junction temperature, a throttle onset or a time-to-throttle. Those depend on the actual heatsink, thermal interface, airflow path and workload, none of which a form can capture. The roadmap decision behind this engine is that a categorical answer from the vendor's own limits is honest; a predicted temperature from a form is not.

2. Inputs

Enclosure air = ambient + the enclosure class's internal rise + solar rise. A thermal-transfer-plate rating is a plate temperature the cooling has to hold, so the TTP range is checked against the site ambient; ambient and module ratings are checked against the enclosure air.

Inputs (WP-01). A field that is not stated takes its documented default and is listed in provenance.defaulted; a field that is stated but invalid — a count of 0, a negative, a fraction or a non-number, true in place of a count, an unknown value of an enumerated input, or an empty string — is rejected with VALIDATION_ERROR naming the field, never replaced by a default.

Input keys (WP-02). The engine accepts one list of input keys — the inputs documented here and their declared backward-compatible aliases. Unknown input keys are rejected with VALIDATION_ERROR naming the key: an invented or misspelt key is never silently ignored, a __ test hook never reaches the engine, and an alias sent together with the key it stands for is rejected too (the engine would read only one of them). export_json.inputs echoes every input the engine honoured, so replaying it reproduces the result.

3. The checks

Unknown input keys are rejected; ambient_c is the only documented alias and maps to ambient_max_c.

Power mode. A requested power mode is read as a power ceiling, through the one resolver Jetson Power & PSU, Compute Fit, Camera Stream Capacity and Hardware Match use. An id that is neither a preset of the module, a wattage ceiling, MAXN nor default is a validation error naming power_mode (HTTP 400). A requested mode that is not a preset of the module is sized at the module's highest preset at or below the requested ceiling, and workload.power_mode_request publishes the ceiling, the selected preset and the resolution; when every preset of the module exceeds the ceiling, a power_mode_ceiling FAIL makes the verdict NOT FEASIBLE. For example, a 30 W request on a Jetson Orin Nano 8GB (presets 7 W, 15 W, 25 W, MAXN_SUPER) is sized at its 25 W preset, and a 5 W request fails: its lowest preset is 7 W. A module without power-mode presets runs at its vendor maximum module power, and fails the same way when that maximum is above the requested ceiling. A named mode is never sized at the vendor maximum as though no power were given.

Cooling resistance, the only arithmetic

required °C/W = (limit − margin − enclosure air) / power, where the limit is the maximum TTP temperature for modules with a thermal transfer plate (AGX Orin, Thor) and the SoC operating limit for modules without one (Orin NX / Nano, Raspberry Pi 5) — the vendor's number, quoted in the dataset — and the margin is 5 °C for a TTP limit (the vendor already specifies it with margin) or 10 °C for a SoC junction limit.

deliverable °C/W = band / (airflow factor × air density), where the band is the cooling class's engineering thermal resistance, the airflow factor is the enclosure class's, and air density follows altitude (1.00 at sea level, 0.78 at 2000 m). The module's own junction-to-plate resistance is inside the vendor limit and is not added again.

The check misses when deliverable > required (or required ≤ 0). Only evidence that can prove the miss makes it a FAIL (elimination authority). When required ≤ 0 the enclosure air is already at or above the design target and no cooling class can deliver it; that is FAIL: NOT FEASIBLE when the site air alone is at or above the vendor limit, because the air around a powered module is a floor on its temperature and no estimate moves it. When it is the class E enclosure rise or design margin that closes the gap, the miss rests on planning-only evidence and the check is REQUIRES VALIDATION with the shortfall stated, with a cooler site, a vented enclosure or a lower power mode as the remedy. A miss that rests on the class E cooling band (deliverable > required > 0) is REQUIRES VALIDATION too, because a band cannot eliminate a module that a deployment-specific thermal design could still cool. NEAR LIMIT when deliverable is at least 80 % of required, or when the estimated surface temperature (enclosure air + power × deliverable) is within the 5 °C marginal band of the target. PASS otherwise. UNKNOWN when the module has no published limit or no power is known. A bare module (none) above idle power is REQUIRES VALIDATION: the idle allowance it is compared with is class E.

4. Verdict rule

• UNKNOWN — the module has neither a TTP / SoC limit nor an operating range on record.
• NOT FEASIBLE — any check FAILs.
• REQUIRES VALIDATION — no FAIL, but a check is UNKNOWN because the vendor does not state the limit (for example Hailo-8 has an operating range but no plate or junction limit, so the cooling check cannot be made), or a check misses only on planning-only evidence — the class E cooling band, enclosure rise or design margin, the bare-module allowance or the sealed-enclosure fan rule (§3). That row carries elimination_authority: planning_only, its demoted status and the shortfall.
• MARGINAL — no FAIL or UNKNOWN, but the cooling check is NEAR LIMIT.
• FEASIBLE — every check PASSes.

A module drawing exactly its rated maximum is MARGINAL, not FEASIBLE: the rating is the permitted operating point, but it leaves no allowance for workload variation, peripheral draw, transient load, aging or measurement error.

A FEASIBLE verdict for a SoC-limited module whose datasheet defers the ambient ceiling to the thermal design guide carries LOW confidence: the ambient enters only through the cooling check.

ambient_rating never reports PASS with available null — a material unknown cannot read as PASS.

5. Cooling classes, enclosure classes and margins

Margins: 5 °C design margin on a TTP limit, 10 °C on a SoC junction limit, 5 °C marginal band. The bands, factors, rises and margins are class E engineering figures — anchored on the reference designs and worked examples in the vendor thermal design guides, not measured per product — and are published in the dataset so they can be argued with.

6. Vendor limit table and sources

Every row in datasets/thermal-limits.json carries the document, URL, retrieval date and a verbatim quote of at most 25 words for each limit. Vendor datasheets hosted on distributor or community mirrors are class A by document with the mirror noted. The engine returns the module's sources with every result.

7. Alternatives and remediation

With a limit and a power on record the engine also reports, for the chosen enclosure and altitude, every cooling class with its deliverable °C/W and whether it passes (and whether it would be marginal), the power the chosen cooling can hold at this ambient ((limit − margin − air) / deliverable), and, for sealed enclosures, what a vented enclosure would do to the internal air. Each failing or marginal check names the remediation that flips it: a lighter cooling class that passes, a power ceiling, a vented enclosure, a wider-rated module or carrier.

8. Evidence classes and confidence

• A — vendor thermal design guides, datasheets and product pages (all limits and ranges except the Raspberry Pi 5 range).
• C — a Raspberry Pi engineer's forum statement for the Pi 5 operating range.
• D — the cooling-capacity constraint (class A limit combined with a class E band) and an ambient check carried by the SoC / TTP limit.
• E — cooling bands, enclosure factors and rises, margins, the fan-in-sealed rule, the no-heatsink rule.

Confidence: HIGH for ambient and power checks with published figures; MEDIUM for a TTP-limited cooling check; LOW for a SoC-limited cooling check, an ambient check carried by the limit, or any UNKNOWN. The overall confidence is the lowest of the four.

9. What invalidates a result

• A poor thermal interface or partial contact with the thermal transfer plate — the bands assume the guide's full-contact mounting.
• Unbalanced workloads: the Thor guide gives a higher junction-to-plate resistance for unbalanced loads; the checker uses the balanced figure inside the vendor limit.
• A power figure below the workload's real sustained draw — use the preset's watts or a measured module power, not the idle figure.
• Solar gain on an outdoor enclosure that exceeds the solar rise you entered.
• An enclosure that does not match its class (a “vented” box with blocked vents behaves as sealed).
• Altitude above 6000 m, or ambient outside −60 to 90 °C, which the engine rejects.

10. Method changelog

Method changes bump the method version; new or re-verified vendor limits bump the dataset version. Both are in every result and in the citation block.