udmi

UDMI / Docs / Specs / Message Walk

Illustrative Message Walk

This document details a high-level overview of the path a message takes as it works its way through the UDMI framework. It is not a detailed how-to, but rather an overview guide of the various bits and pieces. This generally assumes a reasonable working knowledge of the individual components involved, which typically have more detailed documentation elsewhere.

Site Model

The UDMI Site Model provides an abstract model for what the site should look like. Specifically, it holds information used by other tools to do things relating to the device.

Pubber

Pubber is a reference device that can pretend to be any device as listed in the UDMI site model. It’s important for system testing to isolate the setup from anything external. Usually, if Pubber doesn’t work then there’s something wrong with the code or GCP configuration, otherwise it indicates a problem with the real/actual device.

IoT Core

IoT Core is the externally-facing endpoint for on-prem devices. It organizes a particular device into a { project, registry } grouping. The important configuration parameters for a given registry are the Default telemetry and Device state topic types, which should be set to udmi_target and udmi_state, respectively.

PubSub Topics

PubSub is used as the primary communication mechanism for messages in the GCP project. Note that PubSub uses the term topics in a way that is similar to, but semantically different than, an MQTT topic. Same word, roughly same meaning, different contexts. There are four main PubSub topics used by the UDMI system for various functions:

• udmi_target: Primary topic for device communication, including the main telemetry publish events. but also, e.g., augmented state messages, config, etc… Subscribing to this topic should give a reasonably complete stream of all device-related traffic.
• udmi_state: Interstitial topic used for augmenting incoming state messages with aux information, followed by a simple re-publish to the udmi_target topic. No need to pay much attention to this one.
• udmi_config: Used for processing incremental config message updates. I.e., for a given subblock such as pointset, this will process it appropriately so that it is combined into a complete top-level config block.
• udmi_reflect: Used internally by the reflection capability (see below). Not something to pay much attention to.

Cloud Functions

The first set of Cloud Functions handle the ingest traffic from a device. The source code for these functions can be published to the cloud project by the udmis/deploy_udmis_gcloud command (see below).

• udmi_target: Central handling of all messages.
• udmi_state: Processes incoming device state messages and re-writes them to the udmi_target topic.

Validator

The UDMI Validator tool monitors a device’s message stream and validates messages that it sees against the UDMI schema. There are a variety of configurations used, depending on the overall intent.

Sequence Validator

The UDMI Sequence Validator tool monitors a sequence of messages from a device’s stream and validates that the composition of sequential messages is compliant with the UDMI Schema.

This site is open source. Improve this page.