HVAC and refrigeration optimization through combined modeling and artificial intelligence

Abstract

The present disclosure relates to computerized systems and methods for optimizing operation of cooling assets in temperature-controlled environments. A system receives operational and contextual data from sensors, controllers, and external data services, and processes the data using physics-based models and machine learning algorithms to generate predicted operational metrics. The system evaluates cost, energy, and constraint signals to determine optimized control actions for cooling assets, which may be executed automatically or with human oversight. The system dynamically adapts to changing conditions to reduce energy consumption while maintaining temperature compliance and operational continuity.

Description

RELATED APPLICATION(S)

[0001] This application claims the benefit of priority to U.S. Provisional Pat. Application No. 63 / 756,056, filed Feb. 8, 2025, which is incorporated herein by reference in its entirety.FIELD OF THE DISCLOSURE

[0002] The disclosure relates to methods and systems for monitoring, modeling, and optimizing operation of cooling assets within temperature-controlled environments.BACKGROUND

[0003] Industrial cooling methods may be inefficient, expensive, and represent a large strain on the environment. As of 2024, 20% of global electricity is used for cooling and refrigeration. Data Centers spend up to 40% of the electricity they consume exclusively on cooling. Further, the demand for cooling is expected to triple by 2050.

[0004] As electricity demand has grown, so has the price, motivating companies to prioritize energy reductions through optimization software and supplementing grid power with renewable energy sources and energy storage. Current optimization software for HVAC and Refrigeration use incomplete data sources, for example a single temperature sensor in a large cold room, to simply activate or deactivate equipment. Several relevant datapoints are collected and ignored by existing Building Management Software, and even more relevant datapoints fail to be captured.SUMMARY OF THE DISCLOSURE

[0005] The present disclosure describes data streams as inputs to a single or multi staged Artificial Intelligence (AI) systems, composed of a single model or suite of models, which optimize the use of HVAC and / or Refrigeration equipment.

[0006] In some aspects, the disclosure provides a computer-implemented method for dynamically monitoring operation of a cooling asset, the method comprising: (a) reading operational data and / or contextual data from a plurality of heterogeneous data sources; (b) generating a unified time-series dataset representing a current state of a temperature-controlled environment and the cooling asset; (c) applying a computational model to generate a predicted operational metric based on the unified time-series dataset; (d) generating a cost or constraint signal by mapping the predicted operational metric to an objective function, a threshold, or a constraint parameter; (e) determining, using an optimization model and the cost or constraint signal as an input, a candidate control action for the cooling asset that satisfies one or more operational constraints; (f) transmitting, via a communication interface, the determined candidate control action to the cooling asset to update at least one operational parameter; (g) monitoring the updated operation of the cooling asset to verify that the temperature-controlled environment remains within a predefined temperature range; and (h) iteratively repeating steps (b) through (g) to dynamically adjust operation of the cooling asset in response to changes in the operational data and / or the contextual data while maintaining the temperature-controlled environment within the predefined temperature range. In some embodiments, iteratively repeating steps (b) through (g) comprises updating the control action in response to a detected change in electricity pricing data or electrical grid-condition data.

[0007] In some embodiments, the plurality of heterogeneous data sources comprises: a sensor physically deployed within a temperature-controlled environment for measuring temperature at a spatial location; a controller associated with the cooling asset and, one or more sensors or monitoring devices configured to provide operational data of the cooling asset; or an external data source providing contextual data comprising one or more weather data, electricity pricing data, or electrical grid-condition data.

[0008] In some embodiments, generating the unified time-series dataset comprises temporally synchronizing the operational data and the contextual data by assigning timestamps and aligning the operational data and the contextual data to a common time reference.

[0009] In some embodiments, the computational model comprises: a physics-based simulation model representing thermal behavior of the temperature-controlled environment; a machine-learning time-series forecasting model trained on historical operational data; a regression model relating environmental conditions and asset operation to energy consumption, or a combination thereof. In some embodiments, the computational model generates a digital twin of the temperature-controlled environment, the digital twin simulating thermal behavior of the temperature-controlled environment based on the operational data and the contextual data. In some embodiments, the computational model generates the predicted operational metric over a future time horizon.

[0010] In some embodiments, the predicted operational metric comprises a predicted energy consumption, a predicted operating cost, a predicted temperature deviation, or a predicted asset. In some embodiments, the predicted operational metric comprises a predicted temperature trajectory of the temperature-controlled environment.

[0011] In some embodiments, the unified time-series dataset comprises time-aligned operational data and contextual data sampled at different polling intervals.

[0012] In some embodiments, the cost or constraint signal is generated using electricity pricing data that varies as a function of time.

[0013] In some embodiments, the one or more operational constraints comprise a temperature constraint requiring the temperature-controlled environment to remain within a predefined temperature range, and / or an equipment protection constraint limiting operation of the cooling asset based on a parameter selected from a duty cycle, a runtime duration, a cycling frequency, and an operating state of the cooling asset.

[0014] In some embodiments, the optimization model evaluates the candidate control action by computing a score, value, or utility function based on the cost or constraint signal, and / or by optimizing an objective function subject to the one or more operational constraints. In some embodiments, the optimization model comprises a machine-learning or probabilistic decision model configured to select the control action based on an expected reward or penalty.

[0015] In some embodiments, the at least one operational parameter comprises a temperature setpoint, a defrost schedule or an operating mode of the cooling asset.

[0016] In some embodiments, monitoring the operational data or the contextual data comprises comparing the operational data or the contextual data to the predicted operational metric and detecting a deviation when a difference exceeds a predefined threshold. In some embodiments, detecting the deviation from the predicted operational metric causes re-simulation, or updating of the computational model or the optimization model.

[0017] In some embodiments, the control action modifies physical operation of the cooling asset by causing a change in electrical power consumption of the cooling asset.

[0018] In some aspects, the disclosure provides a system comprising: a computing node comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor of the computing node to cause the processor to perform a method comprising: (a) reading operational data and / or contextual data from a plurality of heterogeneous data sources; (b) generating a unified time-series dataset representing a current state of a temperature-controlled environment and the cooling asset; (c) applying a computational model to generate a predicted operational metric based on the unified time-series dataset; (d) generating a cost or constraint signal by mapping the predicted operational metric to an objective function, a threshold, or a constraint parameter; (e) determining, using an optimization model and the cost or constraint signal as an input, a candidate control action for the cooling asset that satisfies one or more operational constraints; (f) transmitting, via a communication interface, the determined candidate control action to the cooling asset to update at least one operational parameter; (g) monitoring the updated operation of the cooling asset to verify that the temperature-controlled environment remains within a predefined temperature range; and (h) iteratively repeating steps (b) through (g) to dynamically adjust operation of the cooling asset in response to changes in the operational data and / or the contextual data while maintaining the temperature-controlled environment within the predefined temperature range.

[0019] In some aspects, the disclosure provides a computer program product, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions being executable by a processor to cause the processor to perform a method comprising: (a) reading operational data and / or contextual data from a plurality of heterogeneous data sources; (b) generating a unified time-series dataset representing a current state of a temperature-controlled environment and the cooling asset; (c) applying a computational model to generate a predicted operational metric based on the unified time-series dataset; (d) generating a cost or constraint signal by mapping the predicted operational metric to an objective function, a threshold, or a constraint parameter; (e) determining, using an optimization model and the cost or constraint signal as an input, a candidate control action for the cooling asset that satisfies one or more operational constraints; (f) transmitting, via a communication interface, the determined candidate control action to the cooling asset to update at least one operational parameter; (g) monitoring the updated operation of the cooling asset to verify that the temperature-controlled environment remains within a predefined temperature range; and (h) iteratively repeating steps (b) through (g) to dynamically adjust operation of the cooling asset in response to changes in the operational data and / or the contextual data while maintaining the temperature-controlled environment within the predefined temperature range.BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The accompanying drawings, which are incorporated into and constitute a part of this specification, illustrate various exemplary embodiments and together with the description, serve to explain the principles of the disclosed embodiments.

[0021] FIGS. 1A-1B illustrate a schematic methodology for monitoring and controlling operation of a cooling asset within a temperature-controlled environment, in accordance with one or more embodiments of the present disclosure.

[0022] FIG. 2 is a diagram outlining the proposed process for single-staged AI system, in accordance with one or more embodiments of the present disclosure.

[0023] FIG. 3 is a diagram outlining a process for an embodiment of a multi-staged AI system, in accordance with one or more embodiments of the present disclosure.

[0024] FIG. 4 is a schematic diagram of an exemplary computing node.DETAILED DESCRIPTION

[0025] In order for the present disclosure to be more readily understood, certain terms are first defined below. Additional definitions for the following terms and other terms are set forth throughout the specification. The publications and other reference materials referenced herein to describe the background of the disclosure and to provide additional detail regarding its practice are hereby incorporated by reference.

[0026] Unless otherwise defined, (i) the terms “a” and “an” are used herein to refer to one or to more than one (i.e., to at least one) of the grammatical object of the article; (ii) the term “or” may be understood to mean “and / or”; (iii) the terms “comprising” and “including” may be understood to encompass itemized components or steps whether presented by themselves or together with one or more additional components or steps; and (iv) where ranges are provided, endpoints are included.

[0027] As used herein, the term “asset strain” or “predicted asset strain” refers to a condition indicating increased operational stress on a cooling asset, which may be quantified as a single value or a vector comprising one or more metrics, including compressor duty cycle, cycling frequency, runtime required to achieve a setpoint, degradation in temperature recovery rate, expected electrical power draw, energy consumed per unit of cooling, deviation from expected energy consumption, likelihood of exceeding temperature constraints, or predicted time to constraint violation, as generated by first-stage regression, anomaly detection, or comparable analytical models and used downstream by optimization or control logic. Predicted asset strain may be computed from a unified time-series of operational and / or contextual data over a future horizon and evaluated to balance efficiency, equipment protection, and / or temperature compliance.

[0028] As used herein, the term “candidate control action” refers to a proposed modification to operation of a cooling asset as evaluated by an optimization model before selection and enforcement, and may include updating temperature setpoints (including pre-cool or coast setpoints), modifying defrost intervals or cutoff conditions, changing operating modes or compressor staging, and issuing commands that alter electrical power consumption, whether communicated to a Building Management System (BMS), a temperature controller, or an edge device for execution. Candidate control actions may be scored against cost or constraint signals and operational constraints prior to selection as a “selected control action.”

