Integrated HVAC Controls: What to Specify When Chillers, Heat Pumps, AHUs, and VRF Must Work Together

The short answer: specify the control contract, not just the interface

Before asking for “BMS integration,” define five deliverables:

1. Equipment boundary: which controller, panel, gateway, sensor, actuator, and field wire belong to each party.
2. Information boundary: every status, command, measurement, alarm, unit, normal state, and trend requirement.
3. Sequence boundary: how equipment starts, stages, resets, hands over, and shuts down under normal and abnormal conditions.
4. Authority boundary: which device may write a setpoint or mode, and what happens when commands conflict.
5. Evidence boundary: the drawings, backup files, point-to-point records, trend plots, and functional tests required at handover.

SongXin’s integrated system controls page describes a product category that connects chillers, heat pumps, AHUs, FCUs, VRF systems, pumps, ventilation units, sensors, valves, dampers, and building-automation platforms. It also lists communication modules such as BACnet, Modbus, KNX, and LonWorks. Those statements identify possible solution components; they do not prove that a specific chiller, VRF gateway, controller, or software version supports every requested point or command. Put the model-specific interface and responsibility in the RFQ.

1. Draw the system boundary before listing points

Start with a one-line diagram and a responsibility matrix. For every item, show the equipment controller, supervisory controller, field devices, network path, power source, and person responsible for the final test.

REFERENCE TABLE · On small screens, scroll horizontally to read all columns.

This separation is especially important when a project combines central chilled water with VRF zoning or uses a heat pump for domestic hot water. The systems may share a schedule or a supervisory dashboard without sharing a water loop, refrigerant circuit, safety chain, or operating mode.

2. Build a usable points list

A points list is a control contract, not a list of tag names. For every point, include:

• equipment and physical location;
• point type: analog input/output, digital input/output, calculated value, command, or status;
• engineering unit and normal range;
• source device and network address or terminal reference;
• read-only or writable status;
• default, fail, and manual values;
• alarm priority, delay, latching and acknowledgement behavior;
• trend requirement, sample interval and retention responsibility;
• owner of the point and the test that proves it works.

Use descriptive names that survive a change of software platform. “CH-01 LWT” is useful only if the schedule defines whether it means leaving-water temperature at the chiller, common header, or process connection. Add the physical location and the reference drawing.

Example points that need more than a tag

REFERENCE TABLE · On small screens, scroll horizontally to read all columns.

Do not fill missing information with a guessed data type or a generic gateway map. Mark the point as to be confirmed and make the proposed supplier identify the model, firmware, gateway, licensing, and test method that close the gap.

One point shown as a worked schedule entry

The following is an illustrative points-list row. The project must replace the placeholders with the selected equipment’s actual sensor, limits and test method.

REFERENCE TABLE · On small screens, scroll horizontally to read all columns.

This is a measurement at one chiller’s inlet, not a substitute for a common-header sensor. Complete the entry with the sensor model, network object/register, alarm limits and delay, trend interval, stale-data timeout, test tolerance and responsible tester. None of those project values is established by this example. The points schedule is not ready for acceptance while those fields are unresolved.

3. Write the sequence of operations as a decision path

The sequence should explain what the system does, what condition triggers it, and how completion is proved. A useful sequence normally covers:

Enable and start

Define the schedule, occupancy or process request that enables the system. State the order of operations: for example, open a required valve, command the pump, prove flow, and then release a chiller or heat-pump enable. Identify the timeout and alarm if proof does not arrive.

Staging and lead/lag

State how equipment is added or removed as demand changes, how the lead unit rotates, and what happens after a fault. Use the selected equipment’s minimum operating capacity and manufacturer’s staging constraints rather than an arbitrary percentage. If a standby module starts only after the lead unit reaches a limit, identify the measured value and delay that initiate the change.

Setpoint reset

Define which measured demand resets a plant or air-side setpoint, the permitted range, the rate of change, and the local limit that cannot be exceeded. A BMS reset should not silently conflict with a local unit controller or a process requirement.

Mode changes and shutdown

Cover occupied, unoccupied, warm-up, seasonal, maintenance, emergency, manual, and communications-loss modes where they apply. State the order in which fans, valves, pumps, compressors, and heat sources stop. Include minimum run times, post-run periods, freeze protection, and the return to automatic control.

Coordination without false coupling

Coordinate systems where the building demand requires it, but do not create a control dependency that the mechanical design does not support. For example, a VRF gateway may provide a demand or status to a supervisory controller while the VRF manufacturer retains refrigerant protection and indoor-unit logic. A heat-pump DHW system may report storage demand to the BMS while its internal high-pressure, defrost, and water-side protection remain local.

4. Decide priority and write authority before commissioning

Conflicting commands are one of the fastest ways to make an integrated system unreliable. Create a write-authority matrix with at least these architectural layers:

1. Life-safety and equipment protection: assign fire/smoke and emergency actions to the approved safety architecture and preserve manufacturer limits. Do not rely on an ordinary BMS network or gateway as the sole path for a required safety action. An approved networked life-safety system is a separate design question.
2. Local automatic control: the equipment controller operates within its approved limits.
3. Plant or system controller: coordinates equipment that was designed to work together.
4. BMS supervisory logic: schedules, requests, resets and records operation within the approved sequence.
5. Operator commands: temporary overrides with a named expiry, visible status and an audit trail.

These are responsibility layers, not a universal priority ranking. An approved operator override may take precedence over a schedule without defeating local protection. For every writable point, record the actual device or gateway command level, release/default behavior, conflict handling and offline fallback. Identify the active command at the user interface. Do not assume that every interface exposes BACnet command priorities or equivalent semantics.

