How UDMI Relates to BACnet and Other Field Protocols

In practice, many owners run both: BACnet (or BACnet/SC) for bi-directional real-time control at the building level, and UDMI for portfolio-wide telemetry ingestion, security management, and lifecycle operations at the cloud level. Choosing UDMI as a preferred protocol for the management layer does not require abandoning the field-level standards already embedded in existing building automation systems.

The foundational core of UDMI is robust operation at scale, focusing on campus, regional, or global fleet managed systems rather than isolated installations. By borrowing proven paradigms from standardized IT-centric systems—such as declarative configuration and cloud-managed lifecycles—UDMI provides a clear contrast with building-centric, ground-up field protocols like BACnet. This architectural separation means that while field protocols excel at managing high-frequency local control loops, UDMI introduces the enterprise-grade fleet scalability and uniform management structure required to operate a vast, modern real estate portfolio.

​

Detailed comparison of Modbus, BACnet, OPC UA, Redfish, and UDMI protocols

​

The section provides a detailed comparison of Modbus, BACnet, OPC UA, Redfish, and UDMI protocols, outlining their origins, typical use cases, security postures, compute requirements, and how they fit within industrial and IoT architectures, emphasizing that UDMI operates at a higher device-to-cloud management layer distinct from the field-level protocols and supports fleet management at scale, with each protocol suited to specific environments and device capabilities.

​

​​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

What each protocol actually is

Modbus is the oldest of the four, dating to 1979. It was designed for serial communication between a master device and slave registers on industrial PLCs. It's essentially a simple request/response scheme over RS-232/485 or TCP, with no concept of data types beyond 16-bit registers and coils. Its simplicity is both its greatest strength and its greatest liability.

​

BACnet (Building Automation and Control Networks) was designed in 1987 specifically for HVAC, lighting, and building management systems. It defines a rich object model — over 60 object types — and supports multiple transport layers (IP, MSTP over RS-485, Ethernet). It's the lingua franca of building automation, not industrial manufacturing.

 

OPC UA (Unified Architecture) is the modern, heavyweight entrant, standardized around 2008 as the successor to OPC Classic. It's a full platform-independent, service-oriented architecture with a built-in information model, discovery services, subscriptions, and end-to-end security baked into the spec. It's the choice when you need semantic interoperability across heterogeneous systems.

 

Redfish is the outlier here: it's an HTTPS/REST/JSON API standard from DMTF (2015), designed not for OT/ICS systems at all but for server and data center hardware management — think BMCs (baseboard management controllers), server chassis, power supplies, and storage. It replaced the aging IPMI protocol. It's "adjacent" to SCADA in the sense that it manages physical infrastructure, but it lives in IT/data-center space, not the factory floor.

​

UDMI provides a high-level specification for the management and operation of physical IoT systems, with data typically exchanged with a cloud entity that maintains a "digital twin" or "shadow device." It was originated by Google (now stewarded as open source under faucetsdn on GitHub) and is used heavily in smart building deployments that connect to cloud backends.

​

The key distinction from everything else you've looked at: UDMI is not a wire protocol in the traditional sense. It defines an interface specification rather than a client library or RPC mechanism. The transport is MQTT over TLS, but the protocol's identity lives in its JSON schema and topic structure, not in the wire encoding. This makes it conceptually closer to a cloud API contract than to Modbus or OPC UA. 

​

UDMI strives for a declarative specification — the schema describes the desired state of the system and relies on underlying mechanisms to match actual state to desired state, conceptually similar to Kubernetes-style configuration files. That Kubernetes analogy is apt and important: you declare what you want, and a reconciliation loop figures out how to get there. None of the other four work this way.

 

 

When you'd choose each

You'd choose Modbus when you're integrating legacy hardware that already speaks it, when your edge device is severely resource-constrained, or when polling simple sensor/actuator values over RS-485 is all you need. Essentially every PLC ever made speaks Modbus. You choose it because you have no choice, or because simplicity genuinely wins.

​

You'd choose BACnet when you're in building automation — working with chillers, air handling units, VAV boxes, lighting controllers. It's mandated in many commercial building contracts and understood by virtually every building automation vendor. Its object model maps naturally to HVAC semantics.

​

You'd choose OPC UA when you need cross-vendor semantic interoperability, when you're building a unified data aggregation layer across a factory or smart grid, when you need publish-subscribe rather than just polling, or when security compliance is mandatory (ISA-99/IEC 62443). It's the right choice for greenfield IIoT deployments and for the "IT/OT convergence" layer.

​

You'd choose Redfish when you're managing server hardware — firmware updates, power management, sensor telemetry from a BMC, or hardware inventory in a rack. If you're building edge computing infrastructure and want to manage the compute nodes themselves (not what runs on them), Redfish is the answer.

 

Security posture

Modbus has essentially no security. There's no authentication, no encryption, and no authorization in the base spec. Modbus/TCP is trivially spoofable — anyone on the network can issue commands. Attackers like INDUSTROYER exploited this. Some vendors add a thin TLS wrapper, but it's not standardized and not widely deployed. You mitigate Modbus risks entirely through network segmentation, not the protocol itself.