[0029] As used herein, the term “communication interface” refers to a hardware or software interface configured to transmit control actions or data between computing nodes, controllers, sensors, or cooling assets, including application programming interfaces, message-oriented protocols such as Message Queuing Telemetry Transport (MQTT) with brokered topics, serial interfaces such as Modbus Remote Terminal Unit (RTU) (including USB-RS485-proprietary serial chains), Ethernet, Wi-Fi, cellular, or comparable pathways, supporting encrypted transport, acknowledgments, and scheduled enforcement messages. Communication interfaces may support polling, event-driven updates, buffering and retransmission, and safe fallback behavior during connectivity loss.

[0030] As used herein, the term “computational model” refers to a mathematical, physics-based, statistical, Bayesian, or machine learning model configured to process a unified time-series dataset and generate one or more predicted operational metrics, including digital twin simulations of thermal behavior, time-series forecasting models, regression models, Bayesian inference or probabilistic models, and reinforcement learning models that may operate alone or in combination to improve prediction robustness. Computational models may run periodically or be event driven, and may be trained, validated, updated, or probabilistically calibrated using historical operational data collected from deployment sites.

[0031] As used herein, the term “contextual data” refers to data external to the cooling asset that influences operation or optimization decisions, including weather and forecast data, time-varying electricity pricing, grid-condition signals, occupancy or door events, and availability or efficiency of on-site distributed energy resources, obtained via external or local Application Programming Interfaces (APIs) with priority, fallback, and validation rules to ensure reliability. Contextual data may be polled at configurable intervals and used to inform predicted metrics, cost signals, or grid-responsive strategies.

[0032] As used herein, the term “cooling asset” refers to any electrically powered system or component configured to remove heat from a temperature-controlled environment, including refrigeration units, freezers, chillers, compressors, evaporators, condensers, fans, and combinations thereof, and may be monitored or controlled via a temperature controller, programmable logic controller, or a Building Management System.

[0033] As used herein, the term “cost or constraint signal” refers to a value or set of values derived by mapping a predicted operational metric to an objective function, threshold, or constraint parameter, including but not limited to mapping predicted energy to time-varying tariffs to produce forecasted operating cost; incorporating grid-condition signals indicating events, penalties, or incentives; and encoding temperature or equipment protection limits used to evaluate candidate control actions. Cost or constraint signals may be computed over short-or medium-term horizons and updated when contextual data changes.

[0034] As used herein, the term “heterogeneous data sources” refers to multiple data sources of different types, origins, formats, or sampling intervals, including sensors deployed in the environment, controller or BMS data, edge device logs, and external or local APIs, with data synchronized and standardized for downstream modeling and control. Heterogeneous data sources may include temperature, humidity, electrical current, door state, asset runtime, weather, tariffs, and grid-condition signals.

[0035] As used herein, the term “operational constraint” refers to a limitation on operation of a cooling asset or temperature-controlled environment, including temperature compliance ranges, equipment protection limits defined by duty cycle, runtime duration, cycling frequency, or operating state, as well as business-driven or grid-driven restrictions, which the optimization model respects when evaluating or selecting control actions.

[0036] As used herein, the term “operational data” refers to data characterizing the operating state or behavior of a cooling asset or temperature-controlled environment, including temperature and humidity measurements, compressor and fan states, defrost status and parameters, controller setpoints and differentials, door events, electrical current or power, alarms, and derived aggregates, collected via sensors, controllers, BMS integrations, or edge devices at configurable polling intervals or on state changes.

[0037] As used herein, the term “optimization model” refers to a model configured to evaluate or select candidate control actions for a cooling asset based on one or more cost or constraint signals and one or more operational constraints, which may compute scores or utility values or optimize an objective function subject to constraints, and in some embodiments may comprise a reinforcement learning agent selecting actions based on expected rewards or penalties. The optimization model may operate in single-stage or multi-stage deployments and produce recommended or automatically enforced control commands.

[0038] As used herein, the term “predicted operational metric” refers to a value generated by a computational model that represents a forecasted or inferred aspect of future or current system behavior, including predicted temperature trajectories, energy consumption, operating cost, temperature deviation, or asset strain, generated over configurable horizons for use in downstream cost mapping and control evaluation.

[0039] As used herein, the term “temperature-controlled environment” refers to a physical space in which temperature is actively regulated by one or more cooling assets, including cold storage rooms, refrigerated warehouses, freezers, server rooms, data centers, and similar environments, which may be instrumented with spatially distributed sensors and integrated with controllers, BMSs, and edge devices.

[0040] As used herein, the term “unified time-series dataset” refers to a structured dataset in which operational and contextual data from heterogeneous sources are temporally aligned to a common time reference by assigning timestamps, synchronizing clocks (e.g., via Network Time Protocol), standardizing formats and units, and storing the resulting time-indexed records in time-series databases that support hot and cold storage tiers for analysis, visualization, and modeling. The unified dataset may include data sampled at different polling intervals and supports both periodic and event-driven records.

[0041] Reference will now be made in detail to the exemplary embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

[0042] The systems, devices, and methods disclosed herein are described in detail with reference to the figures. None of the features or components shown in the drawings or discussed below should be taken as mandatory for any specific implementation of any of these devices, systems, or methods unless specifically designated as mandatory.

[0043] For any methods described, regardless of whether the method is described in conjunction with a flow diagram, it should be understood that unless otherwise specified or required by context, any explicit or implicit ordering of steps performed in the execution of a method does not imply that those steps must be performed in the order presented but instead may be performed in a different order or in parallel.

[0044] As used in this application, the terms “system” and “component” are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are described herein. For example, a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and / or magnetic storage medium), an object, an executable, a thread of execution, a program, and / or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and / or thread of execution, and a component can be localized on one computer and / or distributed between two or more computers.

[0045] Further, components may be communicatively coupled to each other by various types of communications media to coordinate operations. The coordination may involve the uni-directional or bi-directional exchange of information. For instance, the components may communicate information in the form of signals communicated over the communications media. The information can be implemented as signals allocated to various signal lines. In such allocations, each message is a signal. Further embodiments, however, may alternatively employ data messages. Such data messages may be sent across various connections. Exemplary connections include but are not limited to parallel interfaces, serial interfaces, and bus interfaces.

[0046] Conventional approaches to controlling heating, ventilation, air conditioning, and refrigeration (HVAC&R) assets are predicated on simplified control logic and limited, often incomplete, operational data. Accordingly, such conventional approaches exhibit significant performance degradation when confronted with complex, dynamic environments in which thermal behavior is influenced by heterogeneous data sources, including spatially distributed temperature sensors, variable weather conditions, fluctuating electricity pricing, operational schedules, occupancy patterns, and grid-condition signals. In many deployed systems, control decisions are based on a small subset of available data, such as a single temperature probe or a static schedule, without accounting for spatial temperature variation, asset strain, thermal inertia, or future contextual conditions. As a result, these systems may overcool or undercool environments, increase compressor cycling, accelerate equipment wear, and consume excess electrical energy. Furthermore, conventional HVAC&R control systems are typically unable to forecast future operating conditions, generate cost-aware or grid-responsive control strategies, or adapt dynamically to changes in operating constraints. This can lead to inefficient energy use, higher operating costs, and increased manual intervention by operators. Various embodiments described herein address these shortcomings by enabling dynamic, data-driven optimization of HVAC and refrigeration assets through the use of unified time-series data, computational modeling, and artificial intelligence-based optimization

[0047] FIGS. 1A-1B illustrate an exemplary method 100 for dynamically monitoring and controlling operation of a cooling asset within a temperature-controlled environment using computational models and optimization techniques, according to one or more embodiments of the present disclosure. The steps of method 100 presented below are intended to be illustrative, and the steps of exemplary method 100 (e.g., steps 102-116) may be performed automatically or in response to a request from a user. Additionally, the order in which the steps of method 100 are illustrated and described below is not intended to be limiting.

[0048] In some embodiments, method 100 may be implemented in one or more processing devices, such as one or more digital processors, analog processors, digital circuits designed to process information, analog circuits designed to process information, state machines, edge computing devices, cloud-based computing systems, and / or other mechanisms for electronically processing information. The one or more processing devices may execute some or all of the operations of method 100 in response to instructions stored electronically on one or more non-transitory electronic storage media. The one or more processing devices may be configured through hardware, firmware, software, or any combination thereof to perform one or more of the operations of method 100. In some implementations, one or more operations of method 100 are performed in parallel, asynchronously, or in a distributed computing environment.

[0049] Step 102 may include reading operational data and / or contextual data from a plurality of heterogeneous data sources. In some embodiments, the plurality of heterogeneous data sources includes a sensor physically deployed within a temperature-controlled environment for measuring temperature at a spatial location; a controller associated with the cooling asset and one or more sensors or monitoring devices configured to provide operational data of the cooling asset; and / or an external data source providing contextual data comprising one or more weather data, electricity pricing data, or electrical grid-condition data.

[0050] In some embodiments, the operational data received by the system is generated by one or more Internet-connected thermal sensors deployed within or proximate to the temperature-controlled environment. As used herein, the term “Internet-connected thermal sensors” or “Internet-connected sensors” refers to Internet of Things (IoT) sensors or other network-enabled sensing devices capable of communicating sensor data over a wired or wireless network to one or more computing systems, gateways, or controllers. In some embodiments, the one or more IoT sensors may comprise temperature sensors, humidity sensors, door or contact sensors, electrical current sensors, or combinations thereof. The one or more IoT sensors may be configured to communicate wirelessly using one or more communication protocols, including but not limited to WiFi, Bluetooth, Long Range Wide Area Network (LoRaWAN), Zigbee, Z-Wave, Matter, proprietary radio-frequency protocols, or mesh networking protocols.

