The Universal Device Management Interface (UDMI) provides a high-level specification for the management and operation of physical IoT systems. This data is typically exchanged with a cloud entity that can maintain a "digital twin" or "shadow device" in the cloud.
- Core UDMI documentation for tools and specifications
- Message schema definition with (🧬Interactive Viewer)
- [email protected] email discussion list
- Bi-weekly UDMI Discuss video meeting open to all (join the mailing list to get an invite)
By design, this schema is intended to be:
- Universal: Apply to all subsystems in a building, not a singular vertical solution.
- Device: Operations on an IoT device, a managed entity in physical space.
- Management: Focus on device management, rather than command & control.
- Interface: Define an interface specification, rather than a client-library or RPC mechanism.
See the associated UDMI Tech Stack for details about transport mechanism outside of the core schema definition. Nominally meant for cloud-based MQTT-bridge providers, it can also work locally with standard docker-hosted local MQTT brokers.
The recommended workflow for UDMI covers using the registrar and validator tools to configure and test a cloud project. Additionally, the pubber tool is instrumental in setting up and testing the system independent of actual device setup.
The essence behind UDMI is an automated mechanism for IoT system management. Many current systems require direct-to-device access, such as through a web browser or telnet/ssh session. These techniques do not scale to robust managed ecosystems since they rely too heavily on manual operation (aren't automated), and increase the security exposure of the system (since they need to expose these management ports).
UDMI is intended to support a few primary use-cases:
- Telemetry Ingestion: Ingest device data points in a standardized format.
- Gateway Proxy: Proxy data/connection for non-UDMI devices, allowing adaptation to legacy systems.
- On-Prem Actuation: Ability to effect on-prem device behavior.
- Device Testability: e.g. Trigger a fake alarm to test reporting mechanisms.
- Commissioning Tools: Streamline complete system setup and install.
- Operational Diagnostics: Make it easy for system operators to diagnose basic faults.
- Status and Logging: Report system operational metrics to hosting infrastructure.
- Key Rotation: Manage encryption keys and certificates in accordance with best practice.
- Credential Exchange: Bootstrap higher-layer authentication to restricted resources.
- Firmware Updates: Initiate, monitor, and track firmware updates across an entire fleet of devices.
- On-Prem Discovery: Enumerate any on-prem devices to aid setup or anomaly detection.
All these situations are conceptually about management of devices, which is conceptually different than the control or operation. These concepts are similar to the management, control, and data planes of Software Defined Networks. Once operational, the system should be able to operate completely autonomously from the management capabilities, which are only required to diagnose or tweak system behavior.
In order to provide for management automation, UDMI strives for the following principles:
- Secure and Authenticated: Requires a properly secure and authenticated channel from the device to managing infrastructure.
- Declarative Specification: The schema describes the desired state of the system, relying on the underlying mechanisms to match actual state with desired state. This is conceptually similar to Kubernetes-style configuration files.
- Minimal Elegant Design: Initially underspecified, with an eye towards making it easy to add new capabilities in the future. It is easier to add something than it is to remove it.
- Reduced Choices: In the long run, choice leads to more work to implement, and more ambiguity. Strive towards having only one way of doing each thing.
- Structure and Clarity: This is not a "compressed" format and not designed for very large structures or high-bandwidth streams.
- Property Names:Uses snake_case convention for property names.
- Resource Names: Overall structure (when flattened to paths), follows the API Resource Names guidelines.
UDMI provides a means to multiplex multiple functional subsystems through the same shared communication channel. There are a number of subsystems that make up the core UDMI spec:
- Core system messages about the base device itself.
- Device pointset for device telemetry organized by points.
- Optional gateway functionality for proxying device/MQTT connections.
- Local discover for discovering device and network capabilities.
Schemas are broken down into several top-level sub-schemas that are invoked for different aspects of device management:
- Device metadata (example) stored in the cloud about a device, but not directly available to or on the device, defined by metadata.json. This is essentially a specification about how the device should be configured or expectations about what the device should be doing.
- Message envelope (example) for server-side attributes of received messages, defined by envelope.json. This is automatically generated by the transport layer and is then available for server-side processing.
- Streaming device telemetry, which can take on several different forms, depending on the intended use, e.g.:
- Device state (example), sent from device to cloud, defined by state.json. There is one current state per device, which is considered sticky until a new state message is sent. is comprised of several subsections (e.g. system or pointset) that describe the relevant sub-state components.
- Device config (example), passed from cloud to device, defined by config.json. There is one active config per device, which is considered current until a new config is received.
A device client implementation will typically only be aware of the state, config, and one or more telemetry messages (e.g. pointset), while all others are meant for the supporting infrastructure.
An interactive view of the schema is available at gencode/docs/.
Using UDMI on a project entails not only the base device and server implementations, but also properly registering and validating device configuration. The registrar tool and validator tool provide a means to configure and check site installations, respectively.