Skip to Content
Niagara 4What is UDMI?

What Is UDMI? The Universal Device Management Interface for Smart Buildings

UDMI (Universal Device Management Interface) is an open, vendor-neutral schema, first developed by Google, for how building devices report data and are managed over MQTT.

Building owners with large estates, Google among them, found the same problem everywhere: every building's systems spoke different protocols, named points differently and were managed in different ways, so portfolio-wide analytics, digital twins and AI were close to impossible. UDMI is their answer. This guide explains what UDMI is, how it works, how it relates to BACnet, Modbus and semantic standards such as Haystack and BRICK, and how to implement it in a Niagara 4 system with the Tyrrell Products UDMI service.

UDMI in one paragraph

UDMI defines a common structure for messages between building devices (or gateways acting for them) and cloud or on-premises platforms. It covers what a device reports (telemetry, state, events), how it is configured, and how it is discovered and managed. Messages are JSON over MQTT, so they work with standard IoT brokers. UDMI does not replace field protocols such as BACnet and Modbus; it sits on top of them, so data from any building, whatever its underlying systems, arrives in one consistent form.

Why UDMI was created

Operational technology (OT) in buildings lags behind design and construction. During design, BIM and classification standards such as Uniclass, COBie and IFC gave the industry a shared digital language. In operation, buildings still have:

  • proprietary or inconsistent protocols tying owners to manufacturers or integrators
  • fragmented telemetry: temperatures, occupancy and air quality in different formats, naming conventions and systems
  • no standard device management: every vendor provisions, configures and monitors devices differently
  • underused data, because analytics and AI cannot make sense of inconsistent streams

Google developed UDMI to manage IoT devices across its own buildings at scale, and published it as an open specification so the wider industry could adopt it. One of its architects described UDMI as "HTML for building systems": just as HTML gives every web page a structure any browser understands, UDMI gives every building device a structure any platform understands.

What UDMI does

UDMI standardises four things:

1. Communication

A common message format means devices and gateways from different vendors can feed the same platform without custom integration for each one.

2. Device management and provisioning

A consistent process for discovering devices, registering them, pushing configuration and monitoring their health. That is essential when managing thousands of devices across a portfolio.

3. Security and governance

Each device or gateway has an identity and uses authenticated, encrypted connections to the broker, with consistent access rules.

4. A foundation for innovation

With one interface for operational data and control, developers can build analytics, AI and digital twin services once and deploy them across varied buildings.

How UDMI works

UDMI messages flow over MQTT topics between a device (or a gateway representing devices) and a platform. The main message types:

Message Direction Purpose
Pointset telemetry Device → platform Current point values (the readings)
State Device → platform Device status, health, firmware, and acknowledgement of configuration
Config Platform → device Desired configuration, such as which points to report and how often, or setpoint writes
Events Device → platform System events, logs and discovery results
Discovery Both Finding devices and points on underlying networks

Each device has a metadata definition describing what it is and which points it has, which the platform uses to validate messages. UDMI's tooling can validate devices against the schema, which makes conformance testable rather than a matter of opinion.

Because it uses MQTT, UDMI works with cloud IoT platforms and with on-premises brokers. Google originally used Cloud IoT Core; after that service was retired, platforms such as ClearBlade and standard MQTT brokers took its place.

What a UDMI telemetry message looks like

A simplified example of a pointset telemetry message, published by a gateway on behalf of an air handling unit:

{
  "version": "1.5.0",
  "timestamp": "2026-10-03T09:15:00Z",
  "points": {
    "supply_air_temperature_sensor": { "present_value": 18.4 },
    "supply_fan_run_status": { "present_value": true },
    "supply_air_temperature_setpoint": { "present_value": 18.0 }
  }
}

Point names follow the semantic model (here, names in the style of the Google Digital Buildings Ontology), so a platform receiving the same message from any building knows what each value means without a custom mapping. Exact fields depend on the UDMI schema version in use.

UDMI and semantic standards

UDMI defines the structure of data. It does not, on its own, say what a point means. That comes from semantic models:

  • Google Digital Buildings Ontology (DBO): the semantic model used alongside UDMI in Google's own buildings
  • BRICK Schema: describes relationships, for example "this temperature sensor is in this zone, which is served by this air handling unit"
  • Project Haystack: a tagging standard that labels points with machine-readable meaning (for example zone air temp sensor)
  • BDNS (Building Device Naming Standard): consistent naming of devices across systems

To extend the analogy: if UDMI is the HTML, the semantic model is the content. Together with continuous telemetry, they give analytics and AI data that is both consistently structured and consistently understood, which is what makes portfolio-wide fault detection, energy optimisation and digital twins practical.

Niagara 4's tagging and hierarchy features already support Haystack and custom tag dictionaries, which makes it a natural place to apply semantics before data leaves the building.

UDMI and Niagara 4

Most buildings will not replace their BMS to adopt UDMI. The practical route is a gateway that reads existing systems and publishes UDMI-compliant data. Niagara is ideal for this because it already integrates BACnet, Modbus, LonWorks, LoRaWAN and proprietary systems into one normalised point model.

The Tyrrell Products Google UDMI Service for Niagara 4:

  • runs inside a Niagara 4 station on a JACE, IONA or supervisor, supporting Niagara versions 4.10 to 4.15
  • publishes station points as UDMI telemetry and state, and handles UDMI configuration and device management
  • works with any building subsystem integrated into Niagara, not one specific vertical
  • connects to Google-architecture platforms, ClearBlade, or on-premises MQTT brokers
  • supports maintaining a digital twin (shadow device) in the cloud that mirrors the physical devices
  • integrates with Tyrrell Analytics for OT data analytics