[0051] In some embodiments, the one or more IoT sensors may further comprise a temperature or humidity sensor configured to measure ambient temperature and relative humidity within the temperature-controlled environment, respectively. The temperature and / or humidity sensor may be mounted on walls, ceilings, shelving, thermal energy storage components, heat sinks, or other structural elements of the environment. In some embodiments, the one or more IoT sensors are affixed using adhesive, magnets, mechanical fasteners, or integrated mounting features. In some embodiments, the temperature or humidity sensor is mounted directly on or within a thermal energy storage medium, including a phase change material (PCM). The temperature or humidity sensor may include probes inserted into the PCM or sensors affixed to an external casing of the PCM or heat sink. The temperature and / or humidity measurements obtained from such sensors may be used to infer a state of charge, phase state, or thermal capacity of the thermal energy storage medium. In some embodiments, a temperature and / or humidity sensor is spatially distributed throughout the temperature-controlled environment to capture spatial temperature variation and stratification. In some embodiments, at least one temperature and / or humidity sensor is deployed in each corner of the temperature-controlled environment. In some embodiments, the temperature and / or humidity sensor is deployed at a common vertical height. In some embodiments, the temperature and / or humidity sensor is deployed at different vertical heights comprising near floor level or mid-wall height, to account for vertical temperature stratification. In some embodiments, at least eight temperature and / or humidity sensors are deployed per zone of the temperature-controlled environment. In some embodiments, the temperature and / or humidity sensor transmits measurements at configurable sampling intervals. The sampling interval may be as frequent as about one measurement per minute or may be less frequent, including intervals of about 5 minutes. The sampling interval may be adjusted dynamically based on system configuration, sensor capability, or operational requirements.

[0052] In some embodiments, the one or more IoT sensors comprise a door or contact sensor configured to detect opening and closing of one or more doors associated with the temperature-controlled environment. The door sensor may be implemented using one or more sensing modalities, including magnetic contact sensors, optical sensors, or time-of-flight distance sensors. In some embodiments, the sensor component is affixed to a door frame, and the magnet is affixed to the door, such that separation of the sensor component and magnet indicates an open door state and proximity indicates a closed door state. In some embodiments, the positions of the sensor component and magnet are reversed. In some embodiments, the door or contact sensor comprises a time-of-flight or laser-based distance sensor configured to measure a distance between the sensor and a door surface or reference point, wherein a change in measured distance beyond a threshold indicates a door opening event. In some embodiments, the door or contact sensors transmit a door state indicating whether the door is open or closed and may further transmit timestamps or durations associated with door opening events. The door state data may be used to detect heat ingress events and to estimate thermal disturbance of the temperature-controlled environment. In some embodiments, the door sensors transmit data at fixed intervals, or in response to detected state changes.

[0053] In some embodiments, the one or more IoT sensors comprise an electrical current sensor monitoring electrical load drawn by the cooling asset. The electrical current sensor may comprise a single-phase or multi-phase sensor depending on the configuration of the cooling asset. In some embodiments, the electrical current sensor comprises a clamp-style sensor configured to be positioned around electrical conductors supplying power to compressors, evaporators, condensers, fans, or other components of the cooling asset. In some embodiments, the electrical current sensor may measure electrical current directionally, the measured electrical current is transmitted in real time or in an event-driven manner. In some embodiments, the electrical current data may be used to infer instantaneous power consumption, duty cycles, compressor cycling behavior, or operational state of the cooling asset. In some embodiments, the electrical current sensor may transmit measurements at intervals as frequent as about 1 minute or at longer intervals, including intervals of about 5 minutes.

[0054] In some embodiments, the one or more IoT sensors communicate with a locally deployed gateway device. In some embodiments, the gateway device may be configured to receive sensor data via one or more wireless communication protocols, including LoRaWAN, WiFi, Bluetooth, Zigbee, Z-Wave, Matter, proprietary radio-frequency protocols, or mesh networking protocols. In some embodiments, the gateway device may aggregate data from multiple sensors and perform local preprocessing, buffering, or validation of the sensor data. In some embodiments, the gateway device transmits aggregated sensor data to a remote backend system using a message-oriented communication protocol, including but not limited to MQTT, HTTP-based APIs, or other comparable protocols. The communication between the gateway device and the remote backend may be encrypted and may occur over a local area network, a wide area network, or a cellular network using a subscriber identity module (SIM). In some embodiments, the gateway device communicates with the remote backend system via a site WiFi or a cellular network. In some embodiments, the gateway device functions as a router, enabling the one or more IoT sensors to join a local network managed by the gateway device and to route sensor data to the remote backend system or to a cloud backend hosted by a sensor manufacturer. In some embodiments, the sensor data is transmitted directly from the one or more IoT sensors to a cloud backend hosted by a sensor manufacturer using proprietary communication protocols. The cloud backend hosted by the sensor manufacturer may expose an application programming interface (API) through which the system retrieves the sensor data. In some embodiments, sensor data is transmitted from the one or more IoT sensors to the gateway device and then forwarded to the system backend via an API, a message broker, or a virtual private network connection. In some embodiments, the gateway device is configured to support multiple sensor manufacturers and sensor types concurrently. In some embodiments, the gateway device may normalize or tag sensor data received from different sensors to enable unified ingestion and processing by the backend system. In some embodiments, the gateway device may further buffer sensor data locally in the event of a communication interruption and transmit the buffered data when connectivity is restored.

[0055] In some embodiments, the system comprises an edge computing device deployed on site within or proximate to the temperature-controlled environment. The edge computing device may comprise microcomputers, microcontrollers, or other embedded computing platforms capable of executing program instructions. In some embodiments, the edge computing device may execute software written in one or more programming languages, including Python or MicroPython, and to communicate wirelessly via WiFi or other communication protocols.

[0056] In some embodiments, the edge computing device comprises a local power source or backup power capability for maintaining operation for a predetermined duration in the event of a power outage. In some embodiments, the edge computing device comprises a battery power sufficient to maintain operation for at least 1 hour following loss of external power, enabling continued monitoring and control of the cooling asset during transient power disruptions. In some embodiments, the edge computing device may communicate directly with one or more temperature controllers or programmable logic controllers (PLCs) associated with the cooling asset. The communication may occur via one or more communication pathways, including a serial communication, Ethernet communication, wireless communication, or combinations thereof. In some embodiments, the serial communication comprises communication using Modbus RTU or other industrial control protocols. In some embodiments, the edge computing device communicates with a temperature controller through a serial interface comprising a plurality of intermediate converters. For example, the edge computing device may communicate via a universal serial bus (USB) interface to a USB-to-RS485 converter, which in turn communicates with an RS485-to-proprietary serial converter connected to a temperature controller. The temperature controller may expose operational data and control parameters through the proprietary serial interface.

[0057] In some embodiments, the edge computing device may read operational parameters from the temperature controller, including temperature setpoints, measured temperatures, operational states, or alarm conditions. The edge computing device may periodically read the operational parameters at configurable intervals and transmit the operational parameters to a remote backend system. In some embodiments, the edge computing device may periodically read the operational parameters at intervals of about 1-30 minutes. In some embodiments, the edge computing device may periodically read the operational parameters at intervals of about 5 minutes.

[0058] In some embodiments, the edge computing device transmits operational data to the remote backend system using a message-oriented communication protocol, including but not limited to Message Queuing Telemetry Transport (MQTT). In some embodiments, the edge computing device may publish messages to a message broker accessible by the backend system, and the messages may include timestamps and identifiers associated with the cooling asset and deployment site.

[0059] In some embodiments, the system communicates with one or more BMS associated with a temperature-controlled environment. Communication with a BMS may occur via a manufacturer-provided application programming interface (API), a middleware integration layer, or other programmatic interface. In some embodiments, the system periodically polls the BMS to read operational data associated with one or more cooling assets.

[0060] In some embodiments, the system polls the BMS API at regular intervals to retrieve operational data. In some embodiments, the system polls the BMS API at intervals of about 1-30 minutes. In some embodiments, the system polls the BMS API at intervals of about 5 minutes.

[0061] In some embodiments, the operational data read by the system may include temperature and humidity measurements obtained from sensors deployed by the system or from sensors deployed by a customer and integrated via a BMS or similar system. In some embodiments, the system calculates an aggregate room temperature based on measurements from one or more IoT sensors by computing a mean, weighted mean, median, or other statistical representation of the sensor measurements. In some embodiments, the operational data read by the system further comprise probe temperature measurements obtained from a temperature controller, evaporator or coil temperature measurements, configured temperature setpoints, temperature differentials, and internal calibration parameters associated with the temperature controller. The operational data and / or contextual data may further comprise compressor state information, compressor runtime duration, defrost state information, fan state information, door state information, or alarm conditions including temperature (e.g., alarms or door alarms). In some embodiments, the operational data is polled from one or more sources at configurable polling intervals. For example, operational data from a temperature controller may be polled at intervals of about 60 seconds, while data from certain sensors may be polled at intervals of about 5 minutes. In some embodiments, operational data is logged in response to detected state changes rather than at fixed intervals.

[0062] In some embodiments, the system further integrates data from one or more probes associated with a temperature controller, including probes configured to measure room temperature, evaporator temperature, or auxiliary temperature parameters. The sensor and probe data may be collected and processed by one or more edge computing devices associated with corresponding zones of the temperature-controlled environment. In some embodiments, each zone of the temperature-controlled environment is associated with a corresponding edge computing device configured to aggregate sensor data, communicate with the temperature controller, and transmit data to a backend system. The aggregated data enables artificial intelligence models to infer spatial temperature behavior, detect heat ingress events, and generate optimized control actions for the cooling asset.

[0063] In some embodiments, the system interfaces with a BMS configured to monitor and control energy usage of assets within an operational site. The BMS may store real-time and historical data locally on an edge computing device or remotely in a cloud-based system. The data may include cooling asset runtime history, corresponding energy consumption, and asset-specific operational parameters including refrigerant pressure, chilled water supply temperature, or discharge air temperature. The BMS may further provide control capabilities to activate, deactivate, or modulate operation of HVAC or refrigeration assets.

[0064] In some embodiments, the system reads contextual data from one or more external data sources, including weather data APIs and electricity pricing APIs. Weather data may be polled at intervals of about 15 minutes, while electricity pricing data may be polled daily, periodically, or at shorter intervals depending on market conditions and data availability. In some embodiments, polling frequency may be increased or decreased based on system configuration or operational requirements.

[0065] Data from APIs includes, but is not limited to, real-time weather (e.g., temperature, humidity, windspeed and direction, cloud cover, UV Index, etc.), near future weather (e.g., those same conditions 30 minutes, 1 hour, or 3 hours, etc. in the future), real time grid electricity prices, projected grid electricity prices, historical grid electricity prices, and alerts on grid strain conditions (e.g., real-time and planned penalties for overuse or rewards for underuse issued by governments, utility providers, or third parties).

[0066] In some embodiments, contextual data is obtained from one or more local data sources deployed at or near the temperature-controlled environment, including local weather stations. The local weather stations may include internet-connected sensors configured to measure wind speed, wind direction, humidity, temperature, or combinations thereof. In some embodiments, the local weather stations are hosted on the same site as the cooling asset or associated business assets and provide microclimate-specific data that supplements or replaces contextual data obtained from regional data sources accessed via application programming interfaces.