​

BACnet has a similarly troubled history. BACnet/IP in its original form has no authentication, and BACnet devices are routinely found exposed to the internet via Shodan. BACnet Secure Connect (BACnet/SC), standardized in 2020, finally adds TLS 1.3 and certificate-based authentication, but adoption is slow and many deployed devices will never be upgraded.

​

OPC UA has security as a first-class citizen. It specifies three security modes (None, Sign, SignAndEncrypt), uses X.509 certificates for authentication, and supports message-level encryption independent of transport. The spec also includes an application-layer firewall concept via security policies. In practice, many implementations leave security mode set to "None" for ease of deployment — but the mechanism is there and conformant. The main vulnerabilities found in OPC UA implementations have been implementation bugs (buffer overflows, parser issues) rather than protocol design flaws.

​

Redfish uses HTTPS as its transport, so TLS is inherent. It supports multiple authentication methods: HTTP Basic (deprecated in modern profiles), session-based tokens, and certificate-based mTLS. Role-based access control is built into the spec. The attack surface is more like a web API than an industrial protocol — the risks are classic web vulnerabilities: credential stuffing, SSRF, exposed management interfaces. Because BMCs have privileged hardware access (they can power-cycle servers, flash firmware), a compromised Redfish endpoint is catastrophic.

 

Compute requirements at the edge

This is where the protocols diverge most sharply for embedded/edge deployments.

​

Modbus is the lightest by a large margin. A functional Modbus RTU slave can run in a few kilobytes of Flash and RAM on a bare-metal microcontroller with no OS — we're talking 8-bit AVRs and PIC16s. Modbus/TCP adds a TCP stack, so you need a bit more (typically 32-64 KB RAM minimum for a small TCP/IP stack), but it's still extremely lean. No dynamic memory allocation is required for a well-written implementation.

​

BACnet is heavier than Modbus but still manageable on a Cortex-M3/M4 class device. A minimal BACnet/IP stack (supporting maybe 5-10 object types) typically needs 256 KB–1 MB Flash and 64–256 KB RAM. The object model adds complexity, and MSTP requires precise timing management. BACnet/SC (secure) adds TLS and certificate handling, pushing requirements up toward the 512 KB RAM range minimum.

​

OPC UA is the heavyweight. The full spec is enormous — binary protocol, complex information model, discovery, subscriptions, security. A compliant OPC UA server on an embedded target needs at minimum a 32-bit processor (Cortex-M4 or better), typically 1–4 MB Flash, and 512 KB–4 MB RAM. There are "nano" and "micro" profiles defined for constrained devices, and open-source stacks like open62541 have been optimized to run on Cortex-M3 with ~256 KB RAM in a stripped-down configuration, but you give up features. Realistically, OPC UA belongs on Linux-class edge devices (i.e., something running an RTOS with MMU, or a proper embedded Linux board).

​

Redfish requires an HTTP server, TLS stack, and a JSON parser/serializer. That means you effectively need a Linux-class device or a very capable RTOS on a Cortex-A series processor, with at minimum 32 MB RAM (realistically 64–256 MB). It's not a protocol you implement on a microcontroller — it lives on the BMC (itself typically an ARM SoC running a minimal Linux), or on a management plane processor. If your edge device has a BMC, Redfish is the management interface for the device itself, not for the sensors it talks to.---

​

How they relate to each other in a real architecture

These protocols often coexist in layers. A typical industrial edge deployment might have Modbus RTU at the sensor/actuator layer talking to a gateway, BACnet/IP or OPC UA aggregating multiple gateways into a supervisory layer, and Redfish managing the compute hardware that runs all of it. They're not competitors in that stack — they address different layers.

 

A bottom line if you're making a protocol choice:

If you're on a microcontroller with no OS: Modbus. It's the only realistic option and covers a huge range of industrial sensors.

​

If you're in building automation: BACnet, with BACnet/SC if you have any say in the hardware selection.

​

If you're building a new IIoT platform and have a Linux-class edge device: OPC UA is the right long-term answer. The compute cost is real but the semantic interoperability, security, and pub/sub model pay for themselves at scale.

​

If you're managing the edge compute nodes themselves (not the OT sensors they talk to): Redfish is your management plane protocol — it's simply what BMCs speak now.

​

UDMI is a genuinely different animal from the other four, and understanding where it sits requires reframing the comparison axis slightly.

 

What UDMI actually is

UDMI provides a high-level specification for the management and operation of physical IoT systems, with data typically exchanged with a cloud entity that maintains a "digital twin" or "shadow device." It was originated by Google (now stewarded as open source under faucetsdn on GitHub) and is used heavily in smart building deployments that connect to cloud backends.

​

The key distinction from everything else you've looked at: UDMI is not a wire protocol in the traditional sense. It defines an interface specification rather than a client library or RPC mechanism. The transport is MQTT over TLS, but the protocol's identity lives in its JSON schema and topic structure, not in the wire encoding. This makes it conceptually closer to a cloud API contract than to Modbus or OPC UA.

