PLC vs BMS Data: Getting Real-Time Asset Data into Your CMMS

Somewhere in your building, a controller already knows that a pump is vibrating more than it did last month, that a chiller’s approach temperature is creeping up, and that an air handler’s filter is clogged. It knows because it is measuring those things every few seconds.

Meanwhile, your maintenance team finds out about the same problems when someone complains, an alarm trips, or a technician happens to walk past on a round. The data exists. It just lives in a different system from the one that assigns the work.

Closing that gap is the promise of real-time asset data CMMS integration: using live signals from your equipment to trigger, prioritise, and document maintenance automatically. It is also the practical heart of IoT facilities management. But before you connect anything, you need to answer a basic question that trips up many projects: where should the data come from, a PLC or a BMS?

This guide explains the difference, what each source is good for, how the data actually reaches a CMMS, and how to start without turning your maintenance team into a data engineering department.

What a PLC Is, and What a BMS Is

The two terms get mixed up, so let us separate them.

PLC (programmable logic controller)

A PLC is a rugged industrial controller that runs a specific piece of equipment or process. It reads inputs (sensors, switches, drives), executes control logic, and drives outputs (valves, starters, relays) in fast, deterministic cycles. In buildings, PLCs commonly run:

• Boiler and chiller plant sequences
• Pump skids and booster sets
• Water treatment and filtration systems
• Generators and transfer switches
• Process cooling, clean rooms, and industrial utilities
• Packaged equipment supplied with its own controller

PLC data tends to be detailed and fast: motor currents, run states, pressures, flows, valve positions, alarm bits, and counters.

BMS (building management system)

A BMS, sometimes called a BAS (building automation system), supervises the building as a whole. It typically coordinates HVAC, lighting, access, metering, and alarms across many zones and systems, usually through a mix of field controllers and a supervisory layer with graphics, schedules, trends, and alerts.

BMS data tends to be broad and building-oriented: zone temperatures, setpoints, schedules, damper and valve positions, equipment status, energy meter values, and alarm histories.

A simple way to remember the difference

A PLC controls a machine. A BMS supervises a building. In many facilities they coexist, and sometimes a PLC-controlled plant reports upward into the BMS.

PLC vs BMS Data: A Side-by-Side Comparison

Neither is “better.” They answer different questions, and the best integrations use each where it is strongest.

Why Feed Either One Into a CMMS?

A CMMS (computerised maintenance management system) is where work gets planned, assigned, tracked, and recorded. Controllers are where conditions are measured. Connecting them turns passive monitoring into active maintenance.

1. Runtime-based preventive maintenance

Most preventive tasks are scheduled by calendar, but wear depends on use. A pump that ran 200 hours does not need the same service as one that ran 2,000. Run hours from a PLC or BMS can trigger tasks at the right interval, such as lubrication, belt checks, filter changes, or inspections.

2. Condition-based work orders

Instead of waiting for a failure, a threshold on a live value can open a work order: rising differential pressure across a filter, increasing motor current, a widening approach temperature, or a falling flow rate. The technician receives the context, not just a complaint.

3. Faster, better-informed response

When an alarm raises a work order automatically with the asset, location, time, value, and recent trend attached, the first responder starts with evidence instead of a vague report.

4. Reliable uptime and downtime records

Run status and fault signals give objective start and end times for downtime. That makes availability and other facility uptime measures far more accurate than manual logging. We cover this in our guide on OEE for buildings.

5. A richer asset history

Alarms, readings at the time of failure, and the repair carried out all sit against the same asset record, so patterns and repeat faults become visible.

What You Should Not Do: Send Everything

The most common mistake in IoT facilities management projects is treating the CMMS as a data lake. A building can have tens of thousands of points. A CMMS is not designed to store every temperature reading every few seconds, and your team does not need that.

Think of the CMMS as the action layer. Keep high-volume historical trending in the BMS, historian, or analytics platform where it belongs, and send the CMMS only what drives decisions:

• Events: alarms, trips, and state changes
• Counters: run hours, start counts, cycles
• Summaries: daily or hourly aggregates, such as average, minimum, and maximum
• Thresholds crossed: a derived signal saying a value has been outside limits for a set time
• Selected readings for key assets, captured at sensible intervals

A good rule: if nobody would ever raise a task, make a decision, or write a record based on a data point, it probably does not need to be in the CMMS.

How Data Actually Gets From a Controller to a CMMS

There is no single route. Most successful integrations use a layered approach.

Layer 1: The field and controller level

Sensors and equipment connect to PLCs and BMS controllers using field protocols. This is where data is created.

Layer 2: The protocol and gateway level

Controllers expose data through standard protocols. Common ones include:

A gateway or edge device usually sits between the control network and the outside world. It reads from controllers, translates protocols, filters and buffers data, and sends it onward securely.

Layer 3: The integration or middleware level

An integration layer maps incoming points to assets, applies rules, and decides what becomes an event. This might be an IoT platform, an integration engine, a BMS integration module, or an analytics tool.

