Was the storage condition held? Reading temperature and humidity together

A stability chamber is almost never specified as “25 °C” or “60 %RH”. It is specified as 25 °C / 60 %RH: one condition, stated as a pair. A damp-heat test is 40 °C / 93 %RH. The specification asks a single question: was the product held at that condition?

Most chamber reports answer a different question. They give you a time-in-tolerance figure for the temperature loop and another for the humidity loop, and leave you to combine them. Those two numbers cannot be combined. This article explains why, what measures the combined condition directly, and what to check in any report that says it does.

Two good numbers, one bad condition

Take a 100-hour soak at 25 °C / 60 %RH. The report says:

Temperature in band: 95.0%
Humidity in band: 95.0%

That reads like a chamber that held its condition 95% of the time. It might be. But suppose the temperature spent its 5 hours out of band early in the soak, and the humidity spent its 5 hours out of band later, while the temperature was fine. Both loops honestly report 95%. For 10 hours one or the other was out, so the combined condition was held for 90% of the soak, not 95%.

The per-loop figures set a range, not an answer. When the excursions overlap exactly, the condition was held 95% of the time. When they never overlap, 90%. With larger excursions the spread grows: two loops at 80% each can mean the condition was held anywhere from 80% of the time down to 60%. Nothing in the two percentages tells you where in that range you are, and an auditor asking “was 25 / 60 held?” is asking for the one number the report does not contain.

Measuring the condition directly

The fix is to stop measuring the loops separately. At every moment of the soak, ask one question: were both loops inside their bands at the same time? Add up the time the answer was yes.

ProcessView+ calls this setpoint-pair dwell, and the headline figure is the joint window:

Joint window % = time with both loops in band ÷ commanded, observed time × 100

Every word in that denominator matters, and each is a place where a calculation can quietly flatter a chamber.

Commanded. Only the time the profile asked for that condition counts. A ramp is the chamber being moved, not asked to hold, so ramp time is counted nowhere. An interval where either setpoint changed ends any hold.

Observed. Time nobody watched cannot be claimed as held, so logging gaps and communication outages come out of both sides. The obvious alternative is worse: counting a gap as held credits the chamber with time nobody recorded, and counting it as not held punishes the chamber for a network fault. Leaving it out, and reporting how much was left out, is the only reading that is honest in both directions.

Time-weighted. The figure is built from the intervals between readings, not from counting readings. If the logging interval changes during a run, a count of readings would weight the fast-logged stretch more heavily than it deserves.

The hold matters as much as the percentage

A joint window of 98% can describe a chamber that stayed in band for one long, unbroken stretch. It can equally describe one that dropped out for a minute every hour. For a stability study those are different chambers, so the percentage alone is not enough. Two more figures belong beside it:

Longest hold: the longest unbroken stretch with both loops in band.
Total held, over how many holds: the same time as the percentage, but showing whether it came in one piece or twenty.

ProcessView+ applies no debounce: a single interval out of band on either loop ends a hold. That is deliberately strict, and some standards count test duration from when conditions are reached and tolerate brief excursions. Reporting both the longest hold and the total held means a hold broken by one blip shows up as two long holds rather than vanishing. The reviewer can judge it against their own protocol instead of inheriting the software’s leniency.

Reading the scatter

The QA report draws each held condition as a chart: every observed soak reading plotted as a point, temperature across and humidity up, with the warn band of both loops drawn as a rectangle. The rectangle is the condition, and it takes a few seconds to read:

A tight cluster in the centre is a chamber holding its condition well.
A cluster pushed toward one edge is a chamber running consistently off setpoint on that loop. It is in band, but with less margin than it looks.
Points strung out along one axis show which loop is struggling.
Points outside the rectangle are the readings that cost the joint window.

The percentage is time-weighted and the points are not, so counting points will not reproduce the figure. The chart shows where the condition was lost; the number says how much of it.

Five checks for any report that claims a combined condition

Whatever software produced it, these questions separate a measurement from a restatement of two per-loop figures:

Is there one figure for the pair? If the report gives only per-loop percentages, it has not measured the combined condition, however it is labelled.
Is ramp time excluded? A figure that includes the approach to setpoint describes the chamber’s travel, not its hold.
What happened to gaps? The report should say how much commanded time was not observed. Silence usually means gaps were counted as held.
Which band was used? Warn and alarm limits give different answers. The report should say which one, and it should be the band your specification states.
Is the hold reported? A percentage without the longest hold cannot distinguish one clean soak from many broken ones.

Where ProcessView+ draws its lines

A measurement is only as useful as its stated limits, so these are ours:

The joint window is a measurement, not part of the verdict. The run’s PASS, REVIEW or FAIL is decided by the per-loop tolerance bands. The joint window reports how well the combined condition was held, for a reviewer to judge against their specification. The two use different rules (the verdict has a settle window, dwell and hysteresis; the joint window has none), so they can disagree on the same run, and both are shown.
Loop 1 is taken as temperature and loop 2 as humidity. That matches how temperature and humidity chambers are built, but it is an assumption, and the report labels the pair on that basis.
Where a run did not log the profile’s commanded setpoints, the setpoint the controller was driving at each moment is used instead, and the report says so.
A soak step with no band on one loop still counts toward commanded time but can never count as held. A missing band is not a pass.
When there is nothing to measure, it says so. A furnace survey bands thermocouples, not loops, so the report states that setpoint-pair dwell does not apply, rather than showing 0% or 100%. Never held and does not apply are different answers, and the report never shows one as the other.

ProcessView+ calculates the joint window, longest hold and total held for every temperature and humidity condition a profile commands, and prints them on the QA report cover beside the verdict, with the scatter behind it. The free trial’s Stability Demo runs a 25 °C / 60 %RH condition on a built-in controller simulator, so you can see the figures on a real report without a chamber attached. Demonstration runs are simulated and are not test results.