Central plants contain multiple chiller, boiler, and auxiliary equipment. Each piece of equipment operates on different efficiency curves that vary with part load, ambient conditions, and other operating parameters. In addition, the site receives real-time price signals for electricity, and operators must consider fluctuating fuel prices and other costs. The system-level, dynamic optimization of central plants and distribution system implemented in this project has the potential to save energy and cost. The objective of the project was to assess the energy and economic benefits of the real-time optimization technology that commands all equipment in a central plant. The performance objectives were: (1) correct optimizer performance in simulation (objective met), (2) optimizer software interconnection with plant control system (objective met), (3) 10% energy savings (objective not met), (4) preserving comfort conditions in buildings (objective met), (5) economic performance (objective not met), (6) low short cycling of equipment (objective met), and (7) effective user interface (UI) (qualitative) (objective partially met).
The deployed technology is a model-predictive, run-time optimization technology used to operate the generation, storage, and distribution of cooling and heating energy while maintaining building comfort. Based on the inputs of upcoming loads, price signals, central plant performance models, and building response, a mixed-integer evolutionary optimizer algorithm solves the schedules and setpoints for the major and auxiliary equipment in the central plant. The central plant model is configured from a library containing models of chillers, boilers, cooling towers, pumps, and thermal storage system. A dynamic building model mathematically represents the changes in comfort conditions in the building in response to changes in energy supplied with the distributed chilled or hot water. The models are set up based on historical data and updated as new data become available. The optimal control commands are communicated to lower level controllers that operate the equipment in the central plant. Feedback from the buildings provides corrections to the long-term forecast load; this feedback is used to adjust supplied energy.
The demonstration was designed to collect data about the original control and the optimized control, alternately. A software switch incorporated in the optimizer enabled the optimizer to run the plant or switch to the original control operation to ensure similar occupancy and functions for the buildings served by the central plant. Operational electricity and gas consumption data from all equipment were collected in the optimizer’s database for analysis.
A simulation system and models of the central plants and loads to test the optimizer software in simulation. The simulation software was connected with the optimizer software using OPC server protocol. We ran several simulations with the setup to test and fix optimizer software bugs and validate its performance before deploying on site.
The optimization solution was integrated with the chiller plant control system. A systematic and thorough testing and commissioning process was followed to bring the optimizer online. Observations and later analysis showed that the optimizer’s outputs were appropriate, as is expected for energy use minimizing actions.
After training the operators, site resource manager, and other site personnel, and providing the appropriate user manuals, the optimizer was handed over to site staff. Honeywell Laboratories in Minneapolis, MN, continued providing remote phone and onsite support for running the plant under optimizer control. The optimizer software was available and connected at the chiller plant from April 2015, to May 2016, and was enabled to operate the plant for some periods during that time. Data from the chiller plant is available for July 2015—May 2016. After removing invalid and shorter duration data, the data analysis shows the optimizer operated onsite for 39 days (24-hour [hr] periods) in several continuous periods. During the same period, the data shows 164 periods of original control days.
A rigorous baseline characterization methodology was developed to compare the actual energy consumption during optimization with the expected energy consumption under original control operation. Using all the data available, it was found that the optimized control of the plant did not reduce the energy consumption in the plant, and in most cases it is within one standard deviation error of the expected usage with original control. This unexpected result led to further analysis to diagnose the problems. The analysis showed a number of discrepancies in the input data to the optimizer software, which are explained in detail in the performance assessment section.
The optimizer works on real-time-sensed data to know the state of the plant, forecast loads, and calculate optimal operating commands. Poor quality or incorrect sensed data will not result in optimal outputs. The analysis of the data showed that there were no adverse effects to comfort conditions in buildings. The analysis also showed that equipment short-cycling, although more frequent than in original control, was still within guidelines provided by the site and able to be adjusted with user provided parameters. The effectiveness of the UI and the optimizer software architecture had mixed results.
Running the optimizer during the demonstration period depended on the chiller plant equipment being in good operating condition (e.g., not experiencing maintenance issues forcing manual operation) and the availability of site staff to monitor the operation periodically since optimizer-controlled operation is a large departure from current practice. Several troubleshooting periods took place in which the software was updated to manage site expectations and the difficult transition from Research and Development (R&D) to production prototype.
Failure to achieve energy and cost savings during the demonstration period stemmed from the following causes:
- incorrect inputs to the optimizer that were caused by communication disruptions or incorrect configuration changes;
- the complexity and prototype nature of the software required monitoring and support from skilled application engineers, but U.S. Department of Defense (DoD) site restrictions prevented remote access to the workstation;
- data-driven plant equipment models were potentially not well learned due to varied problems experienced by the optimizer preventing it from operating stably for longer periods with all equipment components;
- the transition of complex software from R&D to production prototype required the team to develop additional software tools and training of staff;
- the software’s architecture and the implementation scheme to control the full plant from the supervisory layer caused two problems:
- potential network communication problems required development of additional optimizer software safety measures to prevent unsafe operation, and
- site staff were uncomfortable with a supervisory-level algorithm controlling lower level components in real time.
The results and lessons learned are planned to be published as part of a book (on intelligent control systems) as well as in a white paper.