[0067] In some embodiments, one or more locally operated weather stations expose sensor data via an application programming interface, enabling programmatic access to local environmental conditions. The local contextual data may be used in place of, or in combination with, regional contextual data corresponding to a broader geographic area associated with the deployment site.

[0068] In some embodiments, the system applies a data priority logic to select contextual data used for control decisions. The data priority logic may designate locally sourced sensor data as a primary data source due to increased accuracy for site-specific microclimate conditions. When local sensor data is available and determined to be valid, the system may preferentially use the local sensor data rather than regional contextual data obtained via an external API. In some embodiments, regional contextual data is used as a fallback when local sensor data is unavailable or invalid.

[0069] In some embodiments, regional contextual data includes weather forecasts and grid-related data applicable to a geographic region associated with the deployment site, including a utility service region or grid region. The regional contextual data may correspond to an area larger than the deployment site and may be identified based on administrative or grid boundaries rather than precise site coordinates.

[0070] In some embodiments, the system comprises one or more IoT sensors for monitoring electrical power consumption of a plurality of machines and assets within a facility. The monitored assets may include cooling equipment as well as non-cooling assets that contribute to overall thermal or electrical load within the environment, including computing equipment, lighting systems, manufacturing equipment, power generation or storage equipment, and electric vehicle charging infrastructure. The electrical current measurements provide asset-specific or aggregated indicators of electrical demand within the facility.

[0071] In some embodiments, electrical consumption data is combined with business operational data to provide additional context for modeling cooling demand. The business operational data may include records of goods moving into or out of a facility, historical demand patterns for computing or telecommunications workloads, and employee ingress or egress information derived from access control systems. The combined data provides a contextual representation of facility activity levels that influence thermal load and cooling demand.

[0072] In some embodiments, the system further receives data from a battery management system associated with on-site electrical energy storage. The battery management system may provide real-time data indicating available stored energy, instantaneous power limits, state of charge, and operational constraints governing use of the stored energy. The battery-related data may be provided as an input to a second-stage optimization model to inform control of cooling assets with the goal of reducing grid electricity consumption.

[0073] In some embodiments, the battery management system communicates with a programmable logic controller, an energy management system, or a BMS via hardwired or wireless communication. The system may account for restrictions on use of stored energy, including priority reservations for other processes or assets, when determining whether stored energy is available for operation of HVAC or refrigeration equipment.

[0074] Step 104 may include generating a unified time-series dataset representing a current state of a temperature-controlled environment and the cooling asset. In some embodiments, generating the unified time-series dataset comprises temporally synchronizing the operational data and the contextual data by assigning timestamps and aligning the operational data and the contextual data to a common time reference. In some embodiments, the unified time-series dataset comprises time-aligned operational data and contextual data sampled at different polling intervals.

[0075] In some embodiments, generating the unified time-series dataset is performed by a backend system. In some embodiments, the backend system is hosted in a cloud computing environment and comprises a database for storing operational data received from edge computing devices, sensors, and external data sources. The databases may include structured query language (SQL) databases, time-series databases, or combinations thereof. In some embodiments, recent operational data may be stored in a hot storage tier, while older operational data may be stored in a cold storage tier. In some embodiments, the backend system comprises a data ingestion pathway for receiving operational data via a message broker. The backend system may include automated processes reading messages from the message broker, validate the received data, and store the data in the database. Data received from different sources may have different units, data types, or naming conventions. In some embodiments, the backend system standardizes operational data by storing the data in its original format as received from each source and performing unit conversion, normalization, or aggregation when the data is retrieved for analysis, visualization, or modeling. In some embodiments, standardization of the operational data is performed using a preprocessing operation applied by the backend system prior to analysis or modeling. This approach enables ingestion of heterogeneous data sources without requiring uniform formatting at the point of collection. The time-series database supports time-based queries, aggregation, and dynamic adjustment of polling / write frequencies or communication pathways based on performance, data availability, network conditions, or operational requirements.

[0076] In some embodiments, the preprocessing operation applied by the backend system comprises a unit normalization across heterogeneous sensor types, a timestamp alignment or resampling to a common temporal resolution, handling of missing data using interpolation, outlier detection based on physical plausibility thresholds, or a combination thereof.

[0077] In some embodiments, the edge computing devices may perform clock validation and synchronization logic during startup or reboot. The edge computing devices may compare internal clock measurements against clocks of other devices on a local network, including other edge computing devices, to detect and correct time drift. This synchronization logic reduces loss of temporal alignment when devices are powered off or disconnected for extended periods of time.

[0078] In some embodiments, the system supports future integration with enterprise BMS using standardized communication protocols, including BACnet. The system may map control points and data points between the standardized protocol and internal data representations used by the system. In some embodiments, the system synchronizes timestamps associated with operational data using a system clock maintained by an edge computing device. The system clock may be synchronized using a Network Time Protocol (NTP) to ensure consistent timekeeping across devices. In some embodiments, timestamps associated with operational data are formatted using a standardized time format (e.g., ISO 8601) and stored in a database using a time zone-aware timestamp format. In some embodiments, timestamps are stored in Coordinated Universal Time (UTC), while local time zones are applied only for display or reporting purposes. The timestamps may be formatted according to a standardized format and stored in a database using a time zone-aware timestamp type. In some embodiments, data ingestion comprises automated validation of timestamps (e.g., detection and handling of duplicate or inconsistent timestamped records). Local time zones may be applied for display purposes, while coordinated universal time may be used for storage and processing.

[0079] Step 106 may include applying a computational model to generate a predicted operational metric based on the unified time-series dataset. In some embodiments, the computational model may comprise a physics-based simulation model representing thermal behavior of the temperature-controlled environment; a machine-learning time-series forecasting model trained on historical operational data; a regression model relating environmental conditions and asset operation to energy consumption, and / or a combination thereof. In some embodiments, the computational model generates a digital twin of the temperature-controlled environment, the digital twin simulating thermal behavior of the temperature-controlled environment based on the operational data and the contextual data. In some embodiments, the computational model generates the predicted operational metric over a future time horizon.

[0080] In some embodiments, the system comprises a first-stage model architecture for generating a predicted operational metric used by a second-stage model. In some embodiments, the first-stage model architecture may comprise a physics-based simulation model serving as a foundational digital twin of the temperature-controlled environment and the cooling asset. In some embodiments, the physics-based simulation model is implemented using building energy simulation software and is validated against operational data collected from one or more pilot deployment sites to ensure parity between simulated and observed behavior. In some embodiments, the physics-based simulation model further includes one or more data-driven time-series forecasting models configured to predict future operational behavior of the cooling asset. The time-series forecasting models may be implemented using gradient-boosted decision trees or other machine-learning techniques and may be trained on historical operational data collected from the temperature-controlled environment. In some embodiments, the physics-based simulation model and the time-series forecasting models operate in parallel or in combination to improve prediction robustness.

[0081] In some embodiments, the first-stage model architecture receives a plurality of input features comprising external environmental features, internal environmental features, asset operational features, or temporal features. In some embodiments, external environmental features may comprise current and forecasted outside temperature, humidity, precipitation, or combinations thereof. In some embodiments, internal environmental features may comprise room temperature, probe temperature, evaporator temperature, or room humidity. In some embodiments, asset operational features may comprise compressor state, compressor runtime history, defrost state, or door opening events. In some embodiments, temporal features may comprise tariff period, time of day, day of week, or operational schedules associated with loading or unloading of the temperature-controlled environment.

[0082] In some embodiments, the first-stage model architecture generates an output across a prediction horizon, including short-term horizons and longer-term horizons. In some embodiments, the generated output may comprise a predicted energy consumption, a predicted temperature trajectory, or a candidate control action for the cooling asset. In some embodiments, the prediction horizons may comprise intervals in the order of minutes, hours, or longer durations, enabling both real-time and forward-looking optimization. For example, the prediction horizons may include intervals of about 5 minutes, 1 hour, 4 hours, or combinations thereof, enabling the system to evaluate immediate control actions as well as near-term and medium-term operational strategies.

[0083] In some embodiments, the first-stage model architecture is trained and validated using historical operational data collected from one or more pilot deployment sites. The training data may initially include several weeks of operational data and may expand over time as additional data is collected.

[0084] The sensor data provides contextual information around the environment being cooled, which affects the steps an operator may take when deciding how and when to activate assets, and may be utilized by a first and / or second-stage model. For example, temperature and humidity data can be used to build a first-stage model of HVAC and Refrigeration electricity consumption as a function of weather, and when coupled with real-time grid electricity prices, can be used to model the cost to run the assets under current weather conditions.

[0085] In some embodiments, the backend system may comprise infrastructure for training, validating, and testing a computational model using historical operational data. The backend system may further comprise a digital twin of a deployment site generated using a physics-based simulation software and custom time-series models. The digital twin may be used to simulate thermal behavior of the temperature-controlled environment under different control strategies.

[0086] In some embodiments, the digital twin is constructed based on known operational states of one or more cooling assets, spatial temperature measurements, detected heat sources, and material properties within the environment. The digital twin may represent operational states of the cooling assets including whether the assets are active, output temperature, and airflow characteristics, as well as locations and temperatures of heat sources derived from segmented and labeled optical or thermal image data. The digital twin may further account for door states indicating air exchange with an external environment and material properties of non-heat-generating items within the environment.

[0087] In some embodiments, the digital twin tracks a plurality of operational parameters obtained from a temperature controller via a serial communication interface. The tracked parameters may include temperature readings such as probe temperature, evaporator temperature, and configured temperature setpoints, as well as real-time electrical power consumption. The tracked parameters may further include status flags indicating compressor operation, defrost state, fan operation, door state, and alarm conditions. In some embodiments, the digital twin incorporates configuration parameters associated with the cooling asset, including temperature differentials, economy mode setpoint offsets, defrost intervals, defrost termination conditions, defrost timeouts, and high or low temperature alarm thresholds. In some embodiments, defrost parameters are dynamically controlled by the system rather than statically configured at the controller.

