The dos and don'ts of device management solution implementation

The dos

Getting devices onboard and managed is the first step in deploying IoT services. However, companies continue to relegate device management functions to a secondary thought.

First and foremost, you must formulate a plan and work with your device providers to be fully compliant with the standard you are going to use. Often times, a device claims to be fully compliant but doesn’t satisfy interoperability tests. Interoperability testing and standard compliance testing will ensure you don’t hit glitches once the devices are deployed onto the network.

Given IoT vendors are at various stages of supporting industry standards, compliance testing is critical to ensure project progresses on schedule. LwM2M automated testing platforms are available as well as device client firmware development SDKs.

Device firmware management is a major component of a device management platform. Being able to execute firmware over-the-air at a massive scale requires IoT service planners to consider the following:

• Correct communications between the targeted devices and the management server.
• Secure transfer of update files onto devices, timing of downloading files by devices and scheduling updates for them.

Here, LwM2M makes it easy for you. The standard offers a well-defined firmware update process. It also helps to let the management server select the right moment to start file transmission and inform the device when it’s time to install updates. It provides standardized protocol for device management, while also enabling enough extensibility to enable device-specific proprietary features.

The protocol’s framework enables users to consider up-front requirements, desired data structures and features, and ensure that the devices can perform well not only in PoC, but at production volume as well.

One of the major benefits of this standard is its offering of well-defined data models. LwM2M provides a light but secure communication interface with an efficient data model, representing specific service profiles such as connectivity monitoring, temperature readings or firmware updates.

With a strictly defined data model, it helps to reduce interoperability problems. The protocol’s data model provides easily accessible and reusable semantics for both device management and application data, according to OMA. The Internet Protocol for Smart Objects Alliance provides an open, reusable Object Model. Users can access, contribute or define their own objects.

The don’ts

Today, most of the commonly available LwM2M SDKs on the market are vendor-specific, resulting in a single device operating correctly only with a chosen platform. As a result, compatibility becomes problematic. Many IoT implementations rely on messaging protocols such as MQTT, and users can run into this exact problem. It’s worth noting that, despite being an open protocol, MQTT does not standardize any conventions for communicating device management operations such as configuration changes, telemetry data format or the mentioned firmware updates.

Everyone can define an entirely different format of messages to be sent to or received from devices. It creates an iron cast between device agent and management platform, making switching among vendors a major problem and adding to huge costs.

IoT providers should consider choosing an open and industry standard-based platform. This means that devices, including their underlying structures and semantics, can be ported from one platform to another. It also means that the data structure developed for one vendor’s device can be re-used across a competitive vendor’s device. Reducing single vendor lock-in helps the entire ecosystem grow.

All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.