For an AHU manufacturer, designing the air-handling unit is only part of the job.
When an AHU is delivered as part of a building automation project, the manufacturer often has to deal with a much more complicated requirement: different consultants, system integrators, BAS platforms and end users may require different communication protocols, I/O configurations and integration methods.
One project may require BACnet/IP integration with the building automation system.
Another may require Modbus RTU meters and sensors.
A third project may ask for MQTT connectivity to a cloud platform.
Some projects may also require OPC UA access for an energy management or digitalization platform.
At the same time, the number and type of field signals can vary significantly from one AHU project to another.
This creates a practical problem for AHU manufacturers:
How can the same AHU control architecture remain standardized while still being flexible enough for different projects?
This is where an edge I/O architecture such as the BA190Pro Building HVAC Edge I/O Controller can provide a practical solution.
A typical AHU may need to connect to:
The actual I/O requirements can change depending on the AHU design and project specification.
For example, one AHU may primarily require 0–10 V analog signals, while another project may require 4–20 mA signals, PT100 temperature sensors, relay outputs or additional digital inputs.
Using a fixed I/O configuration for every AHU can result in unused channels in some projects and insufficient channels in others.
The BA190Pro addresses this issue through a modular I/O structure.
It provides 1 to 3 I/O expansion slots, allowing different I/O modules to be combined according to project requirements. Available options include digital input/output, relay, analog input/output, RTD, thermocouple and serial communication modules. This allows an AHU manufacturer to build a common controller platform while changing only the required I/O combination for different AHU models or projects.
For a standard AHU, the manufacturer may configure:
BA190Pro + AI + AO + DI/DO
For a more instrumentation-heavy AHU:
BA190Pro + AI + RTD + DI/DO
For an AHU that needs additional field-device communication:
BA190Pro + AI + Serial Communication
The core controller remains the same.
Only the I/O configuration changes.
This can help AHU manufacturers standardize their control panel design while maintaining project flexibility.
This is one of the most common integration problems.
Many field devices inside an AHU system communicate using Modbus RTU through RS485.
Examples include:
However, the building automation system may require BACnet/IP.
Without an appropriate integration layer, the AHU manufacturer or system integrator may need an additional protocol gateway.
This introduces additional hardware, configuration and commissioning work.
The BA190Pro provides an isolated RS485 interface supporting Modbus RTU master/slave operation, while its Ethernet interfaces support BACnet/IP, Modbus TCP, MQTT and OPC UA. This means the controller can act as a protocol and data integration layer between field devices and higher-level systems.
For example:
Modbus RTU Field Devices → BA190Pro → BACnet/IP → BAS
Instead of designing the AHU panel around multiple independent communication gateways, the BA190Pro can consolidate the data path at the edge.
An AHU manufacturer may deliver the same basic equipment to different customers.
However, the customer's software architecture may be completely different.
One customer may use a traditional BAS based on BACnet.
Another may want to send operating data to an IoT cloud.
Another may have an energy management platform that supports OPC UA.
This means that the AHU manufacturer cannot always rely on a single communication protocol.
The BA190Pro supports four major protocols:
BACnet/IP + MQTT + Modbus TCP + OPC UA
This provides multiple options for connecting the AHU to different layers of the customer's architecture.
For example:
Field Layer Sensors / Actuators / Meters / VFDs ↓ BA190Pro ↓ BACnet/IP → BAS
At the same time:
BA190Pro → MQTT → Cloud Platform
And:
BA190Pro → OPC UA → Energy Management / Data Platform
This multi-protocol architecture is particularly useful for AHU manufacturers who need to support different system integrators without redesigning the hardware platform for every project.
For an AHU manufacturer, the actual cost of a project does not end when the control panel is assembled.
Engineers may need to travel to the site for:
For projects involving many AHUs or geographically distributed buildings, these visits can become a significant operational cost.
The BA190Pro integrates with BLRAT, Beilai's remote access tool, enabling remote parameter configuration and firmware upgrades. The datasheet also describes remote adjustment of temperature setpoints, PID parameters and schedules in the reference application.
This does not eliminate the need for commissioning engineers.
Instead, it provides a practical way to reduce unnecessary physical visits after the system has been deployed.
Consider a large commercial complex with:
The existing system uses multiple independent DDC controllers and a Honeywell BAS.
The project has several problems.
First, the power and heat meters use Modbus RTU, while the BAS requires BACnet.
Second, headquarters wants energy consumption data uploaded to a cloud IoT platform.
Third, maintenance engineers have to visit the site regularly to collect data and adjust parameters.
Fourth, during periods of high electricity demand, the operating team wants to adjust HVAC strategies remotely.
These are exactly the types of integration problems that become difficult when every function is implemented using separate devices.
The BA190Pro can be deployed at the AHU equipment layer.
For example:
One BA190Pro
↓
4 AHUs + 2 Power Meters + 1 Heat Meter
The isolated RS485 interface collects Modbus RTU data from the meters.
The local I/O modules connect to AHU field signals such as:
The BA190Pro then provides the required data to the building automation system through BACnet/IP.
At the same time, selected operating and energy data can be published through MQTT to the cloud platform.
The architecture can therefore be represented as:
AHU Sensors / Actuators ↓ BA190Pro Local I/O
Modbus RTU Meters ↓ BA190Pro RS485
Both data sources ↓ BA190Pro
↓ ↓ ↓
BACnet/IP → BAS
MQTT → Cloud
OPC UA → Energy Management / Third-Party Software
The datasheet specifically describes this commercial-complex application, including Modbus RTU acquisition, BACnet/IP integration, MQTT cloud connectivity and OPC UA data access.
This is an important point for AHU manufacturers.
The BA190Pro does provide basic local logic capabilities.
Its built-in Web Server allows configuration of functions such as register operations and conditional judgment without requiring dedicated programming software.
This can be useful for relatively simple tasks such as:
However, the BA190Pro should not be positioned as a replacement for a sophisticated HVAC control programming platform in every application.
For AHU manufacturers with complex control algorithms, advanced PID strategies or highly customized HVAC sequences, the appropriate architecture should still be evaluated according to the actual project requirements.
The stronger value of BA190Pro is its role as a flexible edge I/O and communication platform, combining field I/O, Modbus acquisition and multi-protocol connectivity in one compact device.
This distinction is important because it allows manufacturers to use the BA190Pro where it creates the most practical value—without overcomplicating its role.
From an AHU manufacturer's perspective, the biggest benefit is not simply adding another controller to the control cabinet.
It is creating a more standardized platform for project delivery.
The same BA190Pro controller can be used across different AHU configurations.
Different I/O boards can be selected according to the actual project requirements. The product supports digital I/O, analog I/O, relay, RTD, thermocouple and serial communication modules.
BACnet/IP, MQTT, Modbus TCP and OPC UA are available on the same controller.
Meters and other Modbus RTU devices can be connected through the isolated RS485 interface without necessarily adding another protocol gateway.
Remote parameter configuration and firmware maintenance can reduce the number of unnecessary site visits.
The controller is specified for an operating temperature range of -40°C to 85°C and 5–95% RH. It has also passed EMC tests including ESD, EFT and surge immunity at Level 3.
The traditional approach often looks like this:
AHU → Dedicated Controller → Protocol Gateway → BAS → Cloud Gateway
Each additional device means additional:
A more integrated architecture can look like:
AHU Field Devices → BA190Pro → BAS / Cloud / Energy Platform
The BA190Pro brings I/O acquisition, Modbus RTU communication, protocol conversion and edge connectivity together.
For AHU manufacturers, this can make the control cabinet easier to standardize and the system easier to adapt to different project requirements.
For AHU manufacturers, the challenge is increasingly moving beyond basic temperature and fan control.
Customers expect AHUs to become connected equipment that can communicate with BAS platforms, energy management systems, cloud platforms and other digital systems.
At the same time, AHU manufacturers need to keep their hardware platform standardized while supporting different I/O requirements and communication protocols.
The BA190Pro provides a practical edge architecture for this situation.
Its value is not based on claiming to replace every type of advanced DDC controller.
Instead, it combines:
Modular I/O + Modbus RTU Acquisition + BACnet/IP + MQTT + OPC UA + Modbus TCP + Basic Local Logic + Remote Maintenance
in one compact edge controller.
For AHU OEMs and system integrators, this provides a practical way to simplify field integration, reduce the number of dedicated gateways, standardize control-panel designs and make AHU systems easier to connect to modern building automation and digital platforms.
The goal is simple: build the AHU once, configure it for different projects, and connect it to the customer's automation architecture with less integration complexity.
