UDMI / Docs / Specs / Connecting
There’s a number of different ways that an IoT device can be connected to the cloud. The “right” choice will depend on the specific devices and overall system architecture. This document describes the major models available in the UDMI world.
Abstractly, the goal is to connect on-prem devices with their cloud-based representations. In between there’s various bits of stuff that facilitate that connection.
On-prem Cloud
/---*---\
[D1]---| |---[D1]
| stuff |
[D2]---| |---[D2]
\---*---/
D1 and D2 in the diagram)
* in the diagram)
To achieve the basic abstract end-result above, there’s a number of different models that can be employed, depending on the particular device capabilities. For the most part, the result should be the same (as indicated in the abstract case), and if not then it’s a red flag for the result.
In some cases, devices can speak direct to the cloud. This requires that they have properly implemented a MQTT driver with proper UDMI message formatting. This capability is present in many “modern” devices available, and is the general gold-standard since it minimizes the overall number of system components.
On-prem Cloud
[D1]----*----[D1]
[D2]----*----[D2]
The adapter case, the end device itself doesn’t understand MQTT/UDMI, but is
fronted by an adapter (D1') of some kind that translates from whatever the end
device (D1) speaks. From UDMI’s perspective, there is no sense or awareness
of the connection between D1 and D1' (it could be IP, RS485, or even
RFC1149).
On-prem Cloud
[D1][D1']--*----[D1]
[D2][D2']--*----[D2]
For systems that have multiple devices that can be reached by a network of
some kind (IP or otherwise, RFC1149 probably does not apply), an
IoT Gateway can provide the same result with reduced overhead.
The gateway device (G1) exists both on-prem and is represented in the cloud,
but is transparent for end-to-end operation of the system.
On-prem Cloud
[D1]-\ /--[D1]
[G1]-*-[G1]
[D2]-/ \--[D2]
The degenerate case of a singleton (only one device) system could still use a gateway construct; however, this is ultimately less elegant since there is extra configuration and overhead required. In this case, the adapter model is preferred as it’s overall more clean (but a gateway would still be functionally correct). Many devices can be configured to be either an adapter or a gateway, so it might be the same hardware but different software setup.
On-prem Cloud
[D1]--[G1]-*-[G1]---[D1]
The aggregator model is essentially a “poor-man’s gateway” in that it has the same on-prem architecture but is treated differently in the cloud. In this case, all the data points from all the devices are aggregated together into one payload, using point-name encodings to differentiate points on the receiving end. The fundamental problem with this architecture is that it will not be able to support some back-end UDMI features that rely on devices being mapped as logical entities on the cloud end. This case is sometimes (unfortunately) required by limitations in some implementations, but is not considered UDMI compliant.
On-prem Cloud
[D1]-\
[A1]----------[A1]
[D2]-/