Fundamentals of IoT device management
Four fundamental device management requirements exist for any Internet of Things (IoT) device deployment: provisioning and authentication, configuration and control, monitoring and diagnostics, and software updates and maintenance. Here, each of these are defined.
Once an Internet of Things (IoT) device is installed, it is not a “fire and forget” scenario. There will be bug fixes and software updates needed; some devices will fail and need to be repaired or replaced; and each time this happens your company is on the hook to minimize downtime – not only to keep your customers happy, but to ensure that you protect your revenue stream.
How do you ensure this? By designing thoughtful device management into your product. Any IoT system must address four fundamental categories of device management, which are:
- Provisioning and authentication
- Configuration and control
- Monitoring and diagnostics
- Software updates and maintenance
This article summarizes each of these categories, while a follow-up piece covers specific implementations and delves into certain commercial device management products.
Provisioning and authentication
According to IDC, the number of Internet-connected devices is expected to reach 30 billion by 2020. Many device manufacturers are largely inexperienced in matters of security, and attacks from the hacking of Foscam security cameras to remotely attacking connected Jeeps have already been widely publicized.[2, 3] Recently, Rob Joyce, the NSA’s lead hacker, said the IoT is an excellent way to attack a target because devices provide a way of entering a network that are often overlooked by sysadmins.
Device authentication is the act of securely establishing the identity of the device to ensure that it can be trusted. A cloud-hosted service that the device connects to needs to know that the device is actually a genuine device, is running trusted software, and is working on the behalf of a trusted user.
Provisioning is the process of enrolling a device into the system. Authentication is part of that process, where only devices that present the proper credentials are registered. The exact details of this process can vary widely based on implementation. However, in most applications, the device being deployed is loaded with a certificate or key (stored in a secure memory area) that identifies it as authentic, and knows the server URL to connect to in order to enroll itself. When the device is first plugged in and connected to the local network, it “calls home,” and then, based on the credentials and other information such as the model and serial number of the device, it might receive further configuration data.
Configuration and control
Unless you are a glutton for punishment and want to preconfigure every device you ship with the specifics as to where it will be installed and how it will be used, you’ll be shipping a device with some sort of generic configuration. Most of the time, your device will need to be further configured by the end user with attributes such as its name and location and application-specific settings.
In a fleet-management example, a device is used to track the location and certain on-vehicle telemetry and report that information back to the cloud via a cellular connection. Certain parameters will need to be written once the device is installed, such as the unique ID of the trailer or truck (perhaps the license plate or VIN number). Other configuration settings, such as the amount of time between sending position messages, are also determined and programmed into the device.
To implement certain control capability into a system, you’ll want to remotely reset the device so as to achieve a known-good state and recover from errors and implement new configuration changes. You may also want to be able reset the device to a factory default configuration, which is useful when you want to decommission a device or as a more invasive way to recover from unknown error conditions. Lastly, issuing a command to update or reload firmware is very important in order maintain security of the remote device, implement feature enhancements, and patch bugs.
Monitoring and diagnostics
In a system of thousands of remote devices, the smooth and secure operation of each device can directly affect the financial bottom line. Small issues can impact customer sentiment enough to hamper successful business outcomes. Monitoring and diagnostics are vital to minimize the impact of any device downtime due to software bugs or other unforeseen operational problems.
As an example, you can detect when something is amiss by monitoring compute, storage, networking, and I/O statistics at the task or process level, and comparing those statistics to characterized nominal values. If the CPU utilization goes up to 60 percent in a process that would normally consume 5 percent, then that gives troubleshooters another data point that make identifying the bug much faster. Monitoring network statistics can also indicate possible security breaches.
Being able to download program logs and dumps is also imperative to diagnosing and solving software bugs. After all, you aren’t going to be able to travel to the devices to debug them in-person with a serial terminal! The application developer must implement good program logging, while device management software must make that information available for upload when an error occurs. Taking that one step further, device management software might also use cloud-hosted analytics software to provide useful insights into problems that occur across multiple connected devices.
Software maintenance and update
You may not think so, but you will release software with bugs in it; you will want to add features and functionality to it; and, yes, you will deploy devices with security vulnerabilities. Because this is not key value-adding functionality, it is viewed as an afterthought (just like documentation!) to most product developers, especially startup companies who are trying to get quickly to market. However, this is one of the most important aspects of device management – it is absolutely essential to securely update and maintain remote device software.
So, what does this mean? There are a lot of potential levels to software maintenance. On one level, you must have a process to completely and securely update all the device software, including bootloaders and binary blobs. You might use this to fix a security vulnerability that pervades the platform firmware. To fix application bugs or add simple feature enhancements and save network bandwidth, you may just want to update the main running application software without touching the platform firmware.
Software maintenance in remote devices is a long-term, running process. You may not have a persistent connection to a remote device if, for example, the device communicates via a wireless connection. The link may not be reliable, especially if the device is moving, or if there is a consumption cost involved in the data connection (for example, via cellular), then the link might be established only periodically to save cost. Finally, one of the main reasons software updates are complicated is that you need to perform them when there is minimal business impact.
Let’s go back to the fleet management example. Let’s say that you’ve had to make a change to the software to fix a bug that just requires an update of the main task or application. Trucks travel through pockets of persistent cellular connectivity, so they may not be on the network all the time. In addition, you wouldn’t want to schedule the update while the truck was moving and giving you the telemetry data that you need. You would schedule the update when the operator (in other words. the truck driver) was resting and when it was reliably connected to the network.
Conclusion and thoughts
These are the fundamental functions of remote device management: provisioning and authentication, configuration and control, monitoring and diagnostics, and software updates and maintenance. All of these functions are fundamental and critical to the success of any IoT implementation.
Unfortunately, there is a major drawback – none of these functions adds much differentiating value to your product. They are analogous to the power supply or the compute subsystem – fundamental yet uninteresting to the end user. Thus these features tend to not get much focus at the front end of product design, which is where it belongs. Development teams have to have a core belief that, without good device management, they are putting the fate of the product on the line. Not only that, but by having it they also ensure a great customer experience and maximum uptime and device security.
It takes a great deal of work to build this functionality from scratch. Imagine needing to create the capability to schedule a full operating system (OS) image download and install with error checking and failover in case the update was unsuccessful. There are commercial options for device management, with Microsoft Windows 10 IoT is one example. Given the Microsoft fits seamlessly into many existing enterprise deployments, device management is built into Windows 10 IoT. Wind River Helix Device Cloud integrates much more than just device management is another interesting commercial offering.
In a future article, I hope to explore these offerings in greater details.
1. IDC: Worldwide Internet of Things Forecast, 2015–2020
2. “Hacker hijacks wireless Foscam baby monitor, talks and freaks out nanny.“ http://www.computerworld.com/article/2878741/hacker-hijacks-wireless-foscam-baby-monitor-talks-and-freaks-out-nanny.html
3. “Hackers Remotely Kill a Jeep on the Highway—With Me in It” www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/
4. “NSA Hacking Chief: Internet of Things Security Keeps Me Up at Night “ https://www.technologyreview.com/s/546251/nsa-hacking-chief-internet-of-things-security-keeps-me-up-at-night/