Product brief

AReCoS embedded controller

Commercial and industrial refrigeration usually splits its control among several controllers, each running its own loops. The AReCoS controller is designed to run the whole refrigerant circuit as one, setting every actuator together from a physics model of the whole system, on the equipment itself.

U.S. Patent 12,768,557 · a hardware test on a vapor-compression system (US 2024/0295337 A1, FIGS. 4 to 7) · a research agreement (CRADA) with Oak Ridge National Laboratory, managed by UT-Battelle, LLC, supported by the U.S. Department of Energy. The record

Email info@arecos.net How an evaluation works

Rev 1.1 · Oct. 2026 U.S. Patent 12,768,557 info@arecos.net

Why it is different

One decision, on the machine.

Every actuator, one decision
Designed to set the compressors, valves, fans and pumps together from a physics model of the whole system, for the lowest total power, where today each runs on a loop of its own.
On the equipment
Every control decision is designed to run on the machine, with no cloud in the control path. An optional cloud connection is designed only to monitor, never to send a command.
The cause, not the symptom
The same physics model is designed to name the likely cause (the part or the sensor) and to count the refrigerant, so a service call starts from the cause, not the symptom. See an example
Designed to fit the equipment there
Designed to run standard compressors, valves, fans and pumps from different makers, and on a rack to replace the rack controller and every case's own valve and fan loops.

The record

Patented, and tested on hardware.

The patent record and the hardware test are public documents, readable today.

U.S. Patent 12,768,557: "Control systems, methods, and algorithms to optimize heat pump and chiller operations", issued Oct. 20, 2026, from application 18/592,624, filed Mar. 1, 2024. Inventor: Ahmed Hussein.
Published application: US 2024/0295337 A1, published Sep. 5, 2024: the architecture in full. Google Patents updates weeks after the USPTO and may still show the application as pending; the USPTO record shows the issued patent.
Test on real equipment: In a hardware test, the controller ran a vapor-compression system in cooling, reading its temperature sensors only and setting the compressor, electronic expansion valve, air blower and fan together. The results are published in FIGS. 4 to 7 of US 2024/0295337 A1. Refrigeration plants and natural refrigerants are within the design scope, still to be validated.
Research agreement: A cooperative research and development agreement (CRADA) with Oak Ridge National Laboratory (ORNL), managed by UT-Battelle, LLC for the U.S. Department of Energy, supported by the DOE, to test the controller on rooftop-unit energy optimization, with building supervisory integration, October 2025 to April 2027.

Show the engineering record

Engineering record: A documented dynamic model of the vapor-compression cycle, built and verified for the AReCoS heat pump; steady-state cycle studies for CO₂ and two-stage ammonia; and a design and verification run that is the same every time.
How each design is verified: Each heat pump controller design so far has been verified against its machine's full physics model, sensor and actuator response included, across a range of operating points. A refrigeration controller is designed to be built and verified the same way, from a model of your machine.

How to buy

The controller is planned to be fitted to your machine, then supplied.

It is designed to run on your commercial or industrial refrigeration system, on its own or under the building system you already have.

The evaluation starts with your machine: its coils, compressor, valve, actuators and refrigerant become the model the controller carries.

If you build equipment, the controller is planned to be licensed per unit, so that it ships inside your equipment as part of your product, not as a supervisor or service bought later from someone else: the savings are credited to your machine, and you keep the customer relationship.

Controller hardware, sensor and actuator channel counts and the enclosure are defined with you in the evaluation, around the machine it will run.

Show what ships with the machine

Your equipment is designed to ship with the optimizer built in: no controls integrator to tune it, no add-on cloud optimizer to get the most from it. Where a site has a building system, your machine is designed to connect to it through a points list defined once for that machine.

Email info@arecos.net

Watch

The controller in under two and a half minutes.

How one controller is designed to set every actuator on a refrigeration circuit together, illustrated, with captions.

Where it runs

Commercial and industrial refrigeration, one controller for the whole circuit.