Layer 4: The CMMS

The CMMS receives events, counters, and selected readings through an API, webhook, or message feed. It matches them to assets, then creates and updates work orders, records meter readings, and stores history.

Three Common Integration Patterns

Pattern A: BMS-first

The CMMS connects to the BMS supervisor, which already aggregates many controllers. This is often the quickest route for HVAC, lighting, and metering data.

Strengths: One integration point, consistent building structure, existing alarm logic.
Watch for: Limited detail on machine internals, alarm overload, and dependence on the BMS vendor’s interface.

Pattern B: PLC-direct

The integration reads directly from specific PLCs, usually through OPC UA or Modbus, via a gateway.

Strengths: Rich detail for critical plant such as boilers, chillers, pumps, and generators.
Watch for: Inconsistent tag naming, security considerations, and the need to coordinate with controls engineers.

Pattern C: Hybrid

The BMS provides building-level status and alarms, while selected PLC-controlled assets feed detailed signals directly. This is the most common arrangement in mixed facilities and often the best balance.

Choosing Between PLC and BMS Data

Use these questions to decide which source to start with for a given asset.

1. Which system actually controls the asset? Go to the source that owns the control logic.
2. What decision will the data drive? Run hours and alarms may be enough. Condition-based maintenance may need richer signals.
3. How critical is the asset? Critical plant justifies deeper integration. Low-criticality equipment may only need status and alarms.
4. How reliable and consistent is the data? A well-structured BMS point list can beat an undocumented PLC tag set.
5. Who maintains the interface? Pick a route your controls contractor and IT team will support long term.
6. What are the security implications? The more direct and open the route, the more carefully it must be segmented and secured.

A practical pattern: start with BMS data for building-wide HVAC and energy, and add PLC data for the handful of assets where machine-level detail will change maintenance decisions.

The Hard Part Is Rarely the Protocol

Teams often assume that the technical challenge is getting the connection working. In practice, the harder problems are about meaning and discipline.

Mapping points to assets

A value called AHU3_SAT in a BMS or P102_MTR_AMPS in a PLC means nothing to a CMMS until it is linked to a specific asset record. Build and maintain a point-to-asset map, using consistent asset IDs across the BMS, PLC documentation, and CMMS.

Naming and tagging

Adopt a clear naming convention, and consider a standard tagging approach for equipment and points. Inconsistent names are the single biggest cause of integration pain and rework.

Units and scaling

A pressure might arrive in kPa, psi, or raw counts. Record units and scaling for every mapped point, and verify against a trusted reading before trusting the feed.

Alarm quality

Sending every alarm to the CMMS creates a flood of work orders nobody can act on. Filter and prioritise before integrating.

• Use deadbands and delays so a value must stay out of range for a set time.
• Use severity levels so only actionable alarms create work orders.
• De-duplicate repeats from the same asset, and attach them to the open work order.
• Suppress nuisance alarms at the source rather than hiding them downstream.

Data quality and sensor health

A failed or drifting sensor can generate false work orders. Include checks for flat-lined values, out-of-range readings, and communication loss, and treat a bad sensor as its own maintenance item.

Time and connectivity

Make sure clocks are synchronised and that the integration buffers data if the connection drops, so downtime records are accurate and no events disappear.

Security: Treat It as Part of the Design

Connecting building and plant controls to a cloud or enterprise system extends the reach of your network. Plan for security from the start.

• Segment networks, keeping control systems separate from general IT.
• Prefer outbound-only connections from the edge device to the cloud, rather than opening inbound access to controllers.
• Use encryption and authentication for every link, and avoid unsecured default settings.
• Apply least privilege. Start with read-only access. Grant write access only where there is a clear need and a reviewed process.
• Keep an inventory of gateways and integration accounts, and apply updates.
• Involve IT and your controls contractor early, and document responsibilities.

Security expectations vary by organisation and jurisdiction, so involve your IT, cybersecurity, and compliance teams before connecting anything.

From Signal to Work Order: Examples

Here are examples of how live data can drive maintenance in practice. Thresholds are illustrative and should be set with your equipment manufacturer and controls team.

For related guidance on turning equipment alarms into a maintenance record, see our guides on chiller fault codes and fire alarm panel trouble codes.

A Step-by-Step Plan to Get Started

You do not need a building-wide IoT program to see value. A phased approach lowers risk and builds trust.

Step 1: Pick a clear use case

Choose one outcome, such as runtime-based PM for pumps, automatic work orders for critical alarms, or accurate downtime tracking on chillers.

Step 2: Choose a small set of assets

Start with five to ten assets where the benefit is obvious and the data is accessible.

Step 3: Identify the data owner and source

For each asset, find out which controller holds the data, who maintains it, and which protocol is available.

Step 4: Define the points you actually need

List the specific signals: run status, run hours, fault state, and one or two condition indicators. Resist the urge to add more.

