Repository navigation
Define conservative cooldown behavior during sensor faults #4
Description
Follow-up from PR #1 interlock review. This is important safety-policy work, but it is not a Phase-0 merge blocker.
Problem
Current blocked() cooldown behavior only commands fan output when sensors_ok() is true, and sensors_ok() requires all required temperature sensors to be valid and finite.
That means a single failed sensor can suppress cooldown fan output even when another valid sensor still reports residual heat.
Example:
- chamber sensor: open/invalid
- outlet sensor: valid and hot
- case sensor: valid and hot
- heater: correctly blocked
- current fan policy: 0% because the aggregate sensor-valid condition fails
The safest behavior is not yet established. We should not casually invent a policy before considering airflow hardware, residual-heat behavior, reboot/brownout handling, and fault recovery.
Decision required
Define the product-level cooldown/fault policy for:
- one sensor invalid while another valid sensor indicates residual heat;
- all temperature sensors unavailable or implausible;
- sensor failure while actively heating;
- normal stop versus latched fault;
- reboot/brownout during cooldown;
- fan failure during required cooldown;
- minimum/maximum cooldown duration if temperature evidence is unavailable;
- recovery and fault-clear prerequisites.
Acceptance criteria
- Conservative cooldown behavior is explicitly documented.
- The policy distinguishes trustworthy remaining temperature evidence from complete sensor uncertainty.
- Interlock/fan behavior is updated if required.
- Host tests cover the chosen fault-state transitions.
- Bench/HIL tests demonstrate cooldown behavior on release-intent hardware.
- The safety verification record identifies retained evidence and its location.
Related: PR #1.
Metadata
Metadata
Assignees
Labels
No labels
Activity
danielbrownjr commentedon Aug 29, 2026
Phase-0 model update from PR #1 corrective safety review (commit 8459894): blocked/fault cooling now stops only when every required sensor is valid, finite, and at or below the cooldown release threshold. Any partial or complete temperature uncertainty requests 100% fan output, and any remaining valid hot sensor remains actionable; a valid sensor can independently latch its sensor-specific overtemperature trip even when another sensor has failed. Host tests cover each invalid status, NaN/Inf, partial invalid+hot evidence, complete uncertainty, and fully valid/cool release. Physical fan behavior, reboot/brownout policy, and release-intent HIL/bench validation remain outstanding, so this issue stays open.
danielbrownjr commentedon Sep 24, 2026
Pre-actuation gate:
cooldown_requiredproducer and lifecycleIdentified during review of the staged PID control work in #9 (stacked on #7). This is an explicit pre-actuation gate, not a current actuation defect: there is still no heater actuator in the firmware.
Requirement
Before any real heater actuator can exist, Jump Jet must have a validated producer and lifecycle for
cooldown_required.Invariant
Removing heater authorization, or transitioning from delivered heating to OFF, must not by itself make recently delivered heat thermally safe for OTA.
Current state
!heater_authorizedand!thermal_management_required. "Heater unauthorized" is deliberately not treated as "thermally safe".thermal_management_requiredacross both stages whencooldown_requiredorfault_requires_thermal_managementis asserted, so the staged window cannot create a false OTA-safe condition.cooldown_requiredyet. So today, a transition from delivered heating directly to OFF with no producer active would leave the final state OTA-eligible. That is moot while no actuator exists, but must be closed before one does.Out of scope here
This does not define cooldown thresholds, durations, or temperature criteria. Those require Phase 3 evidence and belong to the policy decisions already listed in this issue.