IoT Solutions Transition from Proof-of-Concept to Deployment: How Device Agents Enable Critical Device Management Services

Subscribe To Download This Insight

By Abdullah Haider | 4Q 2021 | IN-6301

This insight sheds light on one of the enablers of the IoT market growth: device agents.

Registered users can unlock up to five pieces of premium content each month.

Log in or register to unlock this Insight.


Device Agents are Driving the Rollout of IoT Solutions in the Field


Internet of Things (IoT) solutions are being deployed in many use cases on an increasingly large scale: the number of IoT connections between 2021 to 2026 is forecasted to grow at a CAGR of 22.6%, based on MD-IoTMWW-109. This reflects the expectation that the IoT market is going to continue growing and has yet to reach maturity. This insight sheds light on one of the enablers of this growth: device agents. A critical mass of enterprises, especially larger firms, now possess the ability to securely onboard millions of IoT devices, making IoT solutions scalable and cost-effective. Device agents refers to a piece of middleware which resides on the device (a sensor or gateway). The purpose of the device agent is to allow the client sensor or gateway to communicate with the server of a particular vendor of device management services, such as Azure IoT Hub.  

Why are Device Agents Important for IoT Device Management?


A device agent is a core part of the onboarding process’ value proposition, in which the devices (typically low compute sensors but also higher compute gateways) are connected to a device management platform. The platform manages the lifecycle of the device includes maintenance through Over-the-Air (OTA) updates, as well as sending/receiving data for remote monitoring and diagnostic purposes. Device agent communication can be over Transmission Control Protocol (TCP)-based protocols, such as HTTP or MQTT, enabling device-to-cloud connectivity between client and server. These device agents are critical to any device management service since they enable communication of monitoring and diagnostics data as part of device-to-cloud connectivity. Conversely, cloud-to-device connectivity is enabled by these same device-based agents so that a device can receive information from the cloud server. An example of cloud-to-device connectivity enabled by device agents include FOTA (firmware-over-the-air) updates, which are pushed from the cloud server to the devices in the field. Device agents then play a central role in device-to-cloud and cloud-to-device communication, especially for device management services like onboarding, OTA updates, and for regular transmission of monitoring data.

Device Agents and the Future of IoT Device Management


In the foreseeable future, customer expectations of a plug-and-play IoT solution will only increase, in particular for customers who want a scalable IoT solution and do not want to manually customize each individual sensor prior to field deployment. The main method used to deliver a turnkey solution is to have device agents pre-integrated into the device at the manufacturing stage. This pre-integration takes the form of devices being compliant with a translation protocol like MQTT or LwM2M at the chipset level. For instance, a chipset manufacturer can produce chipsets which are LwM2M compatible. This means that the hardware has a device agent capability built-in which allows for a zero-touch enrollment of the LwM2M client device with a LwM2M server. Also, for cloud suppliers like Microsoft Azure, it is common that device manufacturers release devices which are compatible with a particular cloud supplier’s device manager and provide device agents that typically runs on MQTT instead of LwM2M. Thus, the trend towards a turnkey solution is becoming increasingly pervasive as IoT device management suppliers respond to the expectations of customers.

Another way to ease the onboarding process is possible without having to pre-integrate the IoT sensor in the manufacturing stage. This alternative is to provide an SDK (Software Development Kit) with minimal coding requirements. Previously, the SDKs would provide documentation and a library and customers would have to code their device agents either in-house or by hiring a programmer. Nowadays the number of languages supported has broadened beyond C/C++ and includes Java and Python as well. The SDKs contain a critical tool which simplify the development process, namely Application Programming Interfaces (APIs). An API simplifies the device management onboarding process by providing a microservices architecture, meaning that applications are written not as one big piece of software, but a set of smaller micro-services. And so, these smaller services limit the amount of custom coding required to get a device connected to the cloud—allowing those devices to connect to the cloud which do not have pre-integrated device agents at the point of manufacturing. Therefore, API-based device agents broaden the use of IoT solutions beyond brownfield/legacy deployments and into deployments which contain sensors that are from multiple vendors or sensors which do not provide a pre-integrated device agent in the chipset on a firmware level.

A further change in expectations is the role of security, as customers expect solutions not just to be secured, but also to be have secure device management services at a relatively affordable cost and expect it to function on small footprint devices which have low computing power. TPMs (Trusted Platform Modules) possess these qualities, the device agent such as Azure IoT DPS (Device Provisioning Service) can onboard devices and perform provisioning activities based on a TPM root of trust. Device agents are a vital link for TPMs and secure root of trust as device agents enable and perform a secure onboarding process between the TPM device and the cloud server by performing device identity and attestation functions. So, device agents address not just operational (routine use) of device management services but also security aspects of device management services, such as the use of TPMs for secure device onboarding.

To summarize, IoT deployments are becoming increasingly pervasive in the field, and moving a solution from proof-of-concept to deployment has become possible with a simplified device management process. This simplified process has happened in large part due to device agents becoming pre-integrated/natively built-in or easier to program (via APIs) for onboarding, thus making the solution plug-and-play. Transitioning towards a turnkey solution means IoT solutions move one step closer to field deployment by making onboarding of millions of devices possible and the IoT solution scalable. Many players have contributed to the development of plug-and-play solutions which has led to scalability in the field. These players are device Original Equipment Manufacturers (OEMs) and chipset manufacturers who have provided pre-integrated devices into a cloud supplier’s device manager is based on the MQTT specification, and LwM2M-compliant chipsets for other suppliers. Of course, OMA (Open Mobile Alliance) which designed LwM2M in the first place was a key part of enabling plug-and-play solutions through their open standard too.