CMMS BMS integration connects the system that senses a building fault to the system that ensures somebody fixes it. The BMS sounds the alarm. The CMMS turns that alarm into a work order, assigns it and logs what was done. Integrated correctly, nothing relies on somebody seeing a flashing screen. Integrated poorly, you end up with alarm floods, duplicate tickets and asset records that no longer resemble the equipment in the plant room.
This tutorial explains how data moves, what protocols transport it, how to plan the project, what can go wrong and how to gauge success.
PODTECH
Connect building data to maintenance. PODTECH specializes in custom software development and integration of mission critical infrastructure components such as building management systems (BMS) for the enterprise. Learn more at podtech.com.
TL;DR
- BMS stands for Building Management System. CMMS stands for Computerized Maintenance Management System. The BMS controls and monitors building services. The CMMS keeps track of work and work history. When integrated, BMS alarms and runtime data can automatically generate and prioritize work orders.
- The majority of integrations connect using BACnet, Modbus or an API layer.Point naming, asset mapping and alarm filtering tend to be the difficult parts, not the connection.
- Break it up into steps: use cases, asset and point mapping, rules, pilot, then roll-out.
- Treat the link as an extension of your OT security perimeter: segment, use firewalls, encrypt in transit and apply least-privilege access.
Look at work-order response time, percentage of predictive work orders and energy outcomes, rather than simply counting alarms forwarded.
Table of Contents
- What a BMS and a CMMS each do
- What integration enables
- How data flows between the two systems
- Planning the integration step by step
- Common problems and how to handle them
- Securing the connection
- Measuring the return
- Our perspective
- Talk to us about your integration
- FAQ
- Sources
What a BMS and a CMMS each do
A building management system (BMS) controls and monitors the electrical and mechanical services in a building. Examples include heating and cooling, ventilation, power, lifts, lighting and security or access control. It operates on a real or near real time basis with the primary purpose of control and monitoring.
The CMMS, or computerized maintenance management system, is where maintenance history and workflow lives. It stores your asset register, service history, equipment logs, calendars, parts and technician assignments. It answers a slightly different question to the BMS. Instead of asking “what is happening now?” it asks “who is doing what about it, and what has been done before?”
The split is important because one system is weak where the other is strong. A BMS can alert you that an air handler's supply temperature has drifted. It is not designed to record who attended, what part was fitted or whether the same fault has occurred four times this year. A CMMS can store all of the above, but without a live link can only know what people tell it.
What integration enables
Once connected, real-time data exchange and automated workflows are enabled. If a pre-determined threshold is exceeded, the CMMS is alerted and can create a work order. Performance and runtime information can also be used to trigger condition-based maintenance instead of scheduled calendar intervals.
In practice, the benefits fall into four groups:
- Quicker response. The ticket is created as soon as the alarm occurs, complete with asset, location and fault attached.
- Accountability. Every alarm has an owner, a status and a closure record.
- Improved scheduling. Inspections are driven by run hours and condition data, so crews are not spent servicing good equipment on a calendar basis. They start focusing on the equipment that needs attention.
- A cleaner history. Repeat faults become visible per asset, which supports repair-or-replace decisions.
Interested in more maintenance-focused details? Check out our guide to predictive maintenance models.
How data flows between the two systems
Traffic flows both ways, however one direction is usually built before the other by most teams.
- BMS to CMMS (events). Alarms, status changes and threshold breaches create or update work orders.
- BMS to CMMS (metering). Runtime hours, starts, temperatures and energy readings populate asset records and feed condition-based triggers.
- CMMS to BMS (context). Less common, but useful: an open work order can suppress alarms for equipment that is being worked on, preventing technicians from being bombarded by nuisance alarms while trying to do their tasks.
Protocols and interfaces
Computerised devices on the building side typically communicate using a building automation protocol. ASHRAE Standard 135-2024, the BACnet standard, specifies the information exchange between computerised units of arbitrary function for use in applications including HVAC control, lighting, access control and fire detection. You begin with BACnet because it is the common denominator, due to that wide use. If your site is transitioning to encrypted BACnet, read our BACnet Secure Connect briefing from the integrator's perspective.
| Approach | Typical use | What to watch |
|---|---|---|
| Direct BACnet connection | Sites where the BMS already exposes BACnet objects | Network routing, point naming, discovery across subnets |
| Modbus gateway | Plant, meters and drives with serial or TCP Modbus | Register maps, polling load, scaling |
| API or REST layer | Modern BMS platforms and cloud CMMS | Rate limits, authentication, version changes |
| Middleware or integration platform | Several BMS brands, or a mix of building and IT systems | Another system to run, secure and support |
There's no one right answer. A single-vendor site with a relatively new API may require nothing more than a point-to-point connector. A four-BMS-brand campus will typically benefit from some sort of common integration layer, often a master systems integrator approach.
Planning the integration step by step
1. Define the use cases first
Begin with results, not data points. Common starters include self-generated corrective work orders for critical alarms, run-hour-based preventive tasks, and filter or belt inspections triggered by differential pressure. Choose two or three. Each additional use case you consider will exponentially increase mapping efforts.
2. Map assets and points
This is where success or failure is determined. Map out what asset exists in CMMS to the actual BMS device and respective points you care about: alarm, status, run command, runtime and key analogue values. Create a mapping document of CMMS asset ID, BMS object reference, point type, units and alarm priority.
If your CMMS asset register and BMS naming have come from separate decades and contractors, you will find yourself spending more time fixing things here than anywhere else. You can use a configuration database to maintain the relationship; see our glossary entry for CMDB.
3. Decide what deserves a work order
Not every alarm should become a ticket. Split points into three tiers:
- Create work order. Equipment failures, unsuccessful starts and prolonged out-of-range readings on critical assets.
- Notify only. Warnings that need awareness but not a crew.
- Log only. Informational and transient events kept for trend analysis.
Add delay timers and de-duplication so one fault produces one ticket, not forty.
4. Build the rules and the data path
Publish the BMS data to a common interface. Next, create the rules that will generate work orders, set priority and populate asset fields. Store the rules in configuration, not hidden away in scripts, so they can be reviewed by maintenance and controls.
5. Pilot, then roll out
Roll it out on one building, one type of plant or one critical system first. Evaluate the tickets it created with the technicians who received them. What was valuable? What was noise? Tune thresholds and mappings, then expand. A pilot of a few months that covers an entire seasonal change will teach you more than a quick bench test ever will.
6. Commission and hand over
Test every mapped point from end to end: confirm the condition forces the alarm, the work order and the closure path. Log test results against the asset. Commissioning windows can be small, so preload your test sheet.
Common problems and how to handle them
Field experience mirrors ours. The BACnet retrofit case study mentions the typical problems: mixing data types, carrying forward point-naming conventions, routed networks which make device discovery difficult, narrow windows of opportunity for commissioning and more. It also notes that a single gateway or middleware layer can reduce risk of protocol-mismatch failures in mixed protocol environments.
| Problem | Why it happens | What helps |
|---|---|---|
| Alarm floods | Every BMS alarm forwarded as a ticket | Priority tiers, delay timers, de-duplication |
| Wrong asset on the ticket | Inconsistent naming between systems | A mapping table owned by one named person, reviewed at every change |
| Missing points | Discovery blocked by routed networks | Plan network paths with IT before commissioning |
| Legacy controllers | Old protocols or no network interface | Gateways, or a phased controller upgrade |
| Stale mappings | Equipment replaced, mapping not updated | Make the mapping update part of the work order closure |
There is one other category that deserves special mention: legacy estates. When the BMS is so old that no supported interface is available, the answer is almost never “wait”. You can expose the data with a gateway or integration layer while a longer-term modernisation project is planned. Check out our BMS and PMS integration services page to learn how we handle that sort of mixed estate.
Another perspective to consider: the integration of building controls into maintenance platforms, with work orders, asset records and service history included, falls under the umbrella of implementation, not just an individual connection effort.
Securing the connection
A CMMS is typically an IT system, often cloud-based. A BMS is operational technology. Connecting the two bridges the gap between those worlds, and should be designed as such.
Recommendations for cybersecure BMS architecture identify the foundational controls: network segmentation, firewalls, encrypting data in transit, least-privilege access and more, including coordination with the owner's security team. This same guidance is commonly aligned with IEC 62443.
Applied to a CMMS link, that means:
- Place the integration server in a DMZ with firewall rules permitting only necessary ports and addresses.
- Prefer outbound or brokered flows to eliminate direct connection to controllers from the CMMS where possible.
- Encrypt traffic in transit between the BMS network and the CMMS.
- Allow the integration account read access only to the points it needs. Grant write access only for a specific use case, such as alarm suppression, and only after security approval.
- Involve your information security team before design, not after commissioning.
Measuring the return
Decide the metrics before go-live, and capture a baseline.
- Mean time from alarm to work order. It should fall to seconds.
- Mean time to attend and to close, by priority.
- Share of planned versus reactive work. Integration should push this toward planned.
- Share of predictive work orders, meaning those raised from condition data.
- Energy and comfort outcomes, where the same data supports them.
Here's a published US example: the University of Iowa monitored 49 buildings comprising 6.7 million square feet and four building management systems through one system-agnostic platform. In the first year, they realized over $900,000 in energy savings, and around 17% of their HVAC-related work orders, 705 total, were preventive maintenance work orders. Obviously your numbers will vary depending on your estate, so use examples like this to identify what you should measure, not to predict your results.
Learn more about smart-ready building architecture in why master systems integration matters and our smart buildings overview.
Our perspective
“What we notice in most integration projects is similar behaviour. The technology only takes days to connect. Weeks are spent determining what an alarm means, which asset it relates to and who owns the ticket.”
That is why we build from the mapping and the alarm tiers first, not the connector. A clean asset-to-point table and a well-defined rule for work order generation does more for a maintenance team than simply forwarding everything possible.
We build for the entire estate as well. Critical infrastructure rarely operates using just one vendor's controls. It typically uses BMS, PMS and NMS concurrently, with equipment from multiple generations. Our master systems integration work aims to install a single, secure data layer over that infrastructure, allowing the CMMS to view a single, consistent picture. Supported by a 99.9% uptime SLA and global support, we have successfully completed more than 250 projects.
When done correctly, connectivity between BMS and CMMS systems is the software layer between a fault and a fix.
Harry
Talk to us about your integration
PODTECH develops custom software stacks and integration layers for mission critical infrastructure. Whether your projects include BMS, PMS and NMS integration, datacenter telemetry or enterprise automation, if you are looking to connect your CMMS and BMS together, or take the first steps towards modernising your existing control estate, our team can help scope your mapping, data path and security design.
Explore our systems integration services or skip ahead to enterprise automation software.
FAQ
What is the difference between a BMS and a CMMS?
A BMS monitors and controls building services such as lighting, HVAC, power and access control in real time or close to it. A CMMS manages the maintenance work that goes on within a building, including asset records, schedules, work orders and service history. One senses and takes action; the other plans the work and maintains the record.
Which protocols are used to connect a BMS to a CMMS?
BACnet is probably the most prevalent on the building side and is specified in ASHRAE Standard 135. Modbus tends to be prevalent on plant and meters. These days systems also commonly include an API or middleware layer towards the CMMS. The right combination depends on what your BMS exposes and how many brands you have.
Should every BMS alarm create a work order?
No. Tier alarms so that work orders are created when equipment malfunctions or critical conditions are sustained. Notify for warnings. Log informational events. Include delay timers and de-duplication so one fault does not create hundreds of tickets.
How long does a BMS and CMMS integration take?
The timing depends on the number of assets involved, the condition of your naming and the existing interfaces. Mapping and alarm design often take longer than the connectivity itself. Doing a pilot on one building or one system allows you to tweak the rulesets prior to a broader deployment.
How do we keep the connection secure?
Use network segmentation, firewall traffic restrictions, encryption in transit and least-privilege access for the integration account. Engage your security team early in the design. For BMS architecture design, refer to IEC 62443-aligned guidance.
Sources
- ASHRAE Standard 135-2024 (BACnet)
- Guidance on implementing a cybersecure BMS architecture
- BACnet retrofit case study: multi-protocol integration
- University of Iowa building management case
- How to use CMMS for effective maintenance management
- IWMS, CMMS, CAFM, EAM and BMS: what's the difference?
- Construction software implementation