A walk-in's condensing unit and its unit coolers usually form one refrigerant circuit, and the controller is designed to drive every actuator on it, defrost included.

On a rack, it is designed to take the rack controller's place and set each case's valve opening, evaporator fans and defrost directly, in one decision with the compressors, the condenser fans and, on CO₂, the gas-cooler and receiver valves.

Show how it runs a rack

The valve drivers and case controllers already there, their own superheat loops off, stay as the hardware that carries out those commands, reads the case and keeps its local safeties.

Transcritical CO₂ and two-stage ammonia each add a decision of their own, set out on the CO₂ and ammonia page.

Refrigeration: a condensing unit outside and an evaporator in the cold room, on one refrigerant circuit.

What it is

A model of the machine, designed to run on the machine.

The AReCoS embedded controller is designed to run a first-principles model of the refrigerant cycle on the machine itself: the coils, the compressor, the expansion valve and where the charge sits. From an ordinary set of pressure and temperature sensors it is designed to reconstruct the conditions inside the coils that no practical sensor reports.

Show the controller at a glance

From those same readings it is designed to set the compressor, expansion valve, fans, blowers and pumps at the same instant.

Through the shared refrigerant flow and charge, each actuator moves pressures and temperatures well beyond its own device, so the commands are designed to be decided together, not left to a separate loop on each device to settle out.

It is the same core controller AReCoS is building into its own all-season heat pump rooftop unit and residential heat pump.

Class: Embedded controller for a vapor-compression circuit
Designed for: Commercial and industrial refrigeration
Refrigerants: The core control architecture does not depend on the refrigerant: for each one it is configured with that refrigerant's thermophysical properties, component models, operating constraints and control strategies.
Developed first for: HFC and HFO systems; natural refrigerants, including ammonia R-717 and CO₂ R-744, are within its design scope. What that means on a transcritical CO₂ machine, and on two-stage ammonia.

Why one controller

What it replaces.

Today a refrigeration system runs several controllers, each set up and tuned on its own toward its own objective; some pass each other a setpoint, but each still runs its own loop, and the loops interact. The AReCoS controller is designed to decide every actuator's command itself, on the machine, with no add-on optimizer above it.

Show how today's controllers split the work

They are a rack or unit controller that also runs the condenser fans on a loop of their own, a case or circuit controller at each case or evaporator for its valve, fans and defrost, and separate pump loops, each specified on its own and set up by its maker's defaults or an adaptive search. A setpoint passed between them is often a suction pressure that floats with the case valves.

Even where one rack controller drives both the compressors and the condenser fans, it usually runs them as two loops on the same hardware: compressor capacity holds a suction-pressure setpoint that a supervisor may shift, and the fans hold a condensing-pressure setpoint that floats with outdoor temperature by a fixed rule.

The two come together in an override near the high-pressure limit, not in one decision about the least total power, and neither reaches the case valves or evaporator fans.

Above them a supervisor, on site or in the cloud, mostly sends setpoints and start and stop commands. A setpoint-writing supervisor changes what they aim at and when they run, not how they run: their loops stay, and still interact. On site it keeps running without the internet; in the cloud it stops answering when the link does.

For contractors, that means choosing, matching, wiring and programming each controller, tuning loops that work against each other, returning to adjust settings and setpoints as the plant and its loads change, and chasing faults across separate alarms.

A valve loop that adapts on its own adapts blind to the compressor and fans. Control engineering guides describe keeping PID loops tuned as a plant changes; the refrigeration trade press, setting up and troubleshooting electronic expansion valves on site.

On a walk-in or condensing unit, it is designed to replace all of these controllers, deciding at the machine's own dynamics.

On a rack, it is designed to replace the rack controller and every case's own valve and fan loops (where it runs). A building system can stay, for schedules and setpoints.

Many cases, walk-ins and condensing units in service still feed their coils through thermostatic expansion valves, each a loop of its own that nothing can command; where one stays, the controller is designed to set the compressors, fans and defrost around it, and the full optimum needs an electronic valve fitted in the retrofit.

