SYSE.24:5.1 - Climate control for a new greenhouse configuration

Small equipment company GreenHeat-4 needs a climate-control System for greenhouse GH-2. Until identity inception, GreenhouseClimateControl-GH2 remains the designator for the intended System in the WorkPlan and descriptions. The receiving use is control of heating, ventilation, misting, and shading during cold-night, rapid- solar-rise, and failed-humidity-sensor conditions. Acceptance requires bounded temperature and humidity performance, no unsafe actuator command after the sensor failure, identified software and controller configuration, recoverable observations, and a supported fallback to manual operation. GreenHeat-4’s authorized management team may choose the obtaining arrangement within its approved equipment budget; electrical-safety acceptance remains with the named specialist authority.

GreenHeat-4’s engineering team develops four complete arrangements:

Arrangement	Agents, Work, Methods, and means	Integration, assurance, support, capability, and exit
Ready controller plus integrator	The controller vendor’s engineering team supplies a configured controller; the integration company’s team performs sensor, actuator, network, and commissioning Work; `GreenHeat-4`’s engineering team maintains greenhouse requirements and accepts the result.	The controller supports the existing field interface, but the greenhouse-specific failure behaviour and configuration export remain unsupported. Vendor support is available for three years; control logic cannot be maintained without vendor access.
Commissioned custom controller	The engineering provider’s team designs and integrates a custom controller using its named engineering Method and supplies source, configuration, test evidence, and support.	The arrangement gives change access and an escrow proposal, but the provider has not shown representative sensor-failure evidence and cannot meet the required commissioning date without narrowing the first configuration.
Internal development with AI assistance	`GreenHeat-4`’s controls engineers lead development; a general AI Agent assists with code and test generation; an independent controls specialist reviews the safety-relevant behaviour.	The company can retain knowledge and change the result quickly, but it lacks a qualified hardware-in-the-loop environment and evidence that the team can complete assurance before commissioning. The receiving team uses its checks of the AI-produced code and tests as evidence for capability and acceptance claims.
Ready controller plus internal supervisory layer	The vendor controller retains safety interlocks and local fallback; `GreenHeat-4`’s controls team develops a supervisory optimization layer through a documented interface.	This preserves a supported safety boundary and gives the company control over greenhouse-specific optimization. The arrangement still depends on the controller interface, configuration export, and vendor update policy; failure of that interface defeats the option.

The parity basis includes the same three operating conditions, commissioning date, interface set, configuration evidence, assurance burden, data access, support horizon, internal capability consequence, expected change latency, and exit condition for all four arrangements. The internal-only and commissioned-custom arrangements do not survive the commissioning-date condition. The ready-controller and hybrid arrangements form a tie-set.

The two survivors have different burdens. The ready-controller arrangement is estimated at EUR 84,000, nine weeks, and eighteen days of GreenHeat-4 engineering Work; later greenhouse-specific changes require a vendor release expected to take four to six weeks. The hybrid arrangement is estimated at EUR 96,000, eleven weeks, and thirty-two days of internal engineering Work; if the supervisory interface remains supported, the controls team can make a greenhouse-specific change within five working days. The operating plan expects at least three such changes during the next three years.

The management team is authorized to commit up to EUR 7,000, forty engineering hours, two hardware-in-the-loop laboratory days, and five elapsed working days to the obtaining decision. Those limits fit the remaining one-week decision reserve without moving the commissioning date. The electrical-safety specialist may authorize the failed-sensor injection in the laboratory; that authorization does not extend to a greenhouse trial.

The management team uses this ChoiceRule: preserve the failed-sensor, configuration-identity, and commissioning- date conditions first. Probe only when the probe stays within the stated limits and every possible outcome changes what the team may lawfully do. If both arrangements survive, choose the hybrid only when its added price is no more than EUR 15,000 and its added internal burden is no more than fifteen engineering days; otherwise choose the ready- controller arrangement.

The proposed replay costs EUR 5,500, thirty-two controls-engineering hours, eight integrator hours, two laboratory days, and five elapsed working days. It uses the intended sensor and actuator interfaces and injects the failed- humidity-sensor condition while checking configuration export and the supported supervisory API. Its possible observations have three decision effects:

an unsafe local fallback or a configuration export that cannot reidentify the tested controller and software rejects both survivors and returns the team to arrangement generation;
a safe fallback and usable configuration export combined with failed supervisory timing or withdrawn API support rejects the hybrid and retains the ready-controller arrangement; and
a safe fallback, usable configuration export, and supported API within the timing limit retain both survivors; the price-and-burden branch of the ChoiceRule then selects the hybrid arrangement.

ChoiceResult-GH2-1 is probe again. Choosing either arrangement without the replay would leave a protected acceptance claim unsupported, while rejecting both would discard a survivor that one bounded replay can retain. This worked case stops at that first useful result. APP-SYSE-04 continues the case through performed replay and a later choice. SYSE.3 begins only after the replay retains an arrangement and exposes its first unsupported realization branch.