[0088] In some embodiments, the digital twin receives data directly from a temperature controller via a serial communication protocol and is supplemented by data from one or more internet-connected sensors deployed within the environment. External environmental conditions may be provided via one or more weather data APIs. In some embodiments, controller data is polled at intervals of about 5 minutes, with the ability to increase polling frequency to about 1 minute. Status changes may be captured in real time using event-driven logging. In some embodiments, the comprehensive state tracking enables the physics-based simulation to maintain accurate fidelity of the digital twin over time. The digital twin is continuously updated to reflect current operational conditions and is used to predict thermal behavior, evaluate control strategies, and support optimization decisions.

[0089] In some embodiments, the digital twin incorporates static or semi-static characteristics of cold storage equipment to improve simulation accuracy. The characteristics may include compressor capacity, coefficient of performance curves, compressor temperature, partial load ratio curves, fan airflow rates, fan coil surface area, or pump flow rates. In some embodiments, such characteristics are used to parameterize regression models or efficiency curves within the physics-based simulation.

[0090] In some embodiments, the digital twin models material properties of items within the temperature-controlled environment. In some embodiments, material properties may comprise phase change temperature, latent heat capacity, specific heat, thermal capacity, or charge / discharge rate characteristics. In some embodiments, material properties and / or equipment characteristics are obtained from manufacturer datasheets, literature values, or empirical measurements that are refined through calibration. In some embodiments, calibration includes applying simulation-based inference techniques using Bayesian learning to quantify uncertainty and improve parameter estimates. Controlled operating cycles may be performed to empirically validate characteristics of thermal energy storage systems, including phase change materials.

[0091] In some embodiments, the digital twin represents the temperature-controlled environment using mathematical models that enable execution of a series of computations to estimate a relative impact of individual data points on temperature behavior within the environment. The computations may generate predicted temperatures at one or more locations within the environment, enabling identification of localized hotspots, cold spots, or regions associated with inefficient airflow or thermal conduction. In some embodiments, the system applies advanced analytical techniques to analyze outputs of the digital twin and control interventions. The techniques may include causal inference methods to distinguish causal effects of control actions from confounding factors, Bayesian sensitivity analysis to quantify uncertainty and generate confidence intervals for predicted impacts, and simulation-based inference to rapidly calibrate model parameters and identify parameters that most strongly influence system behavior.

[0092] In some embodiments, the system includes a simulation framework comprising a library of representative deployment sites, operating scenarios, and edge cases. In some embodiments, the system applies federated learning techniques to share learned insights across multiple deployment sites while maintaining data locality and privacy, enabling fleet-wide optimization without centralized aggregation of raw operational data.

[0093] In some embodiments, the simulation framework includes a library of real-world scenarios and edge cases used for robustness testing and validation. The scenarios may include weather extremes, equipment faults, unexpected user interventions, and other operational anomalies. The scenario library enables evaluation of control strategies and model performance under a wide range of operating conditions.

[0094] In some embodiments, the first-stage model architecture further includes one or more regression models configured to predict future availability or efficiency of on-site or nearby distributed energy resources. For example, a regression model may use contextual data including ultraviolet index, cloud cover, ambient temperature, and electrical current output from a photovoltaic system to predict future photovoltaic energy generation over a prediction horizon. In some embodiments, the predicted photovoltaic energy generation is expressed in units of energy and provided as an input to the second-stage optimization model to inform control decisions for the cooling asset.

[0095] In some embodiments, the first-stage model architecture includes one or more regression or time-series models configured to predict wind-generated energy based on contextual data including wind speed, wind direction, and site-specific characteristics. The predicted wind-generated energy may be generated over a prediction horizon of about 1 hour and expressed in units of energy. In some embodiments, the predicted wind-generated energy is evaluated against one or more operational thresholds, such as whether sufficient energy is available to operate the cooling asset for a predetermined duration. For example, the operational threshold may comprise determining whether the predicted wind-generated energy is sufficient to operate one or more compressors for at least about 30 minutes. In some embodiments, the predicted wind-generated energy is provided as an input to the second-stage optimization model. The collection of first-stage models is not limited to the examples described herein, and additional first-stage models may be incorporated to predict other contextual or energy-related variables relevant to optimization of the cooling asset.

[0096] In some embodiments, the sensor placement strategy is informed by physics-based simulation of airflow and temperature distribution within the environment. The physics-based simulation may identify regions of expected temperature extremes or gradients and guide sensor placement accordingly. For example, distributed sensor measurements may enable the system to model spatial temperature distribution and avoid premature or delayed control actions associated with single-sensor deployments.

[0097] In some embodiments, a computational physics-based model leverages operational data and / or contextual data to map airflow and thermal behavior within a temperature-controlled environment using a computational physics model. The computational physics model may be configured to infer airflow patterns and spatial heat transfer dynamics based on sensor measurements, asset operation, and environmental conditions, thereby enabling spatially resolved prediction of temperature behavior within the environment.

[0098] In some embodiments, the computational physics-based model may predict the effect of one or more heat sources on thermal behavior of a temperature-controlled environment. The computational physics-based model may use temperature data obtained from a plurality of internet-connected thermal sensors to reconstruct airflow patterns and heat transfer within the environment. In some embodiments, the physics-based simulation of cool air flow and heat propagation is provided as an input to one or more additional first-stage models or directly to a second-stage artificial intelligence optimization model.

[0099] In some embodiments, the digital twin simulation tracks a plurality of state variables including temperature at a plurality of sensor locations representing spatial temperature distribution, compressor operating state, evaporator and condenser parameters, defrost state and timing, door state indicating heat ingress events, and external environmental conditions including ambient temperature and humidity. The state variables may be updated using real-time operational data received from controllers, sensors, and external data sources. In some embodiments, the digital twin simulation is executed at multiple temporal resolutions. A full simulation may be performed on a day-ahead basis to support operational planning. In some embodiments, additional simulation runs are performed over intermediate horizons (e.g., about 4 hours ahead) using updated real-world data to predict near-term behavior. In some embodiments, the system continuously compares actual operational data to predicted trajectories generated by the digital twin.

[0100] In some embodiments, the system accounts for heat contributions associated with people, machinery, and movable objects within a temperature-controlled environment. Humans, material handling equipment, electronic devices, and inventory may act as transient or persistent heat sources that affect thermal behavior of the environment. The system may collect data indicative of such heat sources and incorporate the data into one or more computational models used for optimized control of a cooling asset. In some embodiments, the system collects visual data from one or more optical image sensors, thermal image sensors, or combinations thereof to capture still images or video of the temperature-controlled environment. In some embodiments, a first-stage model includes a person and object detection model configured to segment and label people, equipment, or inventory present within the environment. The detected objects may be classified by type and location and provided as inputs to a second-stage model to inform asset control decisions. In some embodiments, detected people or objects are associated with nominal or measured thermal properties. For example, detected people may be assigned nominal heat output values, and detected inventory or pallets may be assigned thermal mass or heat capacity values. In some embodiments, thermal image sensors are used to directly measure heat output, reducing reliance on nominal values. The assigned thermal properties may be aggregated to estimate a total heat load within the environment or within one or more zones of the environment.

[0101] In some embodiments, estimated heat loads derived from occupancy, object detection, or door events are incorporated into a physics-based simulation model, wherein the physics-based simulation model predicts the impact of the heat loads on temperature trajectories and spatial temperature distribution. The simulation output is used to inform control strategies selected by the second-stage model (e.g., optimization model), ensuring that control actions are robust to varying occupancy and loading schedules. In some embodiments, the system analyzes detected occupancy events, door events, or object movements over time to identify recurring operational patterns (e.g., loading schedules or dwell times). The system may learn typical heat ingress patterns and detect anomalies relative to learned patterns. The learned patterns may be used to anticipate future heat loads and proactively adjust control strategies. In some embodiments, the system may includes image-based heat load estimation in which detected objects are mapped to spatial zones within the environment, heat loads are aggregated by zone, and zonal heat loads are incorporated into the physics-based simulation. The system may support use of cameras suitable for cold or frozen environments and may integrate thermal imaging to directly measure heat generation. The image-based heat load estimation may be used as an alternative to, or in combination with, door-based heat ingress estimation.

[0102] In some embodiments, the physics-based simulation ensures that heat load predictions derived from occupancy, object detection, or door events are traceable to thermodynamic principles. In some embodiments, the physics-based simulation provides interpretable intermediate outputs that enable validation of predicted temperature impacts and support explainability of control decisions generated by the optimization model.

[0103] In some embodiments, opening of one or more doors associated with the temperature-controlled environment is treated as an air exchange event that introduces warmer air into the temperature-controlled environment. The system may use data from one or more internet-connected door sensors to determine a frequency and duration of door opening events. The door event data may be provided as an input to a physics-based computational model defining an air exchange modeling framework to estimate heat ingress associated with each door opening event. In some embodiments, heat ingress associated with a door opening event is modeled as a function of one or more parameters including duration of the door opening event, a temperature differential between the temperature-controlled environment and the external environment, and one or more characteristics of the door. The heat ingress estimation may be expressed using a simplified functional relationship that is validated against observed temperature changes during door opening events. In some embodiments, the estimated heat ingress generated by the physics-based computational model is provided as an input to one or more first-stage models or to the second-stage optimization model. The estimated heat ingress may be used to predict temperature trajectory impacts and to generate control actions that compensate for anticipated disturbances caused by air exchange events.

[0104] In some embodiments, the air exchange modeling framework is refined using historical door event data to adjust one or more model parameters, including heat transfer coefficients. In some embodiments, future enhancements to the physics-based computational model include modeling pressure differentials between internal and external environments, airflow dynamics associated with high-traffic scenarios, or other factors affecting air exchange. The simulation framework enables testing of such scenarios to validate model accuracy prior to deployment in live control environments.

[0105] In some embodiments, outputs of one or more first-stage models are used to predict strain on one or more cooling assets. Strain on cooling assets may represent a multi-dimensional condition reflecting operational stress, energy efficiency degradation, compliance risk, or equipment health. The predicted strain may be generated using regression models, anomaly detection models, or other first-stage analytical models and provided as an input to downstream optimization or control logic.

[0106] In some embodiments, a predicted strain on cooling assets comprises one or more operational strain metrics selected from compressor duty cycle, compressor cycling frequency, runtime required to achieve a temperature setpoint, and degradation in temperature recovery rate. In some embodiments, the predicted strain further comprises energy-related metrics selected from expected electrical power draw, energy consumed per unit of cooling, and deviation from expected energy consumption. In some embodiments, the predicted strain may further comprise compliance or safety indicators selected from likelihood of exceeding temperature constraints and predicted time to constraint violation. In some embodiments, a predicted strain generated by first-stage models are provided as inputs to a second-stage model. The second-stage model may evaluate predicted strain in combination with other predicted operational metrics to determine control actions including temperature setpoints, defrost timing, or compressor staging. The second-stage model may balance competing objectives including efficiency, asset protection, and temperature compliance.

