Library / Systems Engineering Principles Framework
Jump to passage
In this reading

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 10:39:28 UTC · snapshot created 2026-10-03 10:40:04 UTC · last check 2026-10-03 10:45:12 UTC

SYSE.22:5 - Worked Case: Heat-Pump Controller Family

In this constructed case, a manufacturer maintains heat-pump controllers for occupied apartment buildings. The current decision concerns the controller family and a reversible building pilot. Installed controllers and a laboratory unit are actual Systems; the options below are possible-future specifications under the family’s architecture and effectivity rules.

The earlier selected problem was peak electrical demand during cold mornings. The preferred specification used a schedule optimizer and cloud forecast service. These three field observations now reopen the comparison:

  1. several buildings lose network service during the coldest periods;
  2. compressor cycling increases service calls in one installed configuration; and
  3. a new tariff rewards short demand reductions but penalizes slow recovery that leaves occupants cold.

The current problem portfolio and System-family options produce four correspondence rows:

Problem recordSystem-family optionDecision-bearing correspondence
peak demand, now with recovery-time and occupied-temperature acceptancecloud schedule specificationNetwork loss makes the option inadmissible without a qualified fallback; recovery time enters comparison.
network-loss continuitylocal-fallback specificationLocal forecasting can change continuity and recovery, but processor-load and fallback evidence are missing.
compressor cycling for the affected configurationvariable-speed-control specification and incumbent controlVariable speed can change cycling and energy use while increasing calibration and service burden.
speculative voice-control request, retained only in the archivevoice-gateway specification, retained only in the option archiveNo current use or affected-System consequence gives this pair decision priority.

The final row explains archive retention and current non-selection; it supplies no OptionSet member. The first three rows are the complete correspondence set used by the current decision.

The earlier Front compared energy use and peak demand. The current comparison uses a new candidate set and the following complete coordinate set: continuity, recovery time, occupied-zone temperature, peak power, compressor cycling, processor load, calibration effort, and service burden. It is therefore a new Front with its own basis.

The fixed current OptionSet has three members:

  1. continue developing the cloud-schedule specification;
  2. develop the local-fallback specification; or
  3. develop the variable-speed-control specification.

Safety and occupied-zone comfort are hard guards. The remaining coordinates form a partial order. The cloud- schedule specification without a qualified local fallback fails the network-loss guard. The variable-speed option retains the incumbent local control during network loss and remains admitted, but evidence about processor load and cold recovery is missing for the local-fallback option. That option cannot yet be admitted or rejected.

The controller-family council is the deciding Agent. Its current assignment authorizes it to choose the next engineering probe, or decline new probing on the present basis, and allocate no more than 160 engineering hours. A building operations manager separately authorizes any occupied-building trial; the product-family owner separately authorizes later adoption. The probe choice grants neither authority.

The council uses one shared comparison basis:

  • The fixed OptionSet remains cloud schedule, local fallback, and variable-speed control.
  • The current BeliefState contains the three field observations, the hard safety and comfort guards, the cloud option’s network-loss failure, the variable-speed option’s admitted local control, and the missing local-fallback processor-load and recovery evidence.
  • The OutcomeModel states how each possible probe observation changes admission and the survivor relation. A local-fallback pass admits that option and leaves it non-dominated with variable-speed control; a guard failure or processor overload rejects it. The current calibration uncertainty changes burden estimates for variable- speed control but does not change its admission or resolve the local-fallback question.
Candidate next probeBounded burdenDistinguishing observationsEffect on the current decision
Scripted network-loss and cold-recovery trial96 engineering hours, two hardware-in-the-loop bench days, one three-day reversible building-pilot window, and about one week of decision delay.In each of two representative building configurations: no safety violation; occupied-zone recovery inside 20 minutes; and controller processor load below 70%. An established safety or comfort guard failure, or processor load at or above 70% in either configuration, is a contrary outcome even if the other configuration passes. Incomplete, uncertain or otherwise non-decisive observations remain unresolved only when no such failure has been established.A pass admits local fallback and leaves it with variable-speed control in the survivor set while cloud-only is rejected. A contrary outcome rejects local fallback and leaves variable-speed control as the admitted next-development option. An unresolved outcome preserves the unresolved local-fallback status and requires a new bounded decision.
Variable-speed calibration trial128 engineering hours, four calibration-rig days, the same single building-pilot allocation, and about two weeks of decision delay.Calibration effort and service burden may fall or rise within the currently supported range; the trial does not observe network-loss recovery or local-fallback processor load.Either bounded outcome refines the burden comparison for an already admitted option but leaves the local-fallback admission defect and survivor question unchanged.
No probeNo immediate trial resource use or delay; preserves the scarce pilot allocation and engineering capacity.No new observation.Retain the qualified current comparison: cloud-only fails the guard, variable-speed control remains admitted, and local fallback is retained only as an unresolved candidate, not admitted for use. Later development or adoption still belongs to its competent owner.

The ChoiceRule compares obtainable probes with retaining the qualified current result. Changing admission or the survivor relation is a possible contribution, not an obligation to buy it. In the first resource situation of this case, the council’s qualified judgement is that resolving the local-fallback option before the next family investment is worth the 96 hours, scarce pilot allocation and one-week delay. Assume that capable performers and the windows can be obtained, and that this allocation does not displace more valuable protective or development Work. This value-and-feasibility premise, not the 160-hour ceiling, supports the choice. The calibration trial cannot resolve that question. The deciding Agent applies C.11 and records ChoiceResult-HPF-1 = probe_again for the network-loss and cold-recovery trial.

In the paired resource situation, the same discriminator would consume the only pilot window needed for already supported protective maintenance, or no competent performer can use it before the investment decision. The council can decline that probe and retain the qualified comparison above. Local fallback stays unresolved; no observation or safety assurance is invented. A later owner can make a supported bounded development choice among admitted options. No separate no-probe certificate is needed merely to keep the current comparison usable.

In the selected-probe situation, after that ChoiceResult, a planning Agent must still prepare the trial plan, the building operations manager must authorize the occupied-building trial, and assigned Agents must perform and interpret the Work. Family adoption remains a separate decision by the product-family owner. If pilot authority is withdrawn before the trial Work, a new decision pass records reroute and the missing authority without rewriting ChoiceResult-HPF-1. Later observations reopen only the three current problem–option correspondences and dependent family results; the voice-control archive entry remains unchanged.

For currentness, first keep the same configurations, relied-on observations, calibration, rights and supported use while only the source export date changes: the comparison remains usable. Now change a controller configuration so that the relied-on processor-load evidence no longer covers it, or let a real calibration or pilot permission window end: reopen or suspend the affected use, not every claim in the source. Keep the needed qualification with the comparison for later receivers; do not turn the first case into renewal Work. The case’s 20-minute and 70% limits are receiving acceptance conditions, not universal thresholds supplied by this pattern. Their protective basis and any proposed amendment require the relevant engineering judgement and authority; merely choosing or declining a probe changes neither.