Edge Computing for Facility Management: Signal to Work

Edge computing in facility management keeps selected processing close to building equipment, then sends a qualified event into an accountable maintenance workflow. The useful pattern is signal, rule, assigned work, and verification. Moving data closer to the equipment is not a result by itself.

The NIST fog computing model describes distributed processing as a complement to centralized cloud computing for IoT systems. For a facility manager, the practical question is narrower: which decisions need to remain local, and which facts need to enter the maintenance record?

Edge computing and the maintenance record do different jobs

Building controls, edge services, and a CMMS may share data, but they should not share authority without clear design.

NIST’s Guide to Operational Technology Security treats building automation as operational technology and emphasizes its performance, reliability, safety, and timing requirements. That boundary matters. A cloud maintenance application can open and route work, but it should not be presented as a substitute for approved safety controls or local operator authority.

Use a signal-to-verification operating chain

A connected response is useful only when each handoff is defined.

1. Signal

Start with a named measurement or device state. Record the device identifier, linked asset, location, unit, expected reporting interval, valid range, and time source. A payload called temp1 without an asset or unit is not ready to drive work.

Check data quality before applying a maintenance rule. Useful checks include:

• missing or stale readings
• values outside the sensor’s specified range
• duplicate messages
• clock drift or impossible timestamps
• abrupt changes caused by restart or replacement
• device health, calibration, or battery state where available

2. Rule

A rule explains when a signal becomes an event. It should name:

• the condition and unit
• any dwell time, deadband, or repeated-reading requirement
• occupied, seasonal, load, or operating-state context
• suppression and reset behavior
• priority and escalation route
• rule owner, version, and effective date

Do not copy a threshold from another building and call it a standard. Use equipment guidance, an approved control sequence, an engineering decision, or a measured site baseline. Record the source so the team can review it later.

3. Accountable work

The event should either inform a named operator or create a work order with enough context to act. The work order record needs the linked asset, event time, rule, current condition, priority, owner, and response instructions. It should also explain what not to do when the condition requires controls or safety authorization.

Avoid one work order per reading. Deduplicate repeated events, keep an open incident associated with the continuing condition, and define when a new event should reopen or create work.

4. Verification

Closing a work order is not proof that the condition cleared. Define verification before the pilot:

• the signal returned to an accepted state for a defined period
• a technician inspected and documented the cause
• a local control test passed
• a follow-up reading or manual measurement agreed with the sensor
• the event was classified as valid, false, duplicate, or unresolved

Store the verification result with the asset record. That turns telemetry into maintenance history that can support future rule changes and equipment decisions.

When edge processing earns its place

Not every sensor needs an edge computer. A direct device-to-cloud connection may be sufficient for slow, low-volume monitoring with tolerant response times. Edge processing is more defensible when at least one of these conditions applies.

Local timing or continuity is required

Some building processes cannot wait for an internet round trip. NIST notes that certain operational technology functions may need computation close to sensors and actuators to meet control timing requirements. Keep those functions within the approved local controls design. Send the resulting maintenance event upstream in parallel or afterward.

Raw data volume is higher than the maintenance need

Vibration, electrical waveform, and other high-frequency measurements can produce far more data than a work order needs. An edge service can calculate a site-approved feature, retain a short diagnostic window, and send the event plus relevant evidence. Do not discard raw data blindly. Set retention from diagnostic, contractual, and engineering needs.

Connectivity is intermittent

Basements, roofs, plant rooms, remote compounds, and temporary sites may lose upstream connectivity. Local buffering can preserve events, but only if queue capacity, event ordering, clock behavior, and recovery are tested. A gateway that reconnects by sending hundreds of duplicate alarms creates a different failure.

Data should be minimized before it leaves the site

Occupancy, access, image, audio, or location data may require extra privacy review. Local aggregation can reduce what leaves the site, but edge placement does not make collection automatically lawful or appropriate. Define purpose, access, retention, deletion, and whether the maintenance workflow needs personal data at all.

Existing controls need a translation boundary

An edge gateway can translate device or building protocols into a stable event contract. ASHRAE defines BACnet for communication among building automation and control devices. MQTT 5.0 is an OASIS publish-and-subscribe messaging standard suited to constrained IoT environments. Protocol support moves data; it does not define alarm ownership, work priority, or proof of resolution.

Three facility examples with clear boundaries

Water leak response

A moisture sensor reports water near a pump. The local control environment may sound an alarm or operate an approved valve sequence if the controls design permits it. The edge service validates the event and retains the first reading. The CMMS opens assigned work against the pump or location. The technician records the source, repair, cleanup, and post-repair dry-state check.