[0107] In some embodiments, data obtained from the BMS and the battery management system is provided as an input to one or more first-stage regression or predictive models configured to determine ideal operating conditions for a cooling asset or cooling asset infrastructure. The ideal operating conditions may be determined based on a combination of energy consumption, asset performance, environmental conditions, and availability of stored or renewable energy. Outputs of the first-stage models may be provided as inputs to additional first-stage models or to a second-stage optimization model.

[0108] Step 108 may include generating a cost or constraint signal by mapping the predicted operational metric to an objective function, a threshold, or a constraint parameter. In some embodiments, the predicted operational metric comprises a predicted energy consumption, a predicted operating cost, a predicted temperature deviation, or a predicted asset strain. In some embodiments, the predicted operational metric comprises a predicted temperature trajectory of the temperature-controlled environment. In some embodiments, the cost or constraint signal is generated using electricity pricing data that varies as a function of time.

[0109] In some embodiments, the system may respond to an electrical grid-strain condition through a multi-layered optimization framework that progresses from rules-based control to artificial-intelligence-based optimization. The grid-strain condition may be identified based on a grid-condition signal received from external data sources and may include events associated with energy markets, frequency markets, inertia markets, voltage markets, emergency markets, capacity or reserve markets, curtailment or load-shedding markets, congestion markets, or ancillary support markets. In some embodiments, the system evaluates the grid-condition signal to determine whether modification of operation of the cooling asset is associated with a financial penalty, financial incentive, or operational constraint, and adjusts control strategies accordingly.

[0110] Evaluating the grid-condition signal comprises identifying one or more grid events, extracting associated parameters from the grid-condition signal, determining one or more operational requirements or limits imposed by the grid event, and mapping the one or more operational requirements or limits to control actions for the cooling asset.

[0111] In some embodiments, the predicted operational metrics generated by the first-stage model architecture are mapped to one or more cost signals used as inputs to a second-stage optimization model. The one or more cost signals may be generated by multiplying predicted energy consumption by a time-varying electricity tariff to generate a real-time or forecasted operating cost. In some embodiments, the real-time or forecasted operating cost generated by the first-stage model architecture is provided as an input to a second-stage artificial intelligence decision-making model. The electricity tariff may include day rates, night rates, or other time-of-use pricing structures. In some embodiments, the cost signal enables the system to evaluate trade-offs between energy efficiency improvements and load shifting strategies. In some embodiments, the system may compare a value associated with reducing total energy consumption to a value associated with shifting energy consumption to lower-cost tariff periods, and may select control actions that optimize an overall objective function based on the relative magnitudes of such values. For example, at a pilot deployment site, a cooling asset may consume about 15,000 kilowatt-hours of electrical energy per month, with an applicable electricity tariff including a day rate of about 19.48 pence per kilowatt-hour and a night rate of about 16.13 pence per kilowatt-hour, corresponding to a tariff differential of about 3.35 pence per kilowatt-hour. In such embodiments, the cost signal may be calculated by multiplying a predicted power consumption value, expressed in kilowatts, by a current tariff rate, expressed in pence per kilowatt-hour, to generate a real-time cost signal expressed in pence per hour, which is provided as a key input to the second-stage model.

[0112] Step 110 may include determining, using an optimization model and the cost or constraint signal as an input, a candidate control action for the cooling asset that satisfies one or more operational constraints. In some embodiments, the one or more operational constraints comprise a temperature constraint requiring the temperature-controlled environment to remain within a predefined temperature range, and / or an equipment protection constraint limiting operation of the cooling asset based on a parameter selected from a duty cycle, a runtime duration, a cycling frequency, and an operating state of the cooling asset. In some embodiments, the optimization model evaluates the candidate control action by computing a score, value, or utility function based on the cost or constraint signal, and / or by optimizing an objective function subject to the one or more operational constraints. In some embodiments, the optimization model comprises a machine-learning or probabilistic decision model configured to select the control action based on an expected reward or penalty. In some embodiments, the machine-learning or probabilistic decision model comprises a reinforcement learning model, a Bayesian optimization model, a Bayesian inference model, a probabilistic graphical model, a supervised learning model, or a combination thereof.

[0113] In some embodiments, the optimization model comprises a reinforcement learning agent for learning optimal control policies across a plurality of control levers associated with the cooling asset. The reinforcement learning agent may balance multiple competing objectives, including energy efficiency, operating cost, temperature stability, equipment longevity, responsiveness to grid-condition signals, and a state of charge of thermal energy storage. In some embodiments, the reinforcement learning agent incorporates techniques from causal inference, (e.g., mediation analysis or surrogate modeling) to isolate and evaluate the causal impact of control interventions. In some embodiments, the system further implements a human-in-the-loop framework in which safety constraints, override conditions, or approval requirements are enforced prior to deployment of selected control actions.

[0114] In some embodiments, the system performs optimization across multiple competing objectives when selecting control actions for cooling assets. Primary objectives may include minimizing electricity cost and reducing total energy consumption, including by leveraging thermal mass within the environment. Secondary objectives may include preserving asset longevity, maintaining temperature compliance, and ensuring continuity of business operations. The optimization model balances the competing objectives based on learned trade-offs derived from operational data.

[0115] In some embodiments, the optimization model dynamically evaluates trade-offs between efficiency improvements and load shifting based on tariff rates. For example, the optimization model evaluates trade-offs by assigning an approximate value of eighteen pence to each kilowatt-hour saved through efficiency improvements based on a blended tariff rate, and an approximate value of 3.35 pence to each kilowatt-hour shifted from a higher-cost tariff period to a lower-cost tariff period based on the tariff differential. Based on these relative valuations, the optimization model may preferentially select control actions that reduce total energy consumption when the marginal value of efficiency improvements exceeds the marginal value of load shifting. In some embodiments, validation against pilot deployment data may demonstrate an approximate thirty-one percent reduction in total energy consumption, reflecting outcomes achieved when the optimization model prioritizes efficiency-driven energy reductions relative to load-shifting opportunities under the evaluated tariff differential.

[0116] In some embodiments, in response to a detected grid-strain condition or anticipated peak pricing periods, the system implements a pre-cooling strategy that leverages thermal energy storage within the temperature-controlled environment. The pre-cooling strategy may include operating the cooling asset at a lower temperature setpoint during off-peak periods to charge thermal energy storage, including phase change material, and allowing the temperature-controlled environment to coast at a higher temperature setpoint during peak periods. In some embodiments, the charging setpoint is selected to be below a phase-change temperature of the thermal energy storage, while the coasting setpoint is selected to be above the phase-change temperature. In some embodiments, the system further adjusts temperature setpoints and defrost scheduling based on weather conditions and grid-condition signals, including biasing defrost operations toward off-peak periods.

[0117] In some embodiments, the backend system comprises automated scripts for invoking a trained computational model based on the current state of the temperature-controlled environment and external contextual conditions. The computational model may be executed periodically or in response to detected events and may generate control recommendations or control commands for one or more cooling assets. In some embodiments, the backend system transmits control recommendations or control commands generated by the computational model to the edge computing device via a message broker or an application programming interface. The edge computing device may apply the control commands to the corresponding temperature controllers or make the control commands available for manual approval by an operator.

[0118] In some embodiments, the system uses orchestration logic for coordinating outputs of multiple first-stage models and the second-stage model. The orchestration logic may include rule-based safety backstops that override optimization outputs when operational constraints are violated and may support human-in-the-loop intervention for business or safety requirements. In some embodiments, strain pattern recognition is used to generate predictive maintenance alerts indicating emerging equipment degradation. In some embodiments, confidence-weighted ensemble techniques may be applied to combine predictions from multiple models based on estimated uncertainty

[0119] In some embodiments, the system may coordinate operation across a plurality of sites using federated learning techniques to enable portfolio-level optimization while preserving data locality. In some embodiments, the system may enable automated participation of thermal energy storage resources in a grid-related market selected from a capacity market, an energy market, and a demand response market.

[0120] In some embodiments, the optimization model generates outputs indicating whether a cooling asset should be activated, deactivated, or modulated, and specifies one or more control parameters including operating level, target temperature, fan speed, compressor staging, or defrost behavior. In some embodiments, the outputs are provided as recommendations to cooling operators to optimize energy usage and shift electricity demand while maintaining operational requirements of the environment.

[0121] In some embodiments, an optimization functionality is implemented using a single-stage model rather than a multi-stage architecture. The single-stage model may generate control recommendations directly from operational and contextual data without intermediate first-stage outputs. The single-stage model may provide recommendations to operators or automated control systems using the same communication pathways as the multi-stage architecture.

[0122] Step 112 may include transmitting, via a communication interface, the determined candidate control action to the cooling asset to update at least one operational parameter. In some embodiments, the at least one operational parameter comprises a temperature setpoint, a defrost schedule or an operating mode of the cooling asset.

[0123] In some embodiments, transmitting the determined candidate control action to the cooling asset comprises transmitting one or more control parameters from a remote backend system to an edge computing device associated with the cooling asset. In some embodiments, the remote backend system transmits control commands to the edge computing device using the same or a different communication protocol. The edge computing device may subscribe to one or more communication channels to receive control commands instructing the edge computing device to modify one or more operational parameters of the temperature controller, including temperature setpoints or operating modes. In some embodiments, the edge computing device executes one or more continuously running processes to listen for incoming control commands from the backend system and to write corresponding values to the temperature controller. In some embodiments, the edge computing device may execute one or more processes for publishing acknowledgements or status updates indicating that a control command has been received or executed.

[0124] In some embodiments, the system is configured to transmit control commands to the cooling asset through the BMS when direct control authority via the BMS is available. In other embodiments, when the system does not have direct control authority through the BMS, the system transmits control commands to an edge computing device connected to a programmable logic controller or temperature controller associated with the cooling asset.

