Thermal telemetry only counts as functional-safety evidence when it is a documented envelope: thermal margin measured across the range of load (including the extra heat from fast-charging currents), ambient temperature and duration that the system’s operational design domain allows, with traceable pass/fail results that feed the ISO 26262 or SOTIF safety case. A single nominal-case lab run is a monitoring data point, not evidence. Two practical consequences follow. Duty-cycle-aware scheduling can keep perception inference inside its thermal budget without redesigning the enclosure, within limits that timing guarantees set. And throttle state (clock frequency, power cap) tells you about compute capacity, not model accuracy, so it cannot stand in for a drift alert until it has been calibrated against ground truth on your own hardware.
What evidence shows an assessor that thermal margins hold across the full operating range?
An assessor needs a margin envelope, not a margin number: the measured gap between junction temperature and the relevant throttle or shutdown trip point, tabulated across load, ambient and duration, covering the boundaries of the operating domain and not only the case the lab happened to run.
The standards give that envelope its place. ISO 26262:2018 defines a safety case as an argument that functional safety is achieved, satisfied by evidence compiled from work products of development activities. ISO 21448:2022 (SOTIF) adds “performance insufficiency”, a limitation of technical capability that contributes to hazardous behaviour when triggering conditions occur, and defines the operational design domain (ODD) as the specific conditions under which the system is designed to function. A perception pipeline that slows down because the die hit a passive trip point on a hot afternoon fits that definition in our reading, which is why we put the thermal envelope in the SOTIF argument and not only in a hardware test report.
The trip points themselves are set by each vendor and differ by platform. On Jetson Thor, NVIDIA documents CPU and GPU zones with software throttling at 109.0 °C, hardware throttling at 113.0 °C, software shutdown at 114.5 °C and hardware shutdown at 115.0 °C. On Jetson Xavier, clock throttling starts when the passive trip point is crossed at 88 °C. Axelera documents a fixed hardware throttling threshold of 105 °C junction for its Metis device, a warning at 95 °C and a shutdown at 120 °C that disables all regulators. The margin you claim is the distance to the first trip point that degrades the safety function, which is usually the throttling threshold, not the shutdown one.
Worked example: how ambient consumes margin
The arithmetic is simple, and that is the point: it lets an assessor check the claim.
| Step | Value | Basis |
|---|---|---|
| Die temperature model | ambient + power × total thermal resistance of the path | What Is Thermal Throttling (things-embedded) |
| Assumed load and path | 28 W through 2 °C/W, so 56 °C above ambient | What Is Thermal Throttling (things-embedded) |
| At 25 °C ambient | die at 81 °C, below a 100 °C Tj max | What Is Thermal Throttling (things-embedded) |
| At 45 °C ambient | die at 101 °C, and the processor throttles | What Is Thermal Throttling (things-embedded) |
| Illustration: the same example path against Thor’s 109 °C software-throttling point | 109 − 81 = 28 °C margin at 25 °C; 109 − 101 = 8 °C at 45 °C | arithmetic on the two rows above with the Thor trip point |
Every degree of ambient is a degree less headroom between the die and its limit. The same linear relation appears in a single-node steady-state thermal model in one avionics study, where on-chip temperature is a linear function of power plus a term in ambient. We treat a fast-charging current that warms the enclosure the compute shares as a higher effective ambient, which is why charging current is an axis of the envelope and not a footnote. For charging infrastructure and other grid-side deployments, our page on AI engineering for energy and utilities covers how we approach these systems.
How to measure each point
Each envelope point has to come from a sustained run. A short benchmark finishes inside the turbo window and reports the best case; the method is to run the real application, or a stress tool such as stress-ng, until the chassis reaches a steady temperature, which for a fanless enclosure can take well over half an hour, while logging clocks, power and temperature with tools such as tegrastats on Jetson. Our page on thermal soak testing to steady state covers how long to soak and when a trace counts as settled.
Two cautions decide whether the envelope survives review. Datasheet thermal parameters may not reflect reality, because board layout and manufacturing variation change them; two platforms with nearly identical power draw showed significantly different thermal trajectories because one had a heat sink and airflow. Any thermal model used to interpolate between tested points therefore needs its own validation on the production board and housing, or the claim shrinks back to the discrete set of points you actually ran.
How many charging-current, duration and ambient combinations do we need to test?
No standard or source we rely on gives a fixed count, and an arbitrary number (a 3 × 3 grid, say) is not defensible on its own. The count follows from ODD boundary analysis and from how sensitive margin is to each variable.
| What sensitivity analysis shows | What to test before submitting the claim |
|---|---|
| Margin falls monotonically as current, ambient and duration rise | ODD boundary corners plus worst-case interior points |
| Thermal management switches state inside the ODD (fan curves, power-mode changes, cooling stages) | A denser grid across the whole ODD, concentrated around the switching points |
| Interpolation between points relies on a thermal model | Additional held-out points that validate the model on the production hardware |
Fan control is a concrete source of non-monotonic behaviour: Jetson Thor’s nvfancontrol holds the fan at a floor RPM across a temperature band and then interpolates between table values above it, so margin can change slope inside the domain. The automotive scenario literature offers a principled way to pick points: decomposing scenarios into parameters lets you estimate a probability density over them and sample it deliberately, emphasising safety-critical regions, with each run judged against key performance indicators that carry pass/fail thresholds. Treating current, ambient and duration as scenario parameters gives the test plan the same structure and the same traceability.
Does thermal margin evidence need to feed into ISO 26262 or SOTIF, and how?
Yes, as a documented work product with traceable pass/fail results, because a safety case is satisfied by evidence compiled from work products. ISO 26262 assigns an ASIL to each item, and the ASIL sets the rigour required, including testing techniques and documentation, from ASIL A (lowest) to ASIL D (highest).
The hardware side of the standard already expects thermal conditions to be written down. ISO 26262-11 asks that a base failure rate calculation document its assumptions, including the assumed mission profile and any scaling or de-rating applied, and it models temperature de-rating from junction temperatures and working-time ratios across the mission profile. The standard also warns that ignoring the mission profile and operating conditions can artificially reduce the calculated failure rate.
Middleware does not carry this for you: AUTOSAR states that using its safety mechanisms does not imply ISO 26262 compliance.
Can we duty-cycle the inference workload instead of changing the housing?
Yes, within limits: thermal-aware task allocation lowered steady-state temperature on embedded platforms, and overload schedulers shed lower-criticality work early. It cannot rescue a system whose thermal design is undersized for its hottest ambient.
What scheduling actually buys
Task allocation at a fixed clock gains a few degrees. Thermal-aware task allocation on three embedded platforms cut steady-state temperature between the worst and best methods by up to 5.5 °C (22% relative to a 25 °C ambient) on the i.MX8 MEK and 3.6 °C (14.4%) on the TX2, according to a 2025 avionics study. On GPUs, a 2026 paper on Tri-serve measured core frequency decaying by about 20% over compute-heavy phases due to thermal throttling, and proposed a “pace-and-race” policy that runs at a sustainable frequency first to conserve headroom. Pacing is the frequency-scaling version of the same trade: give up a little peak rate early to avoid a deeper, uncontrolled clock loss later.
Prioritising safety-critical inference when heat is high
The RED scheduler monitors GPU utilisation, queue length and deadline slack and drops low-criticality work early under sustained overload, and its authors report an average deadline miss rate 40.5% lower than EDF across four embedded devices. The D3 execution model goes further, using a deadline policy that adapts to the environment and can fall back to a safety backup mode of simple manoeuvres when deadlines keep being missed. For a steering-assist or protection function, that pattern maps directly: degrade the comfort features first, and define in advance what the safe fallback is when even the critical path cannot hold its rate.
Where timing guarantees limit duty-cycling
Frequency changes are not free. One measured platform showed DVFS switching latency of 5.313 ms on average and up to 12.025 ms, which the authors deduct from available slack so tasks still meet their deadlines; ignoring such overheads can cause deadline misses. On Jetson Orin, a 2026 study found that clock changes take roughly 1, 5 and 8 ms to become true on CPU, GPU and memory controller respectively. AUTOSAR’s OS timing protection and Watchdog Manager deadline supervision exist to detect tasks that overrun their configured runtime, so a duty-cycle change that stretches an inference task can trip those mechanisms if the budgets were not set with it in mind. Switching from a longer to a shorter deadline also introduces unavoidable extra delay, which one mode-change protocol handles by reserving analysed safety margin.
There is a harder constraint for some certification paths: the avionics study assumes DVFS is not used because it increases failure rates and is typically forbidden by safety certification requirements, holding clock frequency fixed. If your assessor takes that line, duty-cycling has to work through task allocation and idle time at a fixed clock, not through frequency scaling.
Is thermal-throttle state a reliable proxy for model accuracy drift?
No, not on its own. Throttle state reports compute capacity such as clock frequency, not whether the model’s outputs are right or how they track confidence. Any such correlation is specific to a model, workload and board, and has to be measured there before an alert relies on it.
TechnoLynx would start by defining which drift events the alert must catch and the false-alarm budget, then run calibration experiments on the target Jetson Orin hardware that log tegrastats or jtop telemetry alongside a sampled ground-truth confidence or accuracy signal across representative thermal scenarios, and validate the proxy’s false-alarm and miss rates against direct confidence-based alerting before choosing proxy, direct or hybrid alerting for deployment.
The mechanics explain why the link is weak. When a sensor crosses a throttling trip point, the platform uses DVFS to lower clock frequencies and voltages; that slows inference, but a slower model computing the same weights on the same input gives the same answer. The effect on accuracy is indirect, for example when a pipeline answers a slipped deadline with a faster, lower-accuracy model.
The telemetry is also less complete than it looks. NVIDIA notes that hardware throttling triggered by overcurrent events is not reported to the host OS and can be detected as a drop in clock rates by sampling the CPU cycle counters. Driver and firmware readback files lag hardware state, so one study treats them as bookkeeping and uses a measured clock counter as ground truth. And slowdowns happen without any thermal cause: on Orin, the same study traced a latency inversion with identical GPU clocks and a one-degree die temperature difference, so it was neither throttling nor thermal, with the unobserved memory-controller clock deciding whether deadlines were met. Latency itself varies with input content: two-stage detectors showed inference variation of up to about 200 ms on VisDrone2019 because proposal counts change per image.
Most importantly, accuracy can fail silently. In one evaluation, a DNN perception model failed its safety requirement in 31 of 100 challenging-scenario runs, all silent failures with no internal indication of degraded perception.
Tegrastats reports CPU and GPU load and frequency, memory-controller bandwidth, thermal-zone temperatures and per-rail power from kernel and sysfs counters. The polling overhead on your own pipeline is still worth measuring rather than assuming. Where the open question is which device to buy before any of this, LynxBenchAI’s published results show how each device runs the public PyTorch stack your models run on, which makes them broadly indicative for custom PyTorch models; they do not measure your model’s confidence under throttling.
What false-alarm rate is acceptable for a proxy alert versus a confidence-based one?
There is no universal acceptable rate: it is set by the cost of a missed drift event in your application against the cost of an operator chasing a false one, and no source we rely on gives a number. What the sources do give is how to state a rate honestly.
A low observed rate needs a confidence bound. One runtime-monitor study observed zero false positives in 100 trials and reported the exact two-sided 95% Clopper-Pearson interval as [0, 0.036], meaning the true rate could still be as high as 3.6%. Within-run samples are serially correlated, so the honest unit of replication is the independent run, not the individual cycle. Aggregate rates also hide clustering: at a fixed 0.1% miss rate, misses on one Orin configuration arrived in bursts of up to 16, so the authors recommend reporting miss-pattern statistics alongside the rate.
| Alerting approach | When it fits | What you pay |
|---|---|---|
| Throttle-state proxy (tegrastats/jtop) | A validated correlation exists for this model and hardware, with false-alarm and miss rates measured against logged ground truth | Recalibration after firmware or workload changes; blind to silent failures with no capacity change |
| Direct confidence sampling | No validated correlation | Periodic inference-side overhead |
| Hybrid | Proxy as a cheap trigger for denser confidence sampling | Two thresholds to tune and justify |
A direct confidence signal can be specified precisely, for example a requirement that pedestrian classification confidence must not drop below 0.8 within 30 m, and a monitor built on such a rule can serve as an ISO 26262 safety mechanism, paired with a hard-to-verify AI component under ASIL decomposition. A throttle-state proxy cannot be specified against the hazard that way, which is the real reason it struggles as safety evidence: it watches the hardware, while the safety goal is about what the model sees. If the proxy earns a place, it earns it as a cheap trigger for the direct measurement, with its calibration data filed in the same envelope as the thermal margins it came from.
