Examine device configuration best practices

Completed

Understanding device configuration best practices can be instrumental to the successful implementation of automatic device management. Best practices apply to the following roles:

  • IoT hardware manufacturer/integrator: Manufacturers of IoT hardware, integrators assembling hardware from various manufacturers, or suppliers providing hardware for an IoT deployment manufactured or integrated by other suppliers. Involved in development and integration of firmware, embedded operating systems, and embedded software.
  • IoT solution developer: The development of an IoT solution is typically done by a solution developer. This developer may be part of an in-house team or a system integrator specializing in this activity. The IoT solution developer can develop various components of the IoT solution from scratch, or integrate various standard or open-source components.
  • IoT solution operator: After the IoT solution is deployed, it requires long-term operations, monitoring, upgrades, and maintenance. These tasks can be done by an in-house team that consists of information technology specialists, hardware operations and maintenance teams, and domain specialists who monitor the correct behavior of the overall IoT infrastructure.

IoT hardware manufacturer/integrator

The following are best practices for hardware manufacturers and integrators dealing with embedded software development:

  • Implement device twins: Device twins enable synchronizing desired configuration from the cloud and for reporting current configuration and device properties. The best way to implement device twins within embedded applications is through the Azure IoT SDKs. Device twins are best suited for configuration because they:
    • Support bi-directional communication.
    • Allow for both connected and disconnected device states.
    • Follow the principle of eventual consistency.
    • Are fully queriable in the cloud.
  • Structure the device twin for device management: The device twin should be structured such that device management properties are logically grouped together into sections. Doing so will enable configuration changes to be isolated without impacting other sections of the twin. For example, create a section within desired properties for firmware, another section for software, and a third section for network settings.
  • Report device attributes that are useful for device management: Attributes like physical device make and model, firmware, operating system, serial number, and other identifiers are useful for reporting and as parameters for targeting configuration changes.
  • Define the main states for reporting status and progress: Top-level states should be enumerated so that they can be reported to the operator. For example, a firmware update would report status as Current, Downloading, Applying, In Progress, and Error. You can define more fields if you need more information on each state.

IoT solution developer

The following are best practices for IoT solution developers who are building systems based in Azure:

  • Implement device twins: All of the benefits for using listed for the manufacturer also apply to the solution developer.
  • Organize devices using device twin tags: The solution should allow the operator to define quality rings or other sets of devices based on various deployment strategies such as canary. Device organization can be implemented within your solution using device twin tags and queries. Device organization is necessary to allow for configuration roll outs safely and accurately.
  • Implement automatic device configurations: Automatic device configurations deploy and monitor configuration changes to large sets of IoT devices via device twins.

Automatic device configurations target sets of device twins via the target condition, which is a query on device twin tags or reported properties. The target content is the set of desired properties that will be set within the targeted device twins. The target content should align with the device twin structure defined by the IoT hardware manufacturer/integrator. The metrics are queries on device twin reported properties and should also align with the device twin structure defined by the IoT hardware manufacturer/integrator.

Automatic device configurations run for the first time shortly after the configuration is created and then at five-minute intervals. They also benefit from the IoT Hub performing device twin operations at a rate that will never exceed the throttling limits for device twin reads and updates.

  • Use the Device Provisioning Service: Solution developers should use the Device Provisioning Service to assign device twin tags to new devices, such that they will be automatically configured by automatic device configurations that are targeted at twins with that tag.

IoT solution operator

The following are best practices for IoT solution operators who using an IoT solution built on Azure:

  • Organize devices for management: The IoT solution should define or allow for the creation of quality rings or other sets of devices based on various deployment strategies such as canary. The sets of devices will be used to roll out configuration changes and to perform other at-scale device management operations.
  • Perform configuration changes using a phased roll-out: A phased roll-out is an overall process whereby an operator deploys changes to a broadening set of IoT devices. The goal is to make changes gradually to reduce the risk of making wide scale breaking changes. The operator should use the solution's interface to create an automatic device configuration and the targeting condition should target an initial set of devices (such as a canary group). The operator should then validate the configuration change in the initial set of devices.

Once validation is complete, the operator will update the automatic device configuration to include a larger set of devices. The operator should also set the priority for the configuration to be higher than other configurations currently targeted to those devices. The roll-out can be monitored using the metrics reported by the automatic device configuration.

  • Perform rollbacks if there were errors or misconfigurations: An automatic device configuration that causes errors or misconfigurations can be rolled back by changing the targeting condition so that the devices no longer meet the targeting condition. Ensure that another automatic device configuration of lower priority is still targeted for those devices. Verify that the rollback succeeded by viewing the metrics: The rolled-back configuration should no longer show status for untargeted devices, and the second configuration's metrics should now include counts for the devices that are still targeted.