[0125] In some embodiments, the system writes one or more control parameters to the cooling asset or associated controller as outputs of the optimization model. The control parameters may include a temperature setpoint, a defrost interval, a defrost cutoff temperature, a defrost cutoff time, or an instruction to initiate or inhibit a defrost cycle based on logic determined by the system. In some embodiments, the system writes temperature setpoints corresponding to different operating modes of the temperature-controlled environment. For example, a first temperature setpoint may be written to charge thermal energy storage or pre-cool the environment during off-peak periods, while a second temperature setpoint may be written to allow the environment to coast or discharge thermal energy storage during peak periods. In some embodiments, control parameters are written to the temperature controller according to a scheduled enforcement process. The scheduled enforcement process may be executed at regular intervals, including hourly intervals, and may apply different target setpoints during different time windows of a day. In some embodiments, the system publishes control commands to the BMS at regular intervals, when the system is authorized to directly control the cooling assets via the BMS. In some embodiments, the system publishes control commands to the BMS at intervals of about 0.5 to 3 hours. In some embodiments, the system publishes control commands to the BMS at intervals of about 1 hour.

[0126] In some embodiments, the edge computing device may comprise a locally stored schedule defining target operational parameters for different time periods. The schedule may be stored in a structured data file and may specify a target temperature setpoint or operating mode for each hour or other time interval. The edge computing device may execute a scheduled process at regular intervals to read the schedule and apply the corresponding operational parameter to the temperature controller.

[0127] In some embodiments, the system writes control parameters to a temperature controller using a serial communication protocol, including Modbus RTU. The control parameters may be written to specific registers associated with the temperature controller, including registers corresponding to temperature setpoints, economy mode offsets, and defrost timing parameters. In some embodiments, the system communicates with the temperature controller via an edge computing device executing a serial communication interface. The serial communication interface may be configured with predetermined communication parameters, wherein the predetermined communication parameters are selected from baud rate, parity, data bits, and stop bits.

[0128] In some embodiments, the system comprises a user interface configured to present recommendations, system status indicators, and performance metrics to operators. The user interface may display information including current and target temperature, predicted energy or cost savings, risk indicators associated with recommended actions, and confidence levels associated with recommendations. In some embodiments, operators may enable, disable, or approve automation through the user interface, enabling manual, semi-automatic, or fully automatic operation with override capability.

[0129] Step 114 may include monitoring the updated operation of the cooling asset to verify that the temperature-controlled environment remains within a predefined temperature range. In some embodiments, monitoring the operational data or the contextual data comprises comparing the operational data or the contextual data to the predicted operational metric and detecting a deviation when a difference exceeds a predefined threshold. In some embodiments, detecting the deviation from the predicted operational metric causes re-simulation, or updating of the computational model or the optimization model.

[0130] In some embodiments, the system triggers re-simulation of the digital twin when a significant deviation is detected between predicted and observed behavior. The trigger for re-simulation may include a temperature deviation exceeding a predefined threshold, detection of unexpected door events, changes in equipment operating state, unplanned defrost events, significant updates to weather forecasts, user overrides of automated control, or detection of a setpoint change communicated by a controller.

[0131] In some embodiments, an experimental validation is performed within the physical environment to validate predictions and hypotheses generated by the digital twin. The experimental validation may include selectively varying control parameters (e.g., temperature setpoints, defrost intervals, or defrost cutoff conditions) and observing resulting effects on temperature behavior or equipment efficiency. Experimental results may be used to refine model parameters and improve predictive accuracy.

[0132] In some embodiments, the system records historical outputs generated by the optimization model and whether corresponding recommendations were executed. The recorded decision and execution data may be evaluated against observed outcomes, including energy consumption or cost, relative to estimated outcomes absent intervention. The evaluation enables the optimization model to adapt its behavior to operator-specific objectives (e.g., minimizing total energy consumption or minimizing energy cost).

[0133] In some embodiments, the system generates explanatory information describing rationale behind recommendations and observed performance outcomes. The explanatory information may be presented in natural language or other interpretable formats to support operator understanding and trust. In some embodiments, the system provides higher-level insights identifying recurring inefficiencies, optimization opportunities, or emerging maintenance needs based on learned patterns across one or more deployment sites.

[0134] In some embodiments, the edge computing device performs local logging and buffers operational data from the temperature controller and sensors. During connectivity loss, buffered data is retained locally and automatically forwarded to the backend when connectivity is restored. In some embodiments, IoT sensors and their gateways or hubs likewise persist historical readings during outages and, upon reconnection, retransmit the stored data to the backend. In some embodiments, when connectivity between the edge computing device and the backend system is unavailable, the edge computing device continues to operate autonomously based on the most recently received schedule or control instructions. The edge computing device may apply a safe fallback operating parameter when communication failures are detected and may continue attempting to transmit operational data until connectivity is restored.

[0135] In some embodiments, the system implements fallback and reliability rules to ensure continued operation during data source failures. For example, if locally sourced sensor data is unavailable for a predetermined duration (e.g., about 30 min), the system may automatically fall back to using regional contextual data obtained from an external API. In some embodiments, if an external API is unavailable, the system may generate alerts for operators by utilizing historical contextual data stored in a local or cloud-based database to estimate likely environmental conditions based on time of day or historical patterns. In some embodiments, when network connectivity is unavailable, the system deploys a locally stored weather dataset to one or more edge computing devices. The locally stored weather dataset may be used as an input to physics-based simulation models or other computational models to enable continued operation in an offline or degraded connectivity mode.

[0136] In some embodiments, the system applies a hierarchical data selection strategy comprising a primary data source, a secondary data source, and a tertiary data source. The primary data source may include locally sourced sensor data obtained from controllers or IoT sensors. The secondary data source may include regional contextual data obtained via an external API. The tertiary data source may include a last known valid data state retained by the system for emergency fallback operation. In some embodiments, communication with a temperature controller is monitored for reliability. If a read operation fails, the system may retry the read operation a predetermined number of times with a predefined delay between attempts. If all retry attempts fail, the system may generate an error code and apply a sentinel value indicating a communication failure. In some embodiments, if a write operation to the temperature controller fails or a communication error is detected, the system may apply a safe fallback control action. The safe fallback control action may include writing a predefined fallback temperature setpoint to the controller. The fallback temperature setpoint may be clamped within allowable operational limits of the controller to prevent unsafe operation.

[0137] In some embodiments, the system performs validation of contextual data by cross-checking values obtained from multiple data sources. The validation may include detecting anomalies or inconsistencies between local sensor data and regional contextual data. In some embodiments, the system selects data from a preferred source based on the data priority logic rather than blending values from multiple sources. In some embodiments, the system generates alerts in response to detected errors, data source failures, or fallback events. The alerts may be transmitted to operators via an automated notification system, including webhooks or messaging integrations. The alerts may include informational alerts indicating successful operations and error alerts indicating exceptions or failures requiring attention.

[0138] Step 116 may include iteratively repeating steps 102 through 114 to dynamically adjust operation of the cooling asset in response to changes in the operational data and / or the contextual data while maintaining the temperature-controlled environment within the predefined temperature range. In some embodiments, iteratively repeating steps 102 through 114 comprises updating the control action in response to a detected change in electricity pricing data or electrical grid-condition data.

[0139] In some embodiments, the system applies stability constraints when iteratively updating control actions to prevent oscillatory or excessive control adjustments. The stability constraints may include hysteresis thresholds, minimum dwell times between control updates, rate-of-change limits on temperature setpoints, or confidence thresholds associated with predicted operational metrics. The stability constraints ensure that iterative control actions converge toward a stable operating regime while maintaining temperature compliance and asset protection.

[0140] FIG. 2 illustrates an exemplary method 200 for generating, calibrating, and operating one or more computational models for optimizing operation of a cooling asset within a temperature-controlled environment, according to one or more embodiments of the present disclosure. The steps of method 200 presented below are intended to be illustrative, and the steps of exemplary method 200 (e.g., steps 204 and 208) may be performed automatically or in response to a request from a user. Additionally, the order in which the steps of method 200 are illustrated and described below is not intended to be limiting.

[0141] In some embodiments, method 200 may be implemented in one or more processing devices, including one or more digital processors, analog processors, digital circuits, analog circuits, state machines, edge computing devices, cloud-based computing systems, and / or other mechanisms for electronically processing information. The one or more processing devices may execute some or all of the steps of method 200 in response to instructions stored electronically on one or more non-transitory electronic storage media. In some implementations, one or more operations of method 200 are performed in parallel, asynchronously, or in a distributed computing environment.

[0142] Data sources 202 may include sensor data, controller data, asset runtime data, weather data, electricity pricing data, grid-condition data, or combinations thereof. In some embodiments, the operational data and / or contextual data is organized into one or more datasets for model training, validation, and testing, and duplicate or anomalous data points may be filtered or excluded.

[0143] In step 204, data from the data sources 202 may be input to single-stage models 206. Single-stage models 206 may include weather and renewable performance regression models, chiller efficiency regression models, business operations and electricity use regression models, person and object detection computer vision models, physics-based temperature-flow models, and any other suitable model.

[0144] In step 208, the method 200 may include outputting a recommended action to one or more actuators 210 of the system. The one or more actuators 210 may include building management systems, internet-connected relays, battery management systems, email, SMS, or push notifications, internet-connected robotic switches, and / or other actuators.

[0145] FIG. 3 illustrates an exemplary method 300 for dynamically controlling operation of a cooling asset using one or more computational models and optimization techniques, according to one or more embodiments of the present disclosure. The steps of method 300 presented below are intended to be illustrative, and the steps of exemplary method 300 (e.g., steps 304, 308, 312, and 316) may be performed automatically or in response to a request from a user. Additionally, the order in which the operations of method 300 are illustrated and described below is not intended to be limiting.

[0146] In some implementations, method 300 may be implemented in one or more processing devices, including edge computing devices, cloud-based computing systems, or combinations thereof. The one or more processing devices may be configured through hardware, firmware, and / or software to execute some or all of the operations of method 300. In some implementations, one or more operations of method 300 are performed continuously, periodically, or in response to detected events.

[0147] Data sources 302 may include sensor data, controller data, asset runtime data, weather data, electricity pricing data, grid-condition data, or combinations thereof. In some embodiments, the operational data and / or contextual data is organized into one or more datasets for model training, validation, and testing, and duplicate or anomalous data points may be filtered or excluded. Data is collected by the system through multiple sources, including, but not limited to, Application Program Interfaces (APIs), hardwired sensors, internet-connected (IoT) sensors, edge computers on site, cloud software and databases on and off-site, Building Management Systems, Battery Management Systems, internal operational reports, and directly from HVAC and Refrigeration assets.