Show why thermostatic valves stay, and their cost

They stay because a sensing bulb and a spring need no power, wiring, electronic sensor or controller, cost little and are familiar to technicians.

Its superheat margin is fixed wide enough to stay stable at every load, not retuned as load or compressor speed changes, so the coil runs drier and colder than it needs to. And it needs a minimum pressure difference to feed, which can keep head pressure from floating as low as cool weather allows.

The controller is designed to drive electronic expansion valves.

Today: separate controllers under a supervisor, each running its own loop; the dotted line marks the compressors and condenser fans that one rack controller often runs, still on separate loops. With AReCoS: one embedded controller, designed to set every actuator together.

What it does

Designed to be commissioned from the machine, not tuned loop by loop.

The controller is designed to be set up from a model of this machine (its coils, compressor, valve, refrigerant and actuator ranges), not device by device from generic presets and loop tuning on site.

Show the control functions

It is designed to cut the site visits spent retuning loops. One design is meant to cover the whole operating range, checked at many operating points rather than tuned at one, and to carry these functions as one decision:

Sets every actuator together: Compressor, expansion valve, fans, blowers and pumps computed as one set of commands, at the machine's own dynamics.
Holds the delivered temperature: The air off the coil, or the temperature the machine is set to deliver.
Regulates superheat: Evaporator superheat held together with capacity, not on a valve loop of its own.
Sets the working pressures: Evaporating and condensing (or gas-cooler) pressure set in the same decision, not each on a loop of its own, at a fixed setpoint or on a separate reset.
Follows subcooling: On a subcritical machine without a receiver, condenser subcooling read as where the charge sits. With a receiver, which holds the surplus, its level does that, read together with the condenser's subcooling whenever the condenser is flooded or split to hold head pressure, or bypassed for heat reclaim.
Least total power, in one decision: Designed to hold the required duty on the actuator combination that draws the least total electrical power, with the expansion valve and evaporator fans or blowers in the same decision as the compressor and condenser fans (on CO₂, the gas-cooler and receiver valves too).
Where today stops: Today a head-pressure strategy at most trades condenser-fan against compressor power, while each valve and evaporator fan runs on a loop of its own.
Works from what no sensor reports: The conditions inside the coils, reconstructed from a standard sensor set's pressures and temperatures, and designed to be acted on as one estimated state with the delivered temperature, rather than as each device's single reading of pressure, superheat or air temperature.
Screens its own commands: A second model is designed to screen the controller's commands for likely component failures before they are sent.

Where it sits

Designed to run on its own, or to take goals from a building system.

Where a site has a building or plant system, that system keeps the goals — setpoints, schedules, demand-response signals — and the controller is designed to decide how the compressor, valves, fans and pumps reach them.

Every control decision is designed to run on the equipment, with no cloud service or remote optimizer in the control path, so the controller is designed to keep deciding with the connection gone. An optional cloud connection is designed only to monitor, never to send a command. Security, and how to report a flaw.

In October 2026, attackers remotely switched on defrost cycles in supermarket refrigeration controllers in France; about 700 stores were affected, the French government said (Associated Press report). This controller is designed to take no command from the internet at all.

Show more on goals and security

It is designed to own the actuators, not the goals; where a site has several machines, their controllers are designed to share the load within those goals.

It is designed to run with no site data leaving the site. Keeping commands off the internet is designed to address the EU Cyber Resilience Act’s requirement to limit attack surfaces.

The machine's own safeties, hard-wired or on a compressor package's own panel, are not in the controller's path.

If the controller loses power, stops or is taken out of service, its outputs are designed to go to the fail-safe positions set for your machine; on a rack, normally the fallback it already has.

Show the fail-safe position of every output

The field bus, the points list and the supervisory interface are agreed with you during the evaluation, and the fail-safe position of every output is fixed there.

