The Unified UDMI Functional Interface (UUFI) defines a standardized messaging mechanism for external applications (the Client) to integrate with a UDMI-managed system (the System). UUFI serves exclusively as an external-facing, application-side interface to UDMI, enabling management and control of devices.
As an external interface specification, this document focuses solely on the public-facing contract: the exchange message formats, connectivity schemas, and the tools available to start or stop test environments. It does not expose or document the underlying system internals or implementation mechanisms (such as process IDs, internal databases, or local host execution steps), which are treated as private implementation details.
This document details the application-facing Applications (UUFI) interface, which represents one of three core system interfaces into the UDMIS ecosystem:
events) and dynamically receive or acknowledge operational config.registrar) to manage site models, provision cryptographic keys, and reconcile device records.UUFI utilizes a messaging transport where Clients and Systems interact via dedicated topics and subscriptions.
UUFI interfaces use a URL-like connection string format. Supported schemes: mqtt://, mqtts://, and pubsub://.
Format: scheme://[user@]host[:port][/path]
unknown@ character is required if a user is specified.pubsub://)principal attribute.user component with a trailing @ (e.g., user@).udmi_uufi).{topic}+{user}.principal attribute matches the local identity or is absent.:port is prohibited.pubsub:// transport is managed out-of-band using standard Cloud IAM and Application Default Credentials (ADC). The connection string specifies the project and topic routing coordinates, whereas credential resolution is a transport-level prerequisite.mqtt://, mqtts://)mqtts:// scheme, or secure ports like 8883):
mqtts:// with the same routing, parsing, and topic mapping rules as mqtt://, differing only in the enforcement of SSL/TLS.[/{prefix}]/uufi/[r/{deviceRegistryId}/[d/{deviceId}/]]c/{subType}/{subFolder}
subType) and a subfolder (subFolder) segment without exception. Topic paths MUST be formatted strictly as [/{prefix}]/uufi/c/{subType}/{subFolder} (for common channels) or [/{prefix}]/uufi/r/{deviceRegistryId}/d/{deviceId}/c/{subType}/{subFolder} (for registry/device scoped channels). Omitting the subfolder segment or truncating suffixes (e.g. /c/{subType}) is strictly prohibited."udmi". Thus, the handshake topics MUST be exactly [/{prefix}]/uufi/c/state/udmi and [/{prefix}]/uufi/c/config/udmi.[/{prefix}]/uufi/p/{principal}/...) and any other custom or arbitrary routing hierarchies are strictly prohibited. All system components MUST standardize exclusively on the common and registry-scoped topic channels to ensure interoperability.prefix MUST be used to isolate different environments sharing the same broker. If provided, it MUST be the leading part of the topic path (e.g. matching all segments of the path provided in the connection string). Implementations MUST support multi-segment prefixes and MUST NOT omit the prefix if provided in the connection string. All active subscriptions MUST be scoped to the provided prefix to ensure environmental isolation. Prefix enforcement MUST be strict: implementations MUST NOT publish to or subscribe from topics outside their designated prefix tree. To avoid collisions and support standard broker authorization structures, implementations MUST construct unique MQTT Client IDs adhering to a standardized format:
[/{prefix}]/{registry_id}/{client_id}. If the registry is unknown or not applicable, the Client ID MUST be formatted as [/{prefix}]/{client_id}._sess123 or a secure random nonce) to the formatted Client ID.projectId field in the envelope SHOULD be treated as a general environment or project identifier. All components within a single UUFI session MUST use a consistent projectId (default: vibrant) to avoid ambiguity in message processing.query/system message to [/{prefix}]/uufi/r/{deviceRegistryId}/d/{deviceId}/c/query/system.[/{prefix}]/uufi/r/{deviceRegistryId}/d/{deviceId}/c/model/system.schema/model_system.json payloads addressed via device-scoped envelope attributes and topic paths (Section 5.1).query/state message to [/{prefix}]/uufi/r/{deviceRegistryId}/d/{deviceId}/c/query/state.[/{prefix}]/uufi/r/{deviceRegistryId}/d/{deviceId}/c/state/blobset (or the corresponding state topic matching the query’s subFolder).transactionId. The resulting state response envelope MUST copy this exact transactionId in its envelope metadata. If no response is received within 15 seconds, the Client SHOULD consider the state query timed out.[/{prefix}]/uufi/r/{deviceRegistryId}/d/{deviceId}/c/events/pointset.[/{prefix}]/uufi/r/{deviceRegistryId}/d/{deviceId}/c/events/discovery.schema/events_pointset.json or schema/events_discovery.json) nested within the standard payload key for MQTT or the root of the message data object for PubSub.[/{prefix}]/uufi/r/{deviceRegistryId}/d/{deviceId}/c/events/status.schema/entry.json, containing category, level, message, and optionally timestamp.transactionId from the preceding client message to enable exact error correlation.To ensure compatibility with MQTT topic parsing structures and PubSub attribute indexing, all identifier strings utilized in UUFI connection coordinates and paths MUST conform to the following character and length restrictions:
{deviceRegistryId}) and Device IDs ({deviceId}) MUST contain only uppercase and lowercase alphanumeric characters, hyphens (-), and underscores (_)./), backslashes (\), wildcards (+, #), and special punctuation characters are strictly prohibited.Handshake is Client-initiated. The System MUST NOT initiate a handshake unless acting as a Client.
The handshake has a 60-second timeout. On timeout, the Client should handle the failure and retry or fail-fast.
The UUFI interface separates network-level presence mapping from device-level operational control. Every component on the bus operates across two logical protocol layers:
To guarantee deterministic state transitions on shared handshake channels:
/uufi/c/state/udmi and publishes responses on /uufi/c/config/udmi./uufi/c/state/udmi.All active application-layer clients (such as orchestrators, parsers, or compliance verifiers) MUST execute their own Layer 1 Service Handshake upon initialization. This ensures that:
For any client initializing on the bus, the handshake sequence MUST follow the Request-Reply pattern below:
[ Client Entity ] [ The Service ]
│ │
│─── (1) Handshake Request (state/udmi) ────────────────────►│
│ Topic: [/{prefix}]/uufi/c/state/udmi │
│ Envelope: │
│ - transactionId: "UUID-A" │
│ - principal: "{implementation_id}.{entity_suffix}" │
│ Payload: │
│ - setup: { "transaction_id": "UUID-A" } │
│ │
│◄── (2) Handshake Config Reply (config/udmi) ───────────────│
│ Topic: [/{prefix}]/uufi/c/config/udmi │
│ Envelope: │
│ - transactionId: "UUID-A" (Symmetric Match) │
│ - source: "udmis" │
│ - principal: "{implementation_id}.{entity_suffix}" │
│ Payload: │
│ - setup: { "deviceRegistryId": "testing" } │
│ - reply: { "transaction_id": "UUID-A" } │
▼ ▼
To prevent packet collisions and support trace correlation across shared handshake channels:
transactionId value from the incoming request envelope directly into the transactionId field of the outgoing reply envelope.transactionId does not match its original request’s transactionId.transactionId across subsequent configurations and states to support end-to-end correlation.To guarantee parsing interoperability and avoid protocol timeouts, Handshake payloads and correlation MUST strictly adhere to the following rules:
"setup" payload block MUST reside directly at the payload root of the message (i.e. the root of the inner UDMI state payload). Nested or wrapped formats (e.g., nesting "setup" under a "udmi" key or any other custom outer wrapper) are strictly prohibited."reply" payload block (along with the optional/mandatory "setup" block) MUST reside directly at the payload root of the message. Wrapping under a "udmi" root sub-object or any other custom outer wrapper is strictly prohibited.Transaction Correlation:
To ensure reliable request-response correlation on shared handshake channels (e.g., /uufi/c/config/udmi), the handshake configuration reply message’s envelope MUST include a "transactionId" attribute matching the exact transaction ID from the client’s handshake request envelope. Receivers MUST validate this correlation and reject mismatched responses.
functions_ver):
The functions_ver integer specified under the setup payload block represents the supported functional capability set of the client/system interface. If the System’s maximum supported version is lower than the Client’s requested version, the System MUST respond with its highest supported version in the Step 2 reply. Clients MUST gracefully handle this negotiation and determine whether to operate in fallback/degraded mode or terminate the session based on the negotiated functions_ver.The Client publishes a UDMI state message to /uufi/c/state/udmi.
setup directly at the root (see Appendix A.1.1).source in envelope contains Client identity.The System publishes a UDMI config message to /uufi/c/config/udmi.
setup and reply directly at the root (see Appendix A.1.1.a and A.1.2.a).principal MUST match Client’s identity (the static identity of the external application entity endpoints of the communication session). For handshake replies, the System MUST use the principal or source from the received state message to ensure the reply reaches the correct client. If the received message has a principal, it SHOULD be used; otherwise, the source SHOULD be used as a fallback. Senders MUST NOT set principal to "uufi" or a server instance ID. For broadcast messages with no specific receiver, principal MUST be left blank. The System MUST set source to "udmis" on outgoing messages for loopback prevention.Retries: The Client SHOULD periodically republish the Step 1 state message (e.g., every 5 seconds) if a valid Step 2 confirmation has not been received, until the 60-second timeout.
Activation: The Client is Active when reply.transaction_id matches the original state.setup.transaction_id.
defaultdeviceRegistryId in the config.udmi handshake reply to the Client. To ensure interoperability, the deviceRegistryId SHOULD be placed within the setup block of the payload. The Client SHOULD use this deviceRegistryId for all subsequent registry-scoped topics. The System MUST NOT expect to discover its own deviceRegistryId from Client-initiated handshakes. To prevent collisions in multi-registry environments where device IDs may not be globally unique, the Client identity (source in envelope and msg_source in setup payload) SHOULD be a structured identifier in the format {registry_id}/{device_id} if the client already has knowledge of its designated registry. Otherwise, if the registry is unknown, the Client identity is the bare {device_id}, and the System will assign a default registry ID (e.g., default). (Note: Use deviceRegistryId camelCase exactly as specified; case-insensitive or snake_case matching is NOT guaranteed).All messages are wrapped in a UUFI Envelope.
Inner JSON payload object MUST include:
timestamp: RFC 3339 (minimal precision).version: UDMI schema version.| Transport | Envelope Location | Payload Location |
|---|---|---|
| PubSub | Message Attributes | Message Data (JSON) |
| MQTT | JSON Wrapper | Payload payload key |
subType, subFolder, and when applicable deviceRegistryId, deviceId) within the JSON envelope payload object across all transport mechanisms. The envelope structure MUST be identical across both MQTT and PubSub transports. For MQTT transport, omitting any of these mandatory envelope header fields from the JSON payload object, or providing envelope fields that conflict with the topic path coordinates, MUST be treated as a validation error, and the message MUST be rejected and ignored.subType, subFolder, deviceRegistryId, deviceId, projectId, transactionId, publishTime, source, principal, and payload).subType, subFolder, deviceRegistryId, deviceId, projectId, transactionId, publishTime, source). If any required envelope fields are omitted from the JSON payload wrapper, or if they fail to match the topic path attributes, the receiver MUST reject and ignore the message.payload key.To ensure protocol compatibility, data integrity, and protection against replay attacks, the following metadata policies are codified for UUFI message envelopes and payloads:
Envelope Nonce Attribute:
To support message deduplication and replay protection, clients and devices publishing state, event, or model messages SHOULD include a "nonce" field in the envelope’s root containing a secure, pseudorandomly generated hexadecimal string (minimum 32 characters, e.g., 16 bytes of entropy).
All receivers MUST gracefully accept, parse, and process envelopes containing the "nonce" attribute without throwing schema errors or dropping the messages.
Configuration Version Attribute:
All configuration envelopes (at the envelope metadata level) and their inner payloads (at the payload root level) MUST include a standard "version" attribute matching the UDMI version schema (e.g., "1.5.2").
Receivers MUST parse and validate this version attribute to guarantee protocol compatibility. Any configuration message that lacks this attribute or contains an invalid or unparseable version schema MUST be treated as non-compliant, rejected immediately, and failed.
READ, CREATE, UPDATE, DELETE, BIND, UNBIND."registries" or "devices") inside the payload. Instead, the registry ID and device ID MUST be specified strictly as message attributes (envelope level) or MQTT topic path segments:
[/{prefix}]/uufi/r/{deviceRegistryId}/d/{deviceId}/c/model/systemdeviceRegistryId and deviceId (along with subFolder set to "system" and subType set to "model" or "query").schema/model_system.json schema representing only the specified device."registries", "devices", or "system" root key inside the JSON payload) are strictly prohibited./uufi/c/config/system or any other unscoped/registry-less topics is strictly prohibited.The UPDATE operation for the system subfolder is a partial merge at the device subsystem level. Existing fields not in the payload MUST NOT be modified.
To configure a device’s expected or desired software subsystem version, implementations MUST adhere to exactly ONE standard schema:
system.software.<subsystem> = "{version}" (where <subsystem> defaults to "system").system.target_version or system.software_target) are strictly prohibited and MUST NOT be accepted.To report a device’s actual or currently running software subsystem version, implementations MUST adhere strictly to the standard UDMI schema:
system.software.<subsystem> = "{version}".version property under blobset.blobs.<subsystem_id>) is strictly prohibited.| UDMI Operation | Envelope subType |
Envelope subFolder |
Direction | Note |
|---|---|---|---|---|
| Handshake State | state |
udmi |
Publish | Standard flat format (Step 1) |
| Handshake Config | config |
udmi |
Receive | Standard flat format (Step 2) |
| Config Update | config |
varies | Publish | |
| State Event | state |
varies | Receive | |
| Telemetry | events |
pointset |
Receive | |
| Discovery | events |
discovery |
Receive | |
| System Model Query | query |
system |
Publish | Registry and device-scoped |
| System Model Update | model |
system |
Publish | Registry and device-scoped |
| System Model Reply | model |
system |
Receive | Registry and device-scoped |
| State Query | query |
state |
Publish | |
| Blobset Config | config |
blobset |
Publish | |
| Blobset State | state |
blobset |
Receive |
transactionId for message identification.transactionIds for 5 minutes.payload object contains the fields of the UDMI message corresponding to the subFolder and subType.blobset config and state payloads, data MUST be nested within a subsystem-id key (e.g., system) to support multi-subsystem devices. Subsystem nesting is strictly required for all UUFI-compliant messages; unnested (flat) payloads are not supported.timestamp and version MUST be at the root of the payload object.make and model fields are mandatory for all blobset subfolder payloads (state and config) within the subsystem nesting.url field in a blobset config payload MUST be a valid URI. Implementations MUST support absolute and relative path mapping using the file:// scheme, as well as inline payloads using the data: scheme:
file:///var/tmp/bundle.bin), the scheme is stripped and resolved as an absolute path (e.g., /var/tmp/bundle.bin).file://relative/path/bundle.bin), the scheme is stripped and resolved as a path relative to the designated application or site-model root.data: scheme (e.g., data:text/plain;base64,MS4xLjA= or data:application/json;base64,...), implementations MUST parse the MIME-type and decode the trailing base64 segment (the portion immediately following ;base64,) to retrieve the raw bytes.2026-05-01T22:32:17Z).Z suffix).current_version, target_version, etc.) MUST NOT be null. If a version is unknown, use a placeholder string like "0.0.0". Implementations MUST treat "0.0.0" as an uninitialized or lower-precedence state; a non-zero version string MUST NEVER be overwritten by "0.0.0" during automated synchronization.make and model, if the value is unknown or uninitialized, implementations SHOULD use "unknown" as a standard fallback value.subType, subFolder, deviceRegistryId, deviceId) inside the JSON payload object wrapper. The JSON envelope structure MUST be identical across MQTT and PubSub transports. If an incoming MQTT message omits these envelope fields from the JSON payload or if they mismatch the topic path parameters, it MUST be rejected as an error./. Implementations MUST NOT accept or publish to topics lacking the leading slash.This section specifies how external client developers (working outside the UDMI project codebase) can set up a local testing environment to build and verify custom UUFI Client implementations against a running System and Device Under Test (DUT).
bin/start_local)To initialize the local System stack (Mosquitto broker, etcd, and UDMIS control plane), execute the local startup script with a designated target site model directory and connection spec:
bin/start_local [site_model_dir] //mqtt/localhost:$port
Example:
bin/start_local sites/udmi_site_model //mqtt/localhost:46432
//mqtt/localhost:$port to ensure correct port parsing and target identification by the local environment.kill/pkill commands. To stop the local system infrastructure, execute bin/start_local stop. Re-executing bin/start_local automatically stops and cleans up any existing background instances before starting fresh.Upon successful startup, the local environment exposes the following connection parameters:
mqtt://localhost:46432 (or ssl://localhost:46432 for mTLS)rocket, Password monkeysites/udmi_site_model/reflector/ca.crtsites/udmi_site_model/reflector/rsa_private.crtsites/udmi_site_model/reflector/rsa_private.pembin/start_dut)To emulate a managed device executing commands and reporting telemetry over UUFI, launch the DUT (Pubber) process targeting the site model and connection endpoint:
bin/start_dut <site_model_dir> //mqtt/localhost:$port [device_id] [serial_no]
Example:
bin/start_dut sites/udmi_site_model //mqtt/localhost:46432 AHU-1 uufi-serial
// (e.g. //mqtt/localhost:$port). Omitting // or passing explicit schemes like mqtts:// is not supported for local test execution and will result in a connection configuration error.AHU-1 (or specified device ID) with serial number uufi-serial and begins standard message exchange between the DUT and the local System.stop subcommand with the target serial number:
bin/start_dut stop <serial_no>
bin/start_dut with the serial number of an active DUT automatically stops the existing instance before launching the new process.bin/registrar)Prior to test execution, the database synchronization step must be executed using the standard registrar tool in full online mode:
bin/registrar <site_model_dir> //mqtt/localhost:$port
Example:
bin/registrar sites/udmi_site_model //mqtt/localhost:46432
metadata_norm.json, populates generated_config.json, and initializes tagabase entries for simulated devices.bin/site_trigger)To trigger automated database mutations or field updates during testing, execute bin/site_trigger using explicit connection syntax:
bin/site_trigger update <site_path> <device_id> <blob_id> <version> //mqtt/localhost:$port
Example:
bin/site_trigger update sites/udmi_site_model AHU-1 system 1.0.0 //mqtt/localhost:46432
//mqtt/localhost:$port syntax as the final argument to target custom ports correctly.Successfully updated expected version of system to '1.0.0' in sites/udmi_site_model/devices/AHU-1/metadata.json.
Publishing model/system update to /uufi/r/ZZ-TRI-FECTA/d/AHU-1/c/model/system...
Model update message triggered successfully.
[/{prefix}]/uufi/r/{deviceRegistryId}/d/{deviceId}/c/model/system (for example, /uufi/r/ZZ-TRI-FECTA/d/AHU-1/c/model/system). The published MQTT payload contains the standard envelope metadata and the flat schema/model_system.json structure:
{
"projectId": "vibrant",
"transactionId": "TXN-a1b2c3d4",
"publishTime": "2026-07-24T06:57:00Z",
"source": "site_trigger",
"payload": {
"version": "1.5.2",
"timestamp": "2026-07-24T06:57:00Z",
"software": {
"system": "1.0.0"
}
}
}
To tear down or stop running test infrastructure and DUT simulations in isolated or non-privileged environments, use the provided high-level tool commands:
bin/start_local stop
bin/start_dut stop <serial_no>
//mqtt/localhost:<port>).UDMI_NO_SUDO is deprecated. Instead, any port specification other than system-default ports (or any explicit port for local execution) automatically instructs all scripts to run in user-space.systemctl). Instead, the broker is started as a local user background process utilizing configuration and log directories located inside the local workspace relative to the UDMI root.This appendix references the formal JSON schemas and provides message examples for the UUFI protocol. The UDMI Schema Repository is the authoritative source for all message structures.
Attributes:
{
"subFolder": "udmi",
"subType": "state",
"transactionId": "UUFI:sess123:001",
"source": "client-id",
"principal": "client-id@"
}
Data:
{
"version": "1.5.2",
"timestamp": "2026-04-29T10:00:00Z",
"setup": {
"functions_ver": 9,
"transaction_id": "UUFI:sess123:001",
"msg_source": "client-id"
}
}
Attributes:
{
"subFolder": "udmi",
"subType": "config",
"transactionId": "UUFI:sess123:001",
"source": "system-id",
"principal": "client-id@"
}
Data:
{
"version": "1.5.2",
"timestamp": "2026-04-29T10:00:05Z",
"setup": {
"functions_ver": 9,
"transaction_id": "UUFI:sess123:001",
"msg_source": "client-id"
},
"reply": {
"transaction_id": "UUFI:sess123:001"
}
}
Topic: /uufi/c/state/udmi
Payload:
{
"subType": "state",
"subFolder": "udmi",
"projectId": "vibrant",
"transactionId": "UUFI:sess123:001",
"publishTime": "2026-04-29T10:00:00Z",
"source": "client-id",
"principal": "client-id",
"payload": {
"version": "1.5.2",
"timestamp": "2026-04-29T10:00:00Z",
"setup": {
"functions_ver": 9,
"transaction_id": "UUFI:sess123:001",
"msg_source": "client-id"
}
}
}
Topic: /uufi/c/config/udmi
Payload:
{
"subType": "config",
"subFolder": "udmi",
"projectId": "vibrant",
"transactionId": "UUFI:sess123:001",
"publishTime": "2026-04-29T10:00:05Z",
"source": "system-id",
"principal": "client-id",
"payload": {
"version": "1.5.2",
"timestamp": "2026-04-29T10:00:05Z",
"setup": {
"functions_ver": 9,
"transaction_id": "UUFI:sess123:001",
"msg_source": "client-id"
},
"reply": {
"transaction_id": "UUFI:sess123:001"
}
}
}
Attributes:
{
"subFolder": "pointset",
"subType": "config",
"transactionId": "UUFI:sess123:002",
"source": "client-id",
"principal": "client-id@",
"deviceRegistryId": "reg-1",
"deviceId": "dev-1"
}
Data:
{
"version": "1.5.2",
"timestamp": "2026-04-29T10:05:00Z",
"points": {
"temp": { "set_value": 22.5 }
}
}
Topic: /uufi/r/reg-1/d/dev-1/c/config/pointset
Payload:
{
"subType": "config",
"subFolder": "pointset",
"deviceRegistryId": "reg-1",
"deviceId": "dev-1",
"transactionId": "UUFI:sess123:002",
"principal": "client-id",
"payload": {
"version": "1.5.2",
"timestamp": "2026-04-29T10:05:00Z",
"points": {
"temp": { "set_value": 22.5 }
}
}
}
Attributes:
{
"subFolder": "blobset",
"subType": "config",
"transactionId": "UUFI:sess123:003",
"source": "client-id",
"principal": "client-id@",
"deviceRegistryId": "reg-1",
"deviceId": "dev-1"
}
Data:
{
"version": "1.5.2",
"timestamp": "2026-04-29T10:10:00Z",
"blobset": {
"blobs": {
"system": {
"phase": "apply",
"url": "file:///path/to/bundle.bin",
"sha256": "abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890",
"generation": "2026-04-29T10:10:00Z"
}
}
}
}
Topic: /uufi/r/reg-1/d/dev-1/c/config/blobset
Payload:
{
"subType": "config",
"subFolder": "blobset",
"deviceRegistryId": "reg-1",
"deviceId": "dev-1",
"transactionId": "UUFI:sess123:003",
"principal": "client-id",
"payload": {
"version": "1.5.2",
"timestamp": "2026-04-29T10:10:00Z",
"blobset": {
"blobs": {
"system": {
"phase": "apply",
"url": "file:///path/to/bundle.bin",
"sha256": "abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890",
"generation": "2026-04-29T10:10:00Z"
}
}
}
}
}
Attributes:
{
"subFolder": "system",
"subType": "model",
"transactionId": "UUFI:sess123:004",
"source": "orchestrator",
"principal": "orchestrator",
"deviceRegistryId": "reg-1",
"deviceId": "dev-1"
}
Data:
{
"version": "1.5.2",
"timestamp": "2026-04-29T10:15:00Z",
"software": {
"system": "2.1.0"
}
}
Topic: /uufi/r/reg-1/d/dev-1/c/model/system
Payload:
{
"subType": "model",
"subFolder": "system",
"deviceRegistryId": "reg-1",
"deviceId": "dev-1",
"projectId": "vibrant",
"transactionId": "UUFI:sess123:004",
"publishTime": "2026-04-29T10:15:00Z",
"source": "orchestrator",
"principal": "orchestrator",
"payload": {
"version": "1.5.2",
"timestamp": "2026-04-29T10:15:00Z",
"software": {
"system": "2.1.0"
}
}
}
UUFI implementations MUST adhere to the following schemas from the UDMI repository:
| UUFI Component | Authoritative UDMI Schema |
|---|---|
| Message Envelope | schema/envelope.json |
| Handshake State | schema/state_udmi.json |
| Handshake Config | schema/config_udmi.json |
| System Model | schema/model_system.json |
| Blobset Config | schema/config_blobset.json |
| Blobset State | schema/state_blobset.json |