Step 5: Clean up asset records and naming

Make sure each asset exists in the CMMS with a unique ID, location, and equipment details, and map points to those IDs.

Step 6: Design the rules

Decide thresholds, delays, priorities, and what each rule should do. Involve technicians so the rules match how work really happens.

Step 7: Connect securely and test

Establish the connection with read-only access, verify values against what technicians see on site, and test rules with simulated events.

Step 8: Pilot and tune

Run the pilot for a few weeks. Review false alarms, missed events, and technician feedback, and adjust.

Step 9: Measure the result

Track the number of automatically created work orders, response times, unplanned downtime, and technician time saved.

Step 10: Expand deliberately

Add assets, signals, and rules in stages, and keep the standards you set in the pilot.

Building the Foundation First

Live data magnifies the quality of your maintenance basics. If asset records are incomplete, tasks are poorly defined, or work orders are not closed properly, integration will amplify the mess. Get the fundamentals right before connecting everything. Our guide on how to start a preventive maintenance program covers the groundwork, while our posts on why a CMMS is essential for preventive maintenance and how it can streamline preventive maintenance explain how scheduled work, asset history, and reporting fit together. If you are evaluating platforms, FacilityBot’s CMMS software page shows how these pieces connect.

Common Mistakes in Real-Time Asset Data Projects

Sending too much data. The CMMS is for action, not storage.

Skipping the asset map. Without consistent IDs, signals cannot be tied to assets.

Creating a work order for every alarm. Filter, prioritise, and de-duplicate.

Ignoring sensor health. Bad data creates bad work.

Granting unnecessary write access. Begin read-only.

Leaving IT and controls teams out. Integration needs both.

Starting with the whole building. A narrow pilot teaches more, faster.

Forgetting the technician. If the work orders are unclear, the best data in the world will not help.

Treating the project as one-off. Points change, equipment is replaced, and rules need review.

Frequently Asked Questions

What is real-time asset data in a CMMS?

Real-time asset data in a CMMS means live or near-live information from equipment, such as run status, run hours, alarms, and key readings, flowing into the maintenance system so that work orders, meter readings, and asset history update automatically.

What is the difference between PLC data and BMS data?

A PLC controls a specific machine or process and produces detailed, fast-changing signals. A BMS supervises building systems as a whole and produces broader, building-oriented data such as zone temperatures, schedules, and alarms.

Should I connect my CMMS to the PLC or the BMS?

It depends on the asset and the decision the data will support. The BMS is often the quickest route for building-wide HVAC and energy data. PLC data is better for detailed machine health on critical plant. Many facilities use both.

What protocols are used to get building data into a CMMS?

Common options include BACnet, Modbus, OPC UA, MQTT, and REST or vendor APIs, often through a gateway or integration platform. The right choice depends on what your controllers support.

How does IoT facilities management work with a CMMS?

IoT facilities management uses connected sensors and controllers to gather live equipment data. A CMMS receives selected events and readings and turns them into work orders, scheduled tasks, and records.

Do I need new sensors to start?

Not necessarily. Many assets already expose run status, alarms, and key readings through existing controllers. Add sensors only where a clear maintenance decision depends on data you cannot get today.

How much data should I send to the CMMS?

Only what drives action: alarms, state changes, counters like run hours, summaries, and selected readings for key assets. Keep high-volume trending in the BMS, historian, or analytics platform.

How do I avoid too many automatic work orders?

Use delays, deadbands, severity levels, and de-duplication. Create work orders only for conditions that need a human response, and group repeat events against the open work order.

Is it safe to connect building controls to a cloud CMMS?

It can be, when designed properly. Segment networks, use outbound-only encrypted connections, start with read-only access, and involve IT and controls specialists. Requirements vary, so confirm with your security team.

How long does it take to get started?

A focused pilot on a handful of assets can be done in weeks, depending on access to controllers, the quality of asset records, and approval from IT. Wider rollouts take longer and benefit from standards set during the pilot.

Can live data replace preventive maintenance schedules?

Not entirely. Live data refines schedules by adding runtime and condition triggers, but regulatory inspections, safety tests, and manufacturer-required tasks still need to be scheduled and documented.

Simplify Connected Maintenance With FacilityBot

Data only matters when it changes what your team does next. FacilityBot helps facilities teams turn signals into action. Our facilities management software keeps assets, work orders, schedules, and history in one place, giving live equipment events somewhere meaningful to land. As a facility management solution built for lean teams, it connects condition triggers, preventive tasks, and contractor work, so an alarm becomes a documented job instead of a missed message. Because it is cloud based CMMS software, technicians can open an auto-created work order, review the context, and close it out from a phone at the equipment, while managers see the effect across every site. And with built-in fault reporting software, staff and occupants can report what the sensors cannot see, from a strange noise to a warm room, so human observations and real-time asset data CMMS records sit side by side. Book a demo to see how FacilityBot can support your IoT facilities management goals.

Written by

Anns Ahmad