It is licensed as a Google UDMI Service base licence with upgrade licences for larger systems. See the UDMI driver category.

Typical architecture

  1. Field devices (BACnet, Modbus, LoRaWAN, legacy systems) are integrated into a Niagara station.
  2. Points are tagged with a semantic model (for example DBO, Haystack or BRICK-aligned tags).
  3. The UDMI service publishes telemetry, state and events to an MQTT broker or cloud platform.
  4. Portfolio analytics, digital twins and AI services consume consistent data from every building.
  5. Configuration and management flow back through UDMI to the station.

Benefits of UDMI for building owners

  • Vendor independence: platforms consume one standard format, not each vendor's API.
  • Portfolio scale: onboarding the hundredth building is the same process as the first.
  • Lower integration cost: analytics and reporting are built once and reused.
  • Better security governance: consistent device identity and authenticated connections.
  • Ready for AI and digital twins: consistently structured and labelled telemetry is the raw material for both.
  • Protects existing investment: existing systems are bridged, not replaced.

UDMI, digital twins and AI

A digital twin is a live digital model of a building: its spaces, systems and equipment, kept up to date with real operating data. Twins are only as good as the data feeding them. UDMI provides the consistent structure; semantic models provide the relationships (which sensor is in which room, which AHU serves which floor); and continuous telemetry keeps the twin current.

With those three in place, a portfolio can run:

  • predictive maintenance, spotting patterns that precede equipment failure
  • real-time optimisation, adjusting HVAC and lighting to occupancy and conditions
  • continuous commissioning, detecting drift from design intent and flagging or correcting it
  • portfolio benchmarking, comparing like-for-like systems across buildings

This is the vision often described as the self-aware building: one that understands how it is meant to perform and notices when it does not. Tyrrell Products works with early adopters and with UDMI's original architects at Google to deliver UDMI interoperability, semantic labelling and OT data analytics towards that goal.

Implementing UDMI: a phased approach

  1. Start with what exists. Integrate current systems into Niagara through gateways and drivers.
  2. Agree a semantic model and naming standard across the estate. This is often the most valuable step, with or without UDMI.
  3. Pilot UDMI on one building, validating messages against the schema and checking the platform receives clean data.
  4. Roll out progressively, adding buildings and systems without disrupting operations.
  5. Train facilities and IT teams in device onboarding, telemetry security and the new analytics tools.
  6. Build analytics and digital twin use cases on the consistent data stream.

Security considerations

Publishing building data to the cloud extends the attack surface of the BMS, so treat a UDMI deployment as an IT project as well as a controls one:

  • use TLS for every MQTT connection and authenticate each gateway with its own credentials or certificate
  • publish outbound only from the building; avoid opening inbound ports to the BMS
  • apply least privilege on the broker so each gateway can only publish and subscribe to its own topics
  • decide which points may be written from the platform through UDMI config, and protect setpoint writes with limits in the station
  • keep Niagara and the UDMI service on supported versions

Questions to ask before adopting UDMI

  1. Which platform will consume the data, and which UDMI version does it support?
  2. Which semantic model will the estate use, and who maintains the naming standard?
  3. Which points are needed? Publishing everything wastes bandwidth and storage.
  4. Will the platform write configuration or setpoints back, or only read?
  5. Who owns device onboarding as buildings change?
  6. How will conformance be tested and monitored?

UDMI vs other approaches

UDMI Vendor cloud API Raw MQTT BACnet/SC
Open standard Yes No Transport only Yes
Defines message structure Yes Vendor-specific No BACnet objects
Device management and config Yes Varies No Limited
Designed for cloud/portfolio scale Yes Yes Depends Mainly on-premises
Semantics Paired with DBO, BRICK, Haystack Varies None BACnet object types

UDMI and BACnet/SC are complementary: BACnet (including Secure Connect) handles control inside the building; UDMI handles structured data and device management between buildings and platforms.

Frequently asked questions

What does UDMI stand for?

UDMI stands for Universal Device Management Interface: an open schema for how building IoT devices report data and are managed, originally developed by Google.

Does UDMI replace BACnet or Modbus?

No. UDMI sits on top of field protocols. BACnet, Modbus and others continue to connect devices inside the building; UDMI standardises how that data is published and managed upwards.

What protocol does UDMI use?

UDMI messages are JSON documents exchanged over MQTT, so they work with cloud IoT platforms and standard on-premises MQTT brokers.

Can Niagara 4 publish UDMI data?

Yes. The Tyrrell Products Google UDMI Service runs in a Niagara 4 station (versions 4.10 to 4.15) and publishes integrated points as UDMI telemetry, state and events.

What is the difference between UDMI and Project Haystack?

UDMI defines the structure and management of device messages; Project Haystack defines tags that describe what data means. They are used together.

Is UDMI free to use?

Yes. UDMI is an open specification with open-source tooling. You pay for the gateways, software and platforms that implement it, such as the Niagara UDMI service licence.

Does UDMI work with LoRaWAN sensors?

Yes, indirectly. LoRaWAN sensor values integrated into a Niagara station become points that the UDMI service can publish like any other.

Who uses UDMI?

UDMI was developed for Google's own building portfolio and is used by owners, integrators and platform providers pursuing standardised, portfolio-scale building data.

Two-factor authenticationWhat is Niagara 4?