Chiller monitoring

Reading a legacy HMI without changing the chiller hardware.

I mapped HMI readings, built the acquisition path, and integrated the team's classifier with the monitoring workflow.

Research Project Assistant

Universitas Padjadjaran × GMF AeroAsia

Aug 2023 to Jan 2024

Completed Jan 2024

System overview

Input: Eleven operating parameters from a Pro-face HMI
Processing: Raspberry Pi acquisition, cloud storage and XGBoost condition classification
Output: Remote readings and history with normal or potential-failure labels

Teammates developed the dashboard and machine-learning approach.

Equipment and remote view

The Pro-face HMI already exposed operating data through a web page. Reusing that interface over local Ethernet let the monitoring application read existing values while leaving the chiller hardware unchanged.

Water-cooled chiller in the plant room with existing pipework and control cabinets. — Existing equipment and controls used as the source for remote monitoring.

Team-built dashboard showing chiller parameters, gauges and history controls with demonstration data. — The remote view includes reading and history controls. Values are demonstration data.

Trace the acquisition and application path

I mapped HMI addresses by changing values in the manufacturer’s simulator and observing the matching entries in its data table. The Raspberry Pi then requested HMI pages over Ethernet, parsed the eleven parameters and sent timestamped readings to the application endpoint.

Diagram connecting the chiller and Pro-face HMI to Raspberry Pi acquisition, cloud storage, a classifier service and the dashboard. — The design connects local acquisition, storage, classification and the team-built dashboard.

Layer	System behavior and my contribution
HMI discovery	I changed simulator values and mapped the corresponding entries in the data table.
Edge acquisition	The Raspberry Pi requested HMI pages, parsed mapped fields and added timestamps. I configured the device and built the acquisition path.
Application integration	Readings went to the web team’s endpoint and PostgreSQL/AWS storage path. I connected acquisition, storage and classifier output.
Condition classification	The team’s XGBoost model labels normal and potential-failure conditions. I integrated it with the monitoring workflow.

Compare readings at the site

During on-site implementation, we compared readings shown in the website with values at the chiller.

Project team working beside a water-cooled chiller during on-site implementation. — Working beside the chiller during the on-site implementation.

Project team gathered around laptops in a lab workspace. — Team members working together around laptops in the project lab.

Project team reviewing a development workstation in a lab. — Team members gathered around a shared workstation during project work.

Review the classifier evaluation

The matrix shows class-specific errors alongside correct classifications. The evaluation dataset and split are unspecified, so these counts are not a field-performance benchmark.

Confusion matrix with 385 correctly classified normal examples, 15 false alarms, 15 missed potential failures and 85 detected potential failures. — Classifier evaluation over 500 examples.

XGBoost feature-importance chart ranking condenser pressure and other chiller inputs. — The model ranking does not establish physical causes of failure.

Check	Result
Evaluation examples	500
Correct classifications	470 of 500 (94%)
Potential-failure recall	85 of 100 (15 missed)
On-site reading comparison	Website values compared with machine readings