​

UDMI strives for a declarative specification — the schema describes the desired state of the system and relies on underlying mechanisms to match actual state to desired state, conceptually similar to Kubernetes-style configuration files. That Kubernetes analogy is apt and important: you declare what you want, and a reconciliation loop figures out how to get there. None of the other four work this way.

 

The layer it operates at

This is the most important thing to understand. Modbus, BACnet, and OPC UA are field-level protocols — they define how a controller talks to a sensor or actuator directly, on-premises, typically within a subnet. Redfish manages hardware. UDMI operates at the device-to-cloud management plane. It assumes your device already has an IP connection to the internet (or a cloud-connected gateway), and it defines the schema for how that device reports state, receives configuration, and participates in fleet management.

​

Compliance facets include pointset telemetry for basic telemetry ingestion, writeback control for on-premises device control, gateway proxy for non-MQTT devices, and system basics for general monitoring and logging.

​

In practice, a real deployment might look like: a BACnet or Modbus sensor on the floor → a gateway that translates to UDMI → MQTT over TLS → a cloud IoT broker → a digital twin backend. UDMI doesn't replace BACnet; it sits above it.

 

Transport and tech stack

The complete UDMI specification requires an MQTT broker or bridge, utilizes a defined MQTT topic table, and uses JSON encoding following the core schema definition for the semantic structure of data. Originally designed for Google Cloud IoT Core (which was deprecated in 2023), it now works with ClearBlade IoT Core and any standards-compliant MQTT broker including local Mosquitto deployments.

 

Other transports (non-Google MQTT, CoAP, etc.) are acceptable with prior approval, but MQTT/JSON is the canonical path.

 

Security

UDMI requires a properly secure and authenticated channel from the device to managing infrastructure. MQTT/TLS support requires connection to an MQTT broker with TLS encryption and at least TLS v1.2. Authentication is handled at the MQTT layer, typically via JWT tokens or X.509 device certificates provisioned through the IoT registry. This is meaningfully stronger than Modbus or legacy BACnet by default, though it inherits whatever security posture the MQTT broker and cloud backend provide. Key rotation and credential exchange are first-class use cases in the spec, which no other protocol on this list treats so explicitly.

​

The attack surface is cloud-shaped: the risk is in the MQTT broker, the cloud IAM configuration, and the device certificate provisioning pipeline — not in the field network.

 

Compute requirements

UDMI is moderate. You need a TLS stack, an MQTT client, and a JSON serializer/parser — that's achievable on a Cortex-M4 class device with a good RTOS and ~256 KB RAM, though 512 KB is comfortable. Realistically most UDMI endpoints are either Linux-class gateways aggregating dumber devices, or mid-range embedded SoCs (ESP32-class and up). It's heavier than Modbus, lighter than OPC UA full-stack, and roughly comparable to BACnet/SC.

​

The bigger requirement isn't compute — it's connectivity. UDMI assumes persistent or intermittent internet connectivity. If your edge device is air-gapped or on a purely local fieldbus, UDMI doesn't apply.

 

Fleet management as a first-class concept

This is where UDMI genuinely differentiates. Use cases include key rotation, credential exchange, firmware updates across an entire fleet, on-premises discovery to enumerate devices, commissioning tools, and operational diagnostics. No other protocol on this list treats fleet-scale lifecycle management as a core design concern. OPC UA has a rich information model; BACnet has a detailed object model; but neither has a built-in notion of "push a firmware update to 10,000 devices and track progress." UDMI does.

 

Where it fits in the comparison---

The critical conceptual difference

The other four protocols answer the question: "how do two endpoints on a network exchange data right now?" UDMI answers a different question: "how do I manage a fleet of IoT devices at scale over their entire lifecycle, from commissioning through firmware updates to decommissioning, with a cloud backend maintaining the authoritative view of state?"

​

That distinction means UDMI isn't really competing with OPC UA or BACnet — it's a layer above them. UDMI includes a gateway proxy capability to proxy data and connections for non-UDMI devices, allowing adaptation to legacy systems. So a well-designed deployment uses BACnet or Modbus at the field level, and UDMI to bring that data into a managed cloud architecture.

​

When you'd specifically choose UDMI over just using OPC UA or BACnet with a custom cloud integration: when you need standardized fleet management at scale (hundreds or thousands of devices), when you want a vendor-neutral schema for the cloud layer, when firmware OTA and key rotation need to be automated and auditable, or when you're building a smart building platform that needs to interoperate with multiple integrators who all speak different field protocols underneath.

 

Its weaknesses relative to the others: it's the newest and least mature in terms of ecosystem and tooling; it was originally tightly coupled to Google Cloud IoT Core (now deprecated, creating some migration pain); it requires cloud or at least MQTT broker connectivity, making it unsuitable for air-gapped or purely local deployments; and its adoption outside the Google-sphere smart building world is still limited compared to OPC UA or BACnet.