Every THING is Internet of Thing

Azure IoT Edge Overview

 
  • Akhilesh Moghe
  • Jan 24, 2022
  • Azure IoT Edge runtime operates as Gateways, providing a connection between other IoT devices on the network and IoT Hub.
  • IoT Edge hub module acts like IoT Hub so can handle connections from other devices that have an identity with the same IoT hub.

Decision Criteria for using IoT Edge:

  • Near real-time response to local changes:
    • If your application needs to react quickly to local changes in near real time.
    • IoT Edge can run modules locally on IoT Edge devices to enable faster response to local changes.
  • Deploy and manage Edge Application using Containers:
    • If your application needs to be deployed in docker compatible containers to IoT Edge devices.
    • IoT Edge enables you to use containers to run your logic at the IoT Edge. Containers help to manage software dependencies such as runtimes and libraries, ensuring that the application runs consistently wherever it’s deployed.
  • Secure Edge deployments:
    • The lack of security for IoT devices is a significant barrier to entry for many enterprises.
    • IoT Edge provides security in several ways. These include integrating with Azure Security Center and by making use of any hardware security modules to provide strong authenticated connections for confidential computing.
  • Offline or intermittent operations:
    • If your application needs to operate with intermittent offline connectivity.
    • IoT Edge devices automatically synchronize the latest state of your devices once they've reconnected to the cloud to ensure seamless operations.
  • AI and analytics workloads on Edge:
    • If you need to run machine learning algorithms on IoT Edge devices.
    • IoT Edge enables you to deploy models built and trained in the cloud and run them on IoT Edge devices.
  • Optimize data costs:
    • Management of costs in the deployment of Cloud resources is essential.
    • You can design your system in such a way that data sent to the cloud is reduced by pre-processing on the IoT Edge devices.
  • Privacy and compliance for Edge deployments:
    • If you need to ensure compliance for Privacy regulations.
    • IoT Edge can protect personally identifiable data and keep data on-premises in that way improving compliance.

IoT Edge Gateway Patterns:

  • The transparent and translation gateway patterns are not mutually exclusive.

Transparent Gateway Pattern:

  • This type of gateway pattern is called transparent because messages can pass from downstream devices to IoT Hub as though there were not a gateway between them.
  • For devices that theoretically could connect to IoT Hub can connect to a gateway device instead.
  • These downstream devices have their own IoT Hub identity.
  • Both the devices and the users interacting with them through IoT Hub are unaware that a gateway is mediating their communications. This lack of awareness means the gateway is considered transparent.
  • You declare transparent gateway relationships in IoT Hub by setting the IoT Edge gateway as the parent of a downstream device child that connects to it.
  • Child devices can only have one parent.
  • Each parent can have up to 100 children.
  • IoT Edge devices can be both parents and children in transparent gateway relationships. The top node of a gateway hierarchy can have up to five generations/layers of children.
  • Gateway Discovery:
    • hostname of Edge Gateway
    • IP Address of Edge Gateway
  • Secure Connection:
    • Parent and child devices also need to authenticate their connections to each other.
    • Uses a shared root CA certificate which the child devices use to verify that they are connecting to the proper gateway.

Translation Gateway Pattern:

  • For devices that can't connect to IoT Hub on their own, IoT Edge gateways can provide that connection.
  • IoT Edge device has to perform processing(~like JSON to string conversions for MCUs) on incoming downstream device messages before they can be forwarded to IoT Hub.
  • Devices that don’t have the capability to connect to IoT Hub on their own can connect to a gateway device instead.
  • This pattern is required for devices that don't support MQTT, AMQP, or HTTP.

Pattern Illustration with Protocol vs Identity Translation:

edge-as-gateway-translation

Protocol vs Identity Translation

Capability Protocol translation pattern Identity translation pattern
Identities
(stored in the IoT Hub identity registry)		 Only the identity of the gateway device Identities of all connected devices
Device twin Only the gateway has a device and module twins Each connected device has its own device twin
Direct methods
and
cloud-to-device messages		 The cloud can only address the gateway device The cloud can address each connected device individually
IoT Hub throttles and quotas Applies to the gateway device Applies to each device
  Only use this pattern when few devices are connecting through each field gateway, and their cloud-to-device traffic is low,
as the cloud-device queue is only for 50 messages for all devices behind the gateway.		  

IoT Edge Agent:

  • IoT Edge agent is the first runtime component to start on any IoT Edge device.
  • Make sure that any downstream, nested IoT Edge devices can access the edgeAgent module image when they start up, and then they can access deployments and start the rest of the module images.

IoT Edge Runtime Installation & Update:

  • Supported Tools, Platforms:
    • container runtime:
      • moby-engine (default)
      • Docker – can be used but not recommended as Microsoft will not provide any fixes for this.
    • OS:
      • Ubuntu Server 18.04 (Tier1)
      • Raspberry Pi OS Stretch (Tier1)
      • Ubuntu 18.04, 20.04 (Tier2)
      • Yocto (Tier2)
      • Debian (Tier2)
  • IoT Edge Runtime is provided as an APT Packages:
    • aziot-edge:
      • IoT Edge service provides and maintains security standards on the IoT Edge device.
      • The service starts on every boot and bootstraps the device by starting the rest of the IoT Edge runtime.
    • aziot-identity-service:
      • IoT identity service handles the identity provisioning and management for IoT Edge and for other device components that need to communicate with IoT Hub.
    • moby-engine:
      • Container runtime
  • We can use Device Update for IoT Hub service which provides APT package-based updates.
  • IoT Edge runtime is like Kubernetes running on a single node, it ensures that the modules are always running and report module health to the cloud.
  • Furtther References:

Updating Nested Edge Gateway or IoT device Containerized Applications:

Docker registry module:

  • Docker registry module can be deployed on the IoT Edge gateway at the top layer of a gateway hierarchy.
  • This module is responsible for retrieving and caching container images on behalf of all the IoT Edge devices in lower layers.

A local container registry module:

  • The alternative to deploying this module at the top layer is to use a local registry, or to manually load container images onto devices and set the module pull policy to never.

API proxy module:

  • The API proxy module is required on any IoT Edge gateway that has another IoT Edge device below it. That means it must be on every layer of a gateway hierarchy except the bottom layer.
  • This module uses an nginx reverse proxy to route HTTP data through network layers over a single port.
  • It is highly configurable through its module twin and environment variables, so can be adjusted to fit your gateway scenario requirements.
  • Route container image pulls for nested IoT Edge devices and IoT devices
    • The same mechanism should be usable for IoT leaf devices

Azure Blob Storage on IoT Edge:

  • The Azure Blob Storage on IoT Edge can be deployed on the IoT Edge gateway at the top layer of a gateway hierarchy.
  • This module is responsible for uploading blobs on behalf of all the IoT Edge devices in lower layers.
  • The ability to upload blobs also enables useful troubleshooting functionality for IoT Edge devices in lower layers, like module log upload and support bundle upload.
  • Further Reference: Azure-Samples/azure-iotedge-blobstorage-sample

ML model deployment to Edge Gateway:

IoT Edge Security:

IoT Edge Security Manager:

  • Workload API:
    • The workload API is accessible to all modules.
    • It provides proof of identity, either as an HSM rooted signed token or an X509 certificate, and the corresponding trust bundle to a module.
      • The trust bundle contains CA certificates for all the other servers that the modules should trust.
  • The IoT Edge module runtime uses an attestation process to guard this API.
    • When a module calls Workload API, the module runtime attempts to find a registration for the identity.
    • If successful, it uses the properties of the registration to measure the module.
    • If the result of the measurement process matches the registration, a new proof of identity is generated.
    • The corresponding CA certificates (trust bundle) are returned to the module.
  • The module uses this certificate to connect to IoT Hub, other modules, or start a server.
  • When the signed token or certificate nears expiration, it’s the responsibility of the module to request a new certificate.

IoT Edge Certificates:

Client Server Communication between Edge – to – Edge and Edge – to – end IoT device:

Azure IoT Edge MQTT Broker:

Azure Event Grid on Azure IoT Edge:

  • Purposed for Reactive, Event Driven Programming
  • Service Type: Event Distribution (discrete)
  • Usage: React to status changes
  • Use Event Grid on IoT Edge to trigger simple workflows between modules.
    • For example, create a topic and publish events like “storage blob created” from your storage module to the topic. You can now subscribe one or several functions or custom modules to that topics.
  • Extend your functionality between edge devices.
  • Store and Forward mechanism:
    • Event Grid on IoT Edge module handles routing, filtering, and reliable delivery of events at scale.
    • Retry logic makes sure that the event reaches the target destination even if it’s not available at the time of publish.
    • It allows you to use Event Grid on IoT Edge as a powerful store and forward mechanism.
  • Event Sources:
    • Azure Blob Storage on IoT Edge
    • CloudEvents sources
    • Custom modules & containers via HTTP POST
  • Event Handlers:
  • Concepts:
    • Events — What happened.
    • Event sources — Where the event took place.
    • Topics — The endpoint where publishers send events.
    • Event subscriptions — The endpoint or built-in mechanism to route events, sometimes to more than one handler. Subscriptions are also used by handlers to intelligently filter incoming events.
    • Event handlers — The app or service that reacts to the event.
  • References:

Monitoring and Troubleshooting for Azure IoT Edge (metrics-collector module):

  • Measure metrics like message latencies and throughput; both between local modules and Upstream communication.
    • Upstream can be ingestion into the Azure IoT cloud or the parent IoT Edge device in a nested configuration.
  • Right-size your hardware by analyzing resource consumption data at both workload and host level.
  • Integrate information from custom modules.
  • Monitor locked-down/nested gateway assets/devices
    • In a nested edge configuration where the lower level devices are completely locked down and can only communicate upstream with their parent IoT Edge device.
    • Monitoring this critical edge infrastructure has been a challenge.
      • A solution can be configured to transport metrics using IoT message telemetry path using the IoT Edge Hub.
      • This path enables monitoring data from assets deep in your network to securely and seamlessly make its way up to the cloud.
  • iotedge-logging-and-monitoring-solution
    • Leverages IoT Edge Agent’s built-in functionality to retrieve logs.
    • Logging architecture reference
    • Monitoring architecture reference
    • Monitor alerts architecture reference
  • Integration with Azure Monitor in Azure Cloud:
    • monitor both your edge and cloud resources with a unified dashboard.
    • Azure Monitor Log Analytics allows you to create alert rules at a resource group or subscription level. These broadly-scoped alert rules can be used to monitor IoT Edge devices from multiple IoT Hubs.
  • Integrated the on-demand log pull feature of the IoT Edge runtime right into the Azure Monitor Portal for quick and easy troubleshooting.
    • Pull logs on-demand, automatically adjusted to the time range of interest.

metrics-collector module:

Retrieve Logs from IoT Edge devices/gateways without SSH or Physical access:

Further Readings

References
Search