[0148] In step 304, data from the data sources 302 may be input to first-stage models 306. Alternatively, in step 316, data from the data sources 302 may be input directed to second-stage AI models 310. First-stage models 306 may include weather and renewable performance regression models, chiller efficiency regression models, business operations and electricity use regression models, person and object detection computer vision models, physics-based temperature-flow models, and any other suitable model.

[0149] In step 308, the output from the first-stage models 306 may be input to one or more second-stage AI models 310. The second-stage AI models may include, but are not limited to, a decision tree, an artificial neural network (ANN), a recursive neural network (RNN), a K-nearest neighbors model, a machine learning model, or any other suitable AI model.

[0150] In step 312, a recommendation output from the second-stage AI model is sent to one or more actuators 314. The one or more actuators 314 may include building management systems, internet-connected relays, battery management systems, email, SMS, or push notifications, internet-connected robotic switches, and / or other actuators.

[0151] According to the present disclosure, by leveraging diverse data streams, computational models, and artificial intelligence, the system reduces electricity consumption and electricity demand associated with cooling assets without negatively impacting business operations. The optimization may be enhanced through coordination with renewable energy sources or energy storage systems, enabling further reductions in grid demand.

[0152] In an alternative embodiment, the system comprises one or more computing nodes operating within a trusted computing environment to support coordinated control and monitoring of cooling assets. Each computing node includes a computer-readable storage medium storing program instructions executable by a processor to perform operations comprising: receiving operational data, predicted operational metrics, or control-action requests from another computing node, edge device, or controller; verifying authorization of the request based on stored credentials associated with a device, system component, or operator account; determining consistency of a current operational state of the temperature-controlled environment by comparing locally stored state information with state information received from at least one other computing node; validating a requested control action based on the determined operational state and one or more operational constraints; and recording execution or rejection of the control action in a system log or state record. In some embodiments, the validation and coordination of control actions are performed to ensure safe, ordered, and consistent operation of cooling assets across distributed edge and cloud computing resources.

[0153] Referring now to FIG. 4, a schematic of an example of a computing node is shown. Computing node 410 is only one example of a suitable computing node and is not intended to suggest any limitation as to the scope of use or functionality of embodiments described herein. Regardless, computing node 410 is capable of implementing and / or performing any of the functionalities set forth hereinabove.

[0154] In computing node 410 there is a computer system / server 412, which is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with computer system / server 412 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices, and the like.

[0155] Computer system / server 412 may be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. Computer system / server 412 may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.

[0156] As shown in FIG. 4, computer system / server 412 in computing node 410 is shown in the form of a general-purpose computing device. The components of computer system / server 412 may include, but are not limited to, one or more processors or processing units 416, a system memory 428, and a bus 418 that couples various system components including system memory 428 to processor 416.

[0157] Bus 418 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, Peripheral Component Interconnect (PCI) bus, Peripheral Component Interconnect Express (PCIe), and Advanced Microcontroller Bus Architecture (AMBA).

[0158] Computer system / server 412 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by computer system / server 412, and it includes both volatile and non-volatile media, removable and non-removable media.

[0159] System memory 428 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 430 and / or cache memory 432. Computer system / server 412 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 434 can be provided for reading from and writing to a non-removable, non-volatile magnetic media (not shown and typically called a “hard drive”). Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a “floppy disk”), and an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media can be provided. In such instances, each can be connected to bus 418 by one or more data media interfaces. As will be further depicted and described below, memory 428 may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the disclosure.

[0160] Program / utility 440, having a set (at least one) of program modules 442, may be stored in memory 428 by way of example, and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. Program modules 442 generally carry out the functions and / or methodologies of embodiments as described herein.

[0161] Computer system / server 412 may also communicate with one or more external devices 414 such as a keyboard, a pointing device, a display 424, etc. ; one or more devices that enable a user to interact with computer system / server 412; and / or any devices (e.g., network card, modem, etc.) that enable computer system / server 412 to communicate with one or more other computing devices. Such communication can occur via Input / Output (I / O) interfaces 422. Still yet, computer system / server 412 can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet) via network adapter 420. As depicted, network adapter 420 communicates with the other components of computer system / server 412 via bus 418. It should be understood that although not shown, other hardware and / or software components could be used in conjunction with computer system / server 412. Examples, include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

[0162] The present disclosure may be embodied as a system, a method, and / or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present disclosure.

[0163] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0164] Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0165] Computer readable program instructions for carrying out operations of the present disclosure may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

[0166] Aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0167] These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0168] The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0169] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0170] The descriptions of the various embodiments of the present disclosure have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A computer-implemented method for dynamically monitoring operation of a cooling asset, the method comprising:(a) reading operational data and / or contextual data from a plurality of heterogeneous data sources;(b) generating a unified time-series dataset representing a current state of a temperature-controlled environment and the cooling asset;(c) applying a computational model to generate a predicted operational metric based on the unified time-series dataset;(d) generating a cost or constraint signal by mapping the predicted operational metric to an objective function, a threshold, or a constraint parameter;(e) determining, using an optimization model and the cost or constraint signal as an input, a candidate control action for the cooling asset that satisfies one or more operational constraints;(f) transmitting, via a communication interface, the determined candidate control action to the cooling asset to update at least one operational parameter;(g) monitoring the updated operation of the cooling asset to verify that the temperature-controlled environment remains within a predefined temperature range; and(h) iteratively repeating steps (b) through (g) to dynamically adjust operation of the cooling asset in response to changes in the operational data and / or the contextual data while maintaining the temperature-controlled environment within the predefined temperature range.

2. The method of claim 1, wherein the plurality of heterogeneous data sources comprises:a sensor physically deployed within a temperature-controlled environment for measuring temperature at a spatial location;a controller associated with the cooling asset and, one or more sensors or monitoring devices configured to provide operational data of the cooling asset; oran external data source providing contextual data comprising one or more weather data, electricity pricing data, or electrical grid-condition data.

3. The method of claim 1, wherein generating the unified time-series dataset comprises temporally synchronizing the operational data and the contextual data by assigning timestamps and aligning the operational data and the contextual data to a common time reference.

4. The method of claim 1, wherein the computational model comprises:a physics-based simulation model representing thermal behavior of the temperature-controlled environment;a machine-learning time-series forecasting model trained on historical operational data;a regression model relating environmental conditions and asset operation to energy consumption, or a combination thereof.

5. The method of claim 1, wherein the predicted operational metric comprises a predicted energy consumption, a predicted operating cost, a predicted temperature deviation, or a predicted asset strain.

6. The method of claim 1, wherein the computational model generates a digital twin of the temperature-controlled environment, the digital twin simulating thermal behavior of the temperature-controlled environment based on the operational data and the contextual data.

7. The method of claim 1, wherein the computational model generates the predicted operational metric over a future time horizon.

8. The method of claim 1, wherein the unified time-series dataset comprises time-aligned operational data and contextual data sampled at different polling intervals.

9. The method of claim 1, wherein the predicted operational metric comprises a predicted temperature trajectory of the temperature-controlled environment.

10. The method of claim 1, wherein the cost or constraint signal is generated using electricity pricing data that varies as a function of time.

11. The method of claim 1, wherein the one or more operational constraints comprise a temperature constraint requiring the temperature-controlled environment to remain within a predefined temperature range, and / or an equipment protection constraint limiting operation of the cooling asset based on a parameter selected from a duty cycle, a runtime duration, a cycling frequency, and an operating state of the cooling asset.

12. The method of claim 1, wherein the optimization model evaluates the candidate control action by computing a score, value, or utility function based on the cost or constraint signal, and / or by optimizing an objective function subject to the one or more operational constraints.

13. The method of claim 1, wherein the optimization model comprises a machine-learning or probabilistic decision model configured to select the control action based on an expected reward or penalty.

14. The method of claim 1, wherein the at least one operational parameter comprises a temperature setpoint, a defrost schedule or an operating mode of the cooling asset.

15. The method of claim 1, wherein monitoring the operational data or the contextual data comprises comparing the operational data or the contextual data to the predicted operational metric and detecting a deviation when a difference exceeds a predefined threshold.

16. The method of claim 15, wherein detecting the deviation from the predicted operational metric causes re-simulation, or updating of the computational model or the optimization model.

17. The method of claim 1, wherein iteratively repeating steps (b) through (g) comprises updating the control action in response to a detected change in electricity pricing data or electrical grid-condition data.

18. The method of claim 1, wherein the control action modifies physical operation of the cooling asset by causing a change in electrical power consumption of the cooling asset.

19. A system comprising:a computing node comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor of the computing node to cause the processor to perform a method comprising:(a) reading operational data and / or contextual data from a plurality of heterogeneous data sources;(b) generating a unified time-series dataset representing a current state of a temperature-controlled environment and the cooling asset;(c) applying a computational model to generate a predicted operational metric based on the unified time-series dataset;(d) generating a cost or constraint signal by mapping the predicted operational metric to an objective function, a threshold, or a constraint parameter;(e) determining, using an optimization model and the cost or constraint signal as an input, a candidate control action for the cooling asset that satisfies one or more operational constraints;(f) transmitting, via a communication interface, the determined candidate control action to the cooling asset to update at least one operational parameter;(g) monitoring the updated operation of the cooling asset to verify that the temperature-controlled environment remains within a predefined temperature range; and(h) iteratively repeating steps (b) through (g) to dynamically adjust operation of the cooling asset in response to changes in the operational data and / or the contextual data while maintaining the temperature-controlled environment within the predefined temperature range.

20. A computer program product, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions being executable by a processor to cause the processor to perform a method comprising:(a) reading operational data and / or contextual data from a plurality of heterogeneous data sources;(b) generating a unified time-series dataset representing a current state of a temperature-controlled environment and the cooling asset;(c) applying a computational model to generate a predicted operational metric based on the unified time-series dataset;(d) generating a cost or constraint signal by mapping the predicted operational metric to an objective function, a threshold, or a constraint parameter;(e) determining, using an optimization model and the cost or constraint signal as an input, a candidate control action for the cooling asset that satisfies one or more operational constraints;(f) transmitting, via a communication interface, the determined candidate control action to the cooling asset to update at least one operational parameter;(g) monitoring the updated operation of the cooling asset to verify that the temperature-controlled environment remains within a predefined temperature range; and(h) iteratively repeating steps (b) through (g) to dynamically adjust operation of the cooling asset in response to changes in the operational data and / or the contextual data while maintaining the temperature-controlled environment within the predefined temperature range.

Images