IoT Concepts

Before going into details with Azure IoT Edge, Let’s do a quick review of some IoT Concepts.

IoT applications or solutions can be described as Things (or devices), sending data or events that are used to generate Insights. These insights are used to generate Actions to help improve a business or process. An example is an engine (a thing), sending pressure and temperature data that is used to evaluate whether the engine is performing as expected (an insight), which is used to proactively prioritize the maintenance schedule for the engine (an action).

To implement an IoT solution the Azure IoT platform provides you with multiple services and different capabilities. We will have IoT devices (also known as downstream devices), which will have their own identity. The device identity is generated by registering the device into Azure IoT Hub. You can register devices into IoT Hub manually, or at scale by using the Device Provisioning Service. Devices use their identity to authenticate and communicate with IoT hub. Devices (usually) send telemetry, have properties which describe their state, and respond to commands which correspond to their capabilities. The devices have their properties stored in a device twin in the device registry. Let’s have a detailed review of the previous IoT concepts:

  • Azure IoT Hub: Azure IoT Hub is a managed service hosted in the cloud that acts as a central message hub for communication between an IoT application and its attached devices. You can connect millions of devices and their backend solutions reliably and securely. Almost any device can be connected to an IoT hub.

  • Device Provisioning Service (DPS): The IoT Hub Device Provisioning Service (DPS) is a helper service for IoT Hub that enables zero-touch, just-in-time provisioning to the right IoT hub without requiring human intervention. DPS enables the provisioning of millions of devices in a secure and scalable manner.

  • IoT Device: Virtual or physical IoT devices (things) differ from other clients such as browsers and mobile apps, specifically, they are often embedded systems with reduced or no human operator, can be deployed in remote -often inaccessible- locations, might only be reachable through the solution back-end, might have limited power and processing resources, usually have attached some sensors, might have intermittent, slow, or expensive network connectivity and might need to use proprietary, custom or industry-specific application protocols.

  • IoT Edge Device: And edge device is a special type of device that usually provides dedicated edge computing capabilities such as data pre-processing and analysis, offline capabilities, bandwidth consumption optimization, etc. Azure IoT Edge provides a device-focused runtime that enables you to deploy, run, and monitor containerized Linux workloads. IoT Edge devices are also downstream devices from the point of view of IoT Hub.

  • Downstream device: A downstream device can be any application or platform that has an identity created with the Azure IoT Hub cloud service. In many cases, these applications use the Azure IoT device SDK. A downstream device could even be an application running on the IoT Edge gateway device itself. In the context of the IoT Edge and transparent gateways, the downstream devices that connects to IoT Hub thru IoT Edge are sometimes called leaf devices or child devices.

  • Device Identity Registry and Authentication: Every IoT Hub has an identity registry that stores information about the devices and modules permitted to connect to it. Before a device or module can connect, there must be an entry for that device or module in the IoT hub’s identity registry. A device or module authenticates with the IoT hub based on credentials stored in the identity registry.

    The IoT Hub supports two methods of authentication between the device and the IoT Hub: SAS token-based authentication or X.509 certificate authentication.

  • Device Communication: IoT Hub uses Transport Layer Security (TLS) to secure connections from IoT devices and services. Three versions of the TLS protocol are currently supported, namely versions 1.0, 1.1, and 1.2. TLS 1.0 and 1.1 are considered legacy and are planned for deprecation.

    Typically, IoT devices send telemetry from the sensors to back-end services in the cloud. However, other types of communication are possible, such as a back-end service sending commands to your devices.

  • Device Telemetry: Examples of telemetry received from a device can include sensor data such as speed or temperature, an error message such as missed event, or an information message to indicate the device is in good health. IoT devices send events to an application to gain insights. Applications may require specific subsets of events for processing or storage at different endpoints.

  • Device Properties: Properties can be read or set from the IoT hub and can be used to send notifications when an action has been completed. An example of a specific property on a device is temperature. Temperature can be a writable property that can be updated on the device or read from a temperature sensor attached to the device.

  • Device Commands: An example of a command is rebooting a device. IoT Hub implements commands by allowing you to invoke direct methods on devices. Direct methods represent a request-reply interaction with a device similar to an HTTP call in that they succeed or fail immediately (after a user-specified timeout). This approach is useful for scenarios where the course of immediate action is different depending on whether the device was able to respond.

  • Device Twins: Device twins are JSON documents that store device state information including metadata, configurations, and conditions. Azure IoT Hub maintains a device twin for each device that you connect to IoT Hub, no matter if it is an edge device or a regular one.

  • Desired Properties and Reported Properties: Are used to synchronize device configuration or conditions, the solution backend can set the desired properties and the device software can read them or receive notifications of its changes; once the device software synchronizes its state with the desired properties, the device set the reported properties accordingly, so the solution backend can read them or received the notifications.

    For further information, see Understand Azure IoT Hub device twins | Microsoft Learn

  • Module Twins: In IoT Hub, under each device identity, you can create up to 50 module identities. Each module identity implicitly generates a module twin. Like device twins, module twins are JSON documents that store module state information including metadata, configurations, and conditions. Azure IoT Hub maintains a module twin for each module that you connect to IoT Hub, no matter if it is an edge device or a regular one.

    For further information, see Understand Azure IoT Hub module twins | Microsoft Learn

  • D2C and C2D: These acronyms are widely used in IoT Solutions context. D2C refers to the communications originated at the devices which flows to the cloud (usually device telemetry or device reported properties), while C2D follows the contrary path, that is, communications originated at the cloud which flows to the devices (usually representing device commands or device desired properties).

Also, do not hesitate to review our Glossary of IoT Terms.