SYSE.5:5 - Worked Case: Heat-Pump Plant Control and Protection

An occupied building has a heat-pump plant whose controller must respond to electricity-price and grid-flexibility signals while maintaining room comfort and protecting compressors. The engineering team must choose a control architecture for plant configuration HP-2 that remains useful for the next three heating seasons. Earlier concept-development Work produced two viable use/System concepts and one unresolved mismatch: centralized optimization improves plant coordination, but communication loss must not remove local protection.

During allocation Work, the engineers restore four contribution families as claims whose bearer arrangements remain to be chosen:

• modulate heat production against building demand under temperature, occupancy, tariff, and plant conditions;
• keep compressor pressure, temperature, cycling, and flow within protected limits;
• accept, validate, and act on external price or flexibility signals within declared timing and authority;
• retain local safe operation and recover state after communication, sensor, or controller failure.

They develop three materially different proposals:

1. A central building controller carries demand estimation, optimization, dispatch, and most protection logic; unit controllers provide actuation and a small emergency stop.
2. Local unit controllers carry protection and normal regulation; a supervisor sends bounded set-points and coordinates units, while loss of the supervisor leaves a declared local operating envelope.
3. Thermal storage and a tariff scheduler carry most time-shifting; local controllers retain protection and regulation, so grid response is split across storage, scheduler, drives, sensors, and plant state estimation.

The functional contribution claims and candidate bearers are not one-to-one. Protection is distributed across software, local electronics, sensors, drive limits, valves, and physical pressure relief. Grid response depends on the supervisor or scheduler, communication bearer, storage state, unit capability, and operating permission. Every bearer entry identifies an actual System or intended referent and its proposed allocation. A model-box label such as protection or optimization is only a cue for recovering those claims.

The interface account separates signal semantics, units, timestamps, command validity, latency, state quality, fallback behavior, configuration identity, and physical connections. The team separately tests rejection of stale commands, agreement of sensor units, local fallback behavior, and the integrated plant contribution. Simulation Work challenges thermal and tariff behavior; Hardware-in-the-Loop Work challenges timing and fallback; a bounded plant trial challenges actual integration. Each produces observations with different claim limits.

An AI coding Agent proposes a fourth function graph and controller split. That Agent and the engineers perform candidate-generation and criticism Work; the generated graph is a description candidate. It enters the account only after its functional claims, candidate bearers, interface assumptions, and unsupported physical dependencies are recovered.

The account retains proposals 2 and 3 and rejects proposal 1 because its local protection split cannot satisfy the declared communication-loss condition. It also records one unresolved storage-cycling evidence need. The two alternatives, allocation conflicts, predicted losses, and conditions for revisiting the decision become inputs to architecture-decision Work governed by SYSE.6.

SYSE.5:5.1 - Small Wrong-Use Check

A service machine uses one lubricant cartridge and one cleaning-solvent cartridge. Cross-connection damages seals. The engineer states the two fluid-delivery contributions and service conditions, then compares candidate cartridges, ports, seals, and connection arrangements. The retained proposal uses mechanically distinct keyed couplings whose materials and geometry fit the relevant fluids, pressure, assembly, and service conditions.

The check attempts every intended connection and the consequential swapped connections under the declared conditions. A colour label is a cue, not evidence that cross-connection is impossible. If an intended connection fails or a damaging swap remains possible, the allocation and interface proposal reopens. The resulting observations can support claims only about the tested configurations and wrong-use cases.