Connecting building automation and production data in factories
Many factories share the same setup. Production automation belongs to one organization, one budget, and one set of vendors. Building automation belongs frequently to another. Both work well from their own point of view, yet they share the same power connection, the same heat, the same air, and often the same product.
In winter this is easy to see. Process cooling might blow heat outside while the building system heats the same hall with district heating. Each system works properly, but is isolated from the other. The problem is that the plant is paying for the same energy twice.
We are adding BACnet support to Prosys OPC UA Forge to help bridge the gap between factory and building automation. This post reflects the real use cases and needs we have identified.
What gets connected and what stays separate
Nobody sensible wants ventilation control and production PLC logic running in the same control system, or a change on the production side touching the control loops of an air handling unit.
The control loops should stay where they are, but data can be connected: temperatures, humidity, energy measurements, equipment states and alarms from both sides, in one place, with the same timestamps and the same context.
Telling the building system that a line is about to start, or that a hall will be empty for the weekend, means changing a setpoint or operating mode. BACnet has a good mechanism for doing this safely. Commandable objects have a priority array with 16 levels. A supervisory system writes at an agreed priority; anything at a higher priority, such as safety functions or an operator override, still wins, and when the supervisory command is relinquished, the device falls back to its own logic. The building system stays in charge, and it simply gets better information about how the space is being used.
By default, every point is read-only, with writes allowed only to the handful of setpoints and modes agreed with the building contractor.
Heating, cooling and waste heat
Most plants already do something here. Ventilation runs on a weekly schedule, and heating follows setpoints that were tuned during commissioning. The problem is that these settings stay fixed. The building system runs the same program whether the lines are running at full load or standing idle for a week, and nobody changes the schedule for an extra weekend shift.
A production line is a heat source, since machines and especially compressed air compressors turn most of their electricity into heat. When the building system knows which lines are running and when the next shift starts, it can adapt rather than react. A small setpoint offset can reduce heating before the process heat reaches the space, and air handling units serving local exhaust can change mode together with the machines. In a Nordic winter, that adds up quickly, because every cubic meter blown out has to be replaced with heated air.
The same data helps when sizing heat recovery or using the building as a thermal buffer against spot electricity prices. Both need history on when heat is produced and needed, and on how much temperature and humidity production can tolerate. They also need energy flows measured in addition to temperatures, and in many plants missing heat meters and sub-metering are the first finding once the data is brought together.
The cold chain in food production
In food production, there is also a food safety reason to bring the data together. The product moves from pasteurization through a chilling tunnel and packaging into cold storage and out to the loading dock. Production automation measures part of that journey, and building automation measures the rest. The product’s temperature history should still be unbroken.
When a cold store warms up overnight, the first question is which batches were in there and for how long. Answering it requires storage temperatures from the building system and batch locations from the MES or warehouse system, and often process temperatures from production as well. If they live in separate places, putting the answer together takes time, and when in doubt, more product gets scrapped than necessary.
The same data shows root causes that cross the system boundary. The cold store may have warmed up because the chilling tunnel was overloaded and product came in too warm, or because doors stood open during a production peak. Neither system alone tells you why.
Having the temperature data, alarms, and equipment states in one place also makes the evidence for quality reviews and audits much easier to find. And since refrigeration is one of the biggest energy consumers in a food plant, the same data feeds the energy work described above.
The hard part is context
Reading values from building automation is rarely the hard part. The protocols are well known and the devices answer. The problems are elsewhere.
Point naming on the building side depends on the contractor and the vendor, and it is often cryptic. Sampling is sparse or change-based, while production people are used to second-level data. Most importantly, the information about which zone or air handling unit serves which line is usually missing altogether. A humidity reading without that link is just a number.
The two systems also organize the plant differently. The building system groups its points by building, floor and zone, and it should keep doing so, because that is how the building is operated and maintained. Production people think in ISA-95 terms: site, area, line and cell. In practice I would use the production structure as the backbone and place building data under the area or line it serves, while each point keeps its link back to the BACnet object it comes from. The two systems stay separate and keep exchanging data, and someone looking at line 2 sees the hall temperature and the ventilation state next to the machine data. OPC UA information models work well for this because they describe both the structure and the relationships.
No protocol solves this for you. Somebody has to walk the plant with the building drawings and the production layout and decide how the pieces relate. That work is worth doing once and properly, because everything built on the data afterwards relies on it.
BACnet in Prosys OPC UA Forge
The next release of Prosys OPC UA Forge adds a BACnet connector. Forge already supports Modbus, and BACnet is one of the most common protocols on the building side, so together they cover a large part of what you find in a typical building management system.
BACnet devices appear in the same OPC UA address space as the production OPC UA servers, PLCs and Modbus devices. We put some effort into making them look like proper OPC UA data. Analog objects become AnalogUnit variables with engineering units as standard UNECE codes, an engineering range and a value precision. Binary objects become TwoStateDiscrete variables and multistate objects MultiStateDiscrete variables. The device’s manufacturer, model, serial number and software revision come along as properties. Any OPC UA client, historian or our Grafana plug-in can tell that a value is a percentage within a given range without knowing anything about BACnet, and building data uses the same unit definitions as production data.
The tag itself is still addressed the BACnet way, by object type and instance. Meaning comes from what you do next: adding references that place the point in the plant structure, next to the zone and the line it relates to, and turning on history where it is needed.
For writing, each tag has its own settings. A tag can be forced read-only, and for writable tags you choose the BACnet write priority. Relinquishing writes a null at that priority, the device returns to its own logic, and any higher-priority command keeps winning. That is the mechanism the supervisory scenarios above rely on.
Building automation often has thousands of points, so it also matters that Forge licensing does not depend on the number of tags or users. Bringing the building side in does not make the licence cost grow with the point count.
Where to start
I would not try to connect the whole plant at once. Pick one space and one line where there is already a concrete question on the table, for example energy use that production volumes do not explain, or a cold store whose deviations keep the quality team busy.
The first step is usually mapping what is measured and where. That quickly shows whether energy metering is missing and who actually knows which air handling unit serves which area. Then bring the data into one model, read-only to begin with, and model the relationships from the start. Writing setpoints or modes can come later, once both sides trust the data and have agreed which points may be touched.
That agreement is often the most useful outcome of the whole exercise. The facility manager and the production manager rarely share budgets or targets, but once they look at the same data they start talking about the same problems.
If you have a question like this on the table at your plant, I am happy to talk it through.
Pyry Grönholm
CEO
Email: pyry.gronholm@prosysopc.com