The EPA’s WaterSense leak detection guidance supports leak detection and repair as part of commercial and institutional facility water management. It does not establish a universal financial return or prescribe one sensor layout for every building.

Rotating equipment condition event

A vibration device sends high-frequency samples to a local processor. The edge service calculates the approved condition indicators and retains a diagnostic sample around the event. A sustained exception creates an inspection work order. A technician checks alignment, lubrication, mounting, load, and sensor condition before deciding whether the equipment has a fault.

The edge result is evidence for investigation, not an automatic diagnosis. For rule design and maintenance context, see the condition-based maintenance guide.

Indoor air quality exception

An indoor air quality sensor reports a persistent value outside a site-approved operating band. The building management system may adjust ventilation under its control sequence. The CMMS receives a maintenance event only when the condition persists, the control response fails, or equipment inspection is required. The work record retains the zone, readings, control state, investigation, and verification.

ASHRAE Standard 62.1 sets ventilation and indoor air quality requirements for non-residential buildings. A sensor reading alone does not prove compliance with the standard.

Design the edge-to-CMMS event contract

Keep the integration payload small enough to understand and complete enough to investigate.

For messaging, MQTT can carry event payloads from gateways, while HTTPS APIs can create or update records. The protocol choice should follow security, delivery, support, and network requirements. Do not promise exactly-once operational behavior unless the whole path, including retries and the receiving application, has been designed and tested for it.

Secure and operate the edge layer as an asset

An edge gateway is not invisible infrastructure. Give it an owner and lifecycle record.

NIST’s IoT cybersecurity baseline highlights device identification, configuration, data protection, interface access, software update, and cybersecurity state awareness. Apply those questions to gateways and connected devices:

• Who owns the device and its credentials?
• Which interfaces and services are enabled?
• How are configuration changes approved and logged?
• How are software and security updates delivered?
• What happens when vendor support ends?
• How does the team detect a silent device or failed gateway?
• Can a replacement device keep the asset mapping and event history?
• How are local data and credentials removed at retirement?

For LoRaWAN devices, use the current regional parameters and network design for the deployment. The LoRaWAN L2 specification describes a protocol optimized for battery-powered devices, but actual coverage and battery life depend on payload size, reporting interval, radio settings, gateway placement, building materials, firmware, and environmental conditions. Verify both on site.

Run a pilot that tests failures, not only the happy path

Choose one operational problem, a limited asset group, and a named response team. Set acceptance criteria before installation.

Before commissioning

1. Confirm the asset and location records.
2. Approve the local control boundary and rule source.
3. Survey connectivity, power, enclosure, and maintenance access.
4. Define the event contract, owner, escalation, and closure evidence.
5. Record the baseline and the business or operating question.

During commissioning

Test valid and invalid readings, duplicate events, stale data, device restart, gateway restart, rule updates, clock errors, network loss, queue recovery, and device replacement. Confirm that the right person receives one understandable task and that local controls remain safe when the CMMS is unavailable.

During the operating trial

Track measures that reveal whether the workflow works:

• valid events delivered and linked to the right asset
• missed, duplicate, stale, and false events
• events that created unnecessary work
• acknowledgement, assignment, and closure times by priority
• unresolved events and repeat conditions
• percentage of closed work with required verification
• operator time spent maintaining devices, rules, and integrations
• gateway, device, and integration availability

Review the evidence with facilities, controls, IT, security, and the technicians who received the work. Scale only when the team can explain how the system behaves during faults and who owns each exception.

Evaluate the complete operating path

Ask vendors to demonstrate a live event from signal through closure. Include an outage and a duplicate message. Check whether the event keeps its original timestamp, maps to the right asset, uses the correct rule version, reaches a named owner, and retains the investigation and verification result.

When evaluating Infodeck IoT monitoring, connect the discussion to the smart sensor and CMMS integration guide and your actual controls boundary. Review pricing for commercial scope, then book a demo to test one sensor-to-work-order scenario against your sites and response process.

Edge computing earns its place when it makes a defined building response more dependable and the resulting maintenance work more accountable. Keep control where it is safe, keep work where people can own it, and keep enough evidence to verify what happened.

Sources and references

1. NIST SP 500-325: Fog Computing Conceptual Model
2. NIST SP 800-82 Revision 3: Guide to Operational Technology Security
3. NISTIR 8259 Series: IoT Cybersecurity Guidance
4. OASIS MQTT Version 5.0
5. ASHRAE Standard 135 BACnet Resources
6. LoRa Alliance LoRaWAN L2 1.0.4 Specification
7. EPA WaterSense Best Management Practices
8. ASHRAE Standards 62.1 and 62.2