5. Design failure and degraded modes

An integrated control system should remain understandable when something is missing. Specify the response to:

• BMS or gateway communication loss;
• a failed, implausible, or out-of-range temperature, pressure, airflow, or occupancy sensor;
• a pump command with no run proof;
• a valve command with no position feedback;
• loss of normal power and power recovery;
• a local hand/off/auto change;
• a fire, smoke, emergency-stop, or other external safety signal;
• a lead unit fault or an unavailable standby unit.

For each case, name the fallback: hold last safe state, switch to local automatic mode, disable a dependent device, start an approved standby path, or generate an alarm that requires a person. Do not promise that “the system will continue normally” without defining what remains controlled locally and what is no longer available.

6. Specify alarms, trends, and evidence—not just dashboards

An alarm is useful only if it tells an operator what changed and what action is expected. Each important alarm should have a clear text, priority, delay, latching rule, acknowledgement behavior, source point, and escalation path. Avoid making every status change a high-priority alarm.

Trend the values needed to diagnose the sequence: demand, enable, run proof, temperatures, pressures, flow or speed feedback, valve position, mode, alarms, and the active setpoint. Record timestamps and units. Use a trend window long enough to show start-up, steady operation, a mode change, and shutdown; the project team should define the interval and retention required for its risk and operating decisions.

The SongXin building automation page describes centralized monitoring, schedules, alarms and historical trend data as BAS/BMS functions. Treat those as requested solution functions, then verify which points, history length, user roles, licenses and exports the offered system actually includes.

7. Treat protocol and cybersecurity as project scope

If the RFQ names BACnet, Modbus, KNX, LonWorks, or another interface, also name:

• the exact device, gateway, firmware and supported objects or registers;
• who supplies the gateway, license, network switch, power and field wiring;
• network ownership, addressing, time synchronization and backup;
• user accounts, role permissions, credential handover and remote-access approval;
• segmentation or firewall requirements set by the owner’s IT policy;
• what happens to local control if the supervisory network is unavailable.

A protocol label indicates a possible communication method. It does not establish point availability, read/write behavior, alarm quality, timing, or a tested sequence. Require a sample point map and a demonstration on the selected equipment or an explicitly approved simulation before closing the interface risk.

Ask different interface questions for different paths

REFERENCE TABLE · On small screens, scroll horizontally to read all columns.

Use the BACnet International reference site for protocol terminology, but treat the selected device and gateway documentation as the evidence for the actual project interface. Its FAQ makes the procurement point directly: a specification that only says “shall be BACnet” does not define the required interactions; the points, schedules, alarms, events and cross-device functions still need to be listed. The same FAQ notes that gateways add configuration, commissioning, maintenance and cost considerations. Those statements support a detailed interface schedule, not a guarantee about any offered model.

This section defines RFQ questions; it does not certify the offered system against a cybersecurity standard. Network segmentation, credentials, remote access, backups and incident ownership still belong in the owner’s approved IT and controls architecture.

Illustrative coordination example: hotel plant with four control domains

Assume a hotel has an air-cooled chiller for a chilled-water AHU, VRF units for smaller zones, and a separate high-temperature heat pump for domestic hot water. The example is a control-design exercise, not a claim about a specific model.

1. The occupancy schedule requests comfort operation. The BMS releases the AHU and the approved VRF schedule, while each equipment controller retains its local safeties.
2. The AHU controller requests chilled water when its supply-air or zone demand requires it. The plant controller proves the pump and flow before enabling the chiller.
3. The plant controller stages the available chiller modules according to the selected sequence and reports actual leaving-water temperature, run proof and alarms.
4. The VRF gateway reports zone demand and alarms. The BMS supervises schedule and approved modes but does not assume it can write every indoor-unit function.
5. The DHW heat pump follows storage demand and its project-approved recovery sequence. If it becomes unavailable, the BMS raises the defined backup request; it does not invent a backup capacity that the mechanical design has not provided.
6. If the BMS network fails, the chiller, AHU, VRF and DHW controllers follow their specified local fallback. The loss is alarmed, and the handover test demonstrates the resulting states.

This example shows why “one screen for all HVAC” is not the same as “one controller owns all HVAC.” The mechanical interfaces, local controls, gateways, and fallback states must be designed together.

Integrated HVAC controls RFQ checklist

Ask each bidder to return the following with the quotation:

REFERENCE TABLE · On small screens, scroll horizontally to read all columns.

Commissioning acceptance checklist

Before accepting an integrated controls package, verify that:

• Every field point has been traced from the drawing to the controller and the BMS screen.
• Commands produce the intended equipment response, and feedback proves the response.
• Local hand/off/auto and safety interlocks behave as documented.
• Staging, lead/lag, setpoint reset and mode changes have been tested with realistic conditions.
• Communication-loss and sensor-failure fallbacks have been demonstrated.
• Alarm text, priority, delay, acknowledgement and escalation match the approved matrix.
• Trends show start-up, stable operation, a load change and shutdown with units and timestamps.
• User roles, backups, network information and source files have been handed over.

Example acceptance evidence to put in the contract

REFERENCE TABLE · On small screens, scroll horizontally to read all columns.

The exact acceptance criteria belong to the contract and safety architecture. These examples show the type of evidence needed; they are not a universal commissioning standard.

Further reading

• Integrated System Controls
• HVAC Controls
• Smart Control Solutions
• Building Automation Systems