Case valves, when its commands stop: Each valve driver goes to what its own configuration sets: its own superheat control, or its last or a fixed opening, so the valve keeps feeding the coil. A driver left at its default may instead stop and close its valve, so that setting is chosen for every driver.
Rack pressures, when its commands stop: Suction and condensing pressure go back to the rack controller it already has, where one is kept beneath the AReCoS controller as the fallback, or to mechanical pressure switches where the rack is wired for them, so the cases stay cold.
When a valve driver loses power: A pulse-width (on/off solenoid-type) valve closes by itself. A stepper-motor valve stops its case's feed only where the machine is fitted for it, with a battery or capacitor module on the driver that closes the valve or a liquid-line solenoid ahead of it that shuts the line; with neither, it stays where it was.
Transcritical CO₂: A CO₂ rack normally has no mechanical fallback on its high side: its gas-cooler and receiver valves need backup power for their controller and drivers, or a defined position of their own.
Industrial plant: Each compressor package's panel can be set to return to its own local capacity control when the controller's commands stop, or to stop the compressor instead.
Where they are set: Outside the controller: in each driver's and panel's own settings, and in the machine's wiring and actuator hardware.
The machine's own safeties: They act without the controller: its hard-wired pressure cut-outs, relief devices and motor protection, and on an industrial compressor package the oil management and safety chain its own panel keeps.

Phases

Starting, stopping and switching, not just steady running.

The controller is designed to run the machine through starting, stopping, switching and defrost as one control problem, inside the sequence interlocks that keep hot gas and liquid feed apart.

Show each phase

Control loops are usually designed for the machine once it has settled. Starting, stopping and switching are left to fixed sequences in each device (timers, set valve openings, ramps and interlocks, with a sensor ending some steps), none treating these phases as one problem across the compressor, valves and fans.

Yet in these phases refrigerant moves between the coils, liquid most often reaches the compressor, and much of the damage is done.

Startup: Up to capacity without liquid returning to the compressor while the charge redistributes between the coils, including a restart after a power cut that left a coil part-way through its defrost.
Running: Holding the duty as the load and the ambient move.
Shutdown: To rest in the state the next start needs, pumping down or closing the liquid line where that serves, and following the refrigerant as it redistributes, so the next start begins from a tracked state.
Defrost coordination: Designed to coordinate each refrigeration coil's defrost with the compressor, valves and fans, managing capacity and refrigerant return through it as one decision, where today each coil's defrost follows its own start, stop and drain settings.

What it fits

Designed to fit more than one compressor or maker.

Designed to be configured for each machine from its own component models, data and operating constraints, and to run standard compressors, valves, fans, blowers and pumps from different manufacturers, with no proprietary sensor and no proprietary actuator.

Show circuits, standards and site codes

The same core software architecture is designed to be verified on the design and verification path run on the AReCoS heat pumps.

Circuits: Single-circuit machines and racks with electronic expansion valves and air movers, whose compressors vary capacity by speed, by stages or unloaders, or, on screws, by slide valve; more than one coil and expansion valve on one controller. A case or coil that keeps its thermostatic expansion valve stays outside the decision (what it replaces).
How each is commanded: Designed to command them from its own outputs on a walk-in or condensing unit; on a rack, each case valve's opening and each evaporator fan through the valve drivers and case controllers already there (where it runs).
On an industrial plant: Designed to command each compressor package through its panel's remote capacity and setpoint interface, the panel keeping oil management and the safety chain. Every command travels over the field bus agreed in the evaluation.
Standards: Designed to UL 60730-1 for automatic electrical controls, for use in equipment listed to UL 60335-2-89 where it applies, and for industrial control panels built to UL 508A; and to FCC Part 15 Subpart B emissions limits (Class A, or Class B where the installation needs it).
Interfaces and security: Designed to BACnet (ASHRAE 135) at the building interface, with IEC 62443 practice for securing that connection, and to the essential cybersecurity requirements of the EU Cyber Resilience Act.
Site codes: Field-built systems are built to ASHRAE 15, except ammonia plants, which are built to IIAR 2 in its place. An ammonia plant holding 10,000 lb or more falls under OSHA process safety management and EPA's risk management program, so fitting the controller there goes through the plant's management of change.
The plant: One controller is designed to run each refrigerant circuit, with every suction group and stage that discharges into it: a booster rack or a two-stage plant takes one, two separate circuits take two.
Sharing the load: The controllers are designed to share the load by what each machine can best spare, not by a fixed order, choosing suction and head pressures within the site's product temperature limits, with no optimizer above them.
The link between them: Over the local network, BACnet or the plant's own field bus, within the limits and schedules the plant or building system sets; condenser fans that two circuits share are designed to be set together.

Signals

What it reads, and what it drives.

The measurements it is designed to work from and the devices it is designed to command; channel counts are set in the evaluation.

Show the signals

Readings in, one controller in the middle, every actuator out.

Designed to read, refrigerant: Suction and discharge pressure, which the control and the estimate are designed around, and refrigerant temperature at the compressor, condenser and evaporator outlets and at each additional heat exchanger.
Designed to read, air and fluid: Air temperature into and out of the coils, and ambient; store or case-room humidity, for the anti-sweat heaters and demand defrost; entering and leaving fluid temperature on a machine with a fluid loop; refrigerant mass flow and compressor current where they are fitted.
Designed to read, from the plant: Where a plant already reports them: vessel levels and liquid temperatures, pump pressures, purger run time, and each case's air temperatures and valve opening.
Designed to estimate: The conditions inside the coils, from those same readings.
Designed to drive, compressors: Compressor capacity (by speed, by stages and unloaders, or on screws by slide valve and volume ratio (Vi), with economizer and liquid injection where fitted, across one or several compressors per stage).
Designed to drive, valves, heaters and fans: Electronic expansion valves, closed to open; on CO₂ the gas-cooler and receiver valves, on ammonia the vessel level and liquid-feed valves; defrost valves and heaters, and case anti-sweat heaters; fans, blowers and pumps where the machine carries them. Each by the command path under What it fits.
Designed to take from above: Case, room or delivered-air temperature setpoints, schedules, operating-mode requests (such as fans off for a door opening or cleaning) and demand-response requests (grid response), all as goals from the building or plant system, designed to be answered inside the machine's limits.
Designed to report up: Present power, the power the machine would draw without the request, the shed or add achieved, how long it can hold, and fault flags with the likely cause (Fault detection).

Protection and conditioning

What runs on the controller itself.

As in today's valve drivers and rack controllers, these protections are designed to run on the controller itself, from the machine's own pressure and temperature sensors; the difference is that they serve one decision.

Show the protections

Superheat and subcooling: Designed to be computed on the controller from the machine's suction and discharge pressure and refrigerant temperatures, with nothing added where those transmitters are fitted, and read against the dew-point and bubble-point tables it holds for the refrigerant, since blends such as R-448A and R-449A glide as they boil.
Command range: Every command is designed to be held inside the actuator's commanded range before it leaves the controller.
Rate limits: Each channel is designed to carry its own rate limit, so the controller cannot slam an actuator.
Compressor pressure limit: The compressor command is designed to be screened against a maximum discharge pressure before it is sent.
Measurement conditioning: Temperature, pressure and flow measurements are each designed to be filtered on their own terms, so a slow filter on one noisy channel does not delay the rest.

Fault detection

The cause and where to look, before the truck rolls.

A warm-case alarm names a symptom; so does a compressor's low-suction trip. A supervisor or a monitoring service may attach the causes that usually go with that alarm, but someone on site still has to rule them out. This controller is designed to do that on the machine, from what physics says each reading should be, before anyone is sent.

Leaks make the case. EPA has estimated that the average US supermarket leaks about a quarter of its charge a year, and US supply of HFCs is being cut 85 percent by 2036.

Pressures and efficiency can stay quiet until much of the charge is gone, so the controller is designed to count the refrigerant itself, and to say when the charge cannot yet be judged.

Show what it tells apart

The model that sets the actuators is designed to predict each pressure, temperature, flow and current, within its own margin of error, because physics ties each to the others.

When a reading disagrees, the controller is designed to read the pattern for the reason: one reading off while those tied to it agree points to the sensor; several moving together, to the machine, and the way they move, to the part.

Sensor or machine: Wherever liquid and vapor sit together at rest, the refrigerant's own properties tie pressure to liquid temperature, allowing for a blend's glide and for a receiver held up by discharge gas.
A sensor named: A sensor that breaks that tie while its neighbors agree, other pressure readings on the same vapor included, is designed to be named as the sensor, before it misleads the control or sends a technician after a fault that is not there.
Or the refrigerant: Air, water or oil in the refrigerant breaks the same tie. A vessel whose pressure readings agree with each other but not with the saturation pressure at its liquid's temperature is designed to be flagged as contaminated, for a refrigerant sample.
Three flows, one answer: The compressor, the expansion valve and the heat balance each give the refrigerant flow, each within its own margin (a compressor map's can be wide).
Which flow is off: Designed to compare all three, allowing for gas drawn off for defrost or heat reclaim: valve and heat balance agreeing against the compressor point to the compressor; the valve disagreeing with both, to the valve or the line feeding it.
The charge, counted: Designed to follow the refrigerant wherever it sits and to predict how it moves with weather, load and defrost, so a shortfall in the total reads as a loss: pounds gone, pounds a week, and since when.
With a level transmitter: On a rack that carries a level transmitter, the loss is designed to be read as the gap between the receiver level the model predicts and the level the transmitter shows.
Level, or no level: Many racks show the level only on a sight glass or report it only through a low-level switch. With a transmitter, a slow leak is designed to show as a trend in pounds, not, as it often does today, as warm cases once the receiver runs dry.
With no level measured: With no level measured and reserve liquid still in the receiver, the controller is designed to say the charge cannot be judged yet, rather than report no leak.
Cases and defrost: Each case's refrigerant side is designed to be checked against its air side, to tell a stopped fan from an icing coil, a blocked air path or a door left open, and a defrost that did not finish from one that was not needed.
The rack and its valves: The compressors must move what the case valves pass, and the condenser, with any heat-reclaim coil, must reject the compressors' power plus the load.
What those balances find: Against them the controller is designed to find a fouled condenser or a failed fan, a compressor or unloader that stops matching its command, air in the circuit, and a case valve, regulator or solenoid that sticks.
Wear and fouling: Designed to be reported the same way, as findings measured against the clean machine, rather than absorbed into the model.
Ranked by what waiting costs: Each finding is designed to be run back through the model at the day's conditions, to give it a cost per day and a time to act: now, this week, next visit, or watch. Safety sits at the top, then equipment damage, lost cooling and energy.
Raised on evidence, once: Designed to raise a fault when the evidence clears the model's own margin of error, not when a timer runs out, and to report a symptom once, at its cause. Ranking is designed never to hold back a safety alarm.

Show an example message

Example message, for illustration.

Rack B, medium temperature · 5:40 a.m. · three findings, most urgent at the top

1. Case 14 evaporator fan stopped. Act now.

Discharge air up 4 °F since 5:25 a.m.; superheat dropped at 5:25, and the case valve is now at a fraction of the opening this case's load calls for at the same suction. Product at risk by 9 a.m.

Bring: a fan motor for case 14. Check its breaker first.

2. Refrigerant charge falling. Act this week.

About 35 lb below where it was three weeks ago, falling about 12 lb a week: past 50 lb in under two weeks. Every defrost and two cold nights in that time are accounted for. Cases holding temperature.

Leak search, with a detector: the cases and the machine room.

3. Condenser fouling. Act at the next visit.

Heat transfer 9% below clean at the same fan speed: about 3% more compressor power, some 40 kWh a day.

Checked and normal: suction and discharge pressure transducers; receiver level transmitter, which matched the last defrost's return.

Show the leak rule

On large HFC systems a leak is also a deadline. EPA's leak rule requires repair of systems holding 15 lb or more of an HFC refrigerant once their leak rate, calculated each time refrigerant is added, passes 20 percent a year in commercial refrigeration, or 30 percent in industrial process refrigeration.

HFC refrigeration of 1,500 lb or more installed since 2017 needs automatic leak detection: from the start on systems installed since 2026, and by 2027 on the rest. A system that infers leaks from the plant's own readings must alert at a loss of 50 lb or 10 percent, whichever is less.

Where the rack carries a receiver level transmitter, the controller's charge tracking is designed to raise that alert; that has not yet been tested, and the system owner's annual audit and calibration still apply.

The technician's detector still finds the joint, and the machine-room gas detectors stay where the codes put them, because they protect people. All of it is designed to run on the machine.

CO₂ and ammonia plants have faults of their own. See the CO₂ and ammonia page.

Grid response

The grid can ask. The controller is designed to decide how.

Grid programs reward power that drops at the peak and rises when there is power to spare. On this controller a demand-response request is designed to be one more limit on the same decision over every actuator: the least total power, inside the site's product and equipment limits.

Show how it answers

On today's racks a shed is usually a fixed rule, a cap on compressor capacity or a setpoint offset, while the valves and fans stay on their own loops.

A setpoint offset guesses what it will save. The controller is designed to work it out from its model of the machine and from how fast the cases, rooms and product warm, which it is designed to learn on site from case and room air temperatures.

A request, not a command: From the building or plant system, an aggregator or the utility, through the site's own network. The controller is designed to answer inside limits set at the machine, which no request can change, and to report when a limit ends its part.
What it takes: Designed to take a setpoint or an offset, a kW cap, a cut or an increase in percent or kW, or a defrost request or delay, as a value or as a level; each level maps to limits the site sets at commissioning.
How far: Designed to shed power on request, more in a critical event, and to add load when the grid has power to spare, as long as the product's temperature limits allow.
How much, and how long: How much and how long depend on the room, the product and its mass (frozen rooms can coast far longer than chilled cases); the controller is designed to state both as each event starts, within limits set with you at commissioning.
Where each kilowatt comes from: A kW cap is designed to bound compressors, fans, pumps and defrost heaters added together: electric defrosts wait first, then compressor speed comes down, with fans and pumps rebalanced together. Over most of its range a slower compressor works across a smaller lift, so capacity falls less than power.
Shift and recover: Designed to pre-cool cases and walk-ins ahead of a peak, storing cold in the product as far as its limits allow, then coast through it with suction raised, compressors slowed, condenser fans rebalanced and electric defrosts held until after the window, inside product and ice limits, and pace the recovery so the rebound sets no new peak.
A baseline from the model: Designed to report the power the machine would have drawn without the request beside what it drew, so the site can check what it gave against the program's own baseline.
Several machines, one meter: Designed to split a kW cap from the building or plant system among themselves, over the site's own network or field bus, each giving up kilowatts where they cost the least cooling, with no optimizer above them.
CO₂: On CO₂, designed to shed with compressor capacity and suction, never by dropping the high side below its best pressure, and with heat reclaim to put a load add into the hot-water tank or heating loop as heat, for as long as it can take it.
Two-stage ammonia: On two-stage ammonia, designed to hold the interstage pressure at the split that runs the compressors coolest through the shed, as far as any loads served at the intermediate temperature allow. Why the refrigerant changes the answer.
The link: Designed to take OpenADR 2.0b requests, received by the building or plant system or a gateway and carried to the controller over wired Ethernet as named points: BACnet from a building system, or in a plant through a gateway from its own industrial protocol; IEEE 2030.5 through a gateway that translates it.
No radio, no cloud command: Designed with no Wi-Fi or Zigbee radio, and with no command path from the cloud.

Let's talk.

Tell us what you run: a refrigeration system or a machine you build.