The device agent is shared as an open source project in this repo.
Microsoft Azure provides scalable and secure cloud services that enable device management for a large number of devices. The services act as the cloud infrastructure connecting operators to devices.
As shown in the diagram, to have an end-to-end solution, the following components need to be present:
- A cloud infrastructure.
- A device agent to connect various components on the physical device to the cloud services.
- A cloud solution to present the various cloud services in a format suitable for the operator scenario.
The cloud infrastructure is provided by Azure. You can read about the various services here:
Both the device agent and the cloud solution can be implemented by using the Azure SDKs provided for the above mentioned services. However, given the commonality of many of their functions, there are multiple offerings that can give a head start.
The Cloud Solution can be built using the Azure SDKs or an existing solution by Microsoft or a third party can be adopted and extended to meet the specific needs and scenarios of the operator.
Microsoft provides two options:
For the device agent, Microsoft provides a ready-to-build open source solution that:
- Manages the device identity provisioning with IoT Hub.
- Manages the cloud connection and its renewal.
- Provides a plug-in model for platform components which allows easy onboarding to various Azure services. This model includes discovery, initialization, error reporting, and state aggregation.
- Comes with a set of ready-to-ship plug-ins for very commonly used platform components.
The device agent can run on both the Windows IoT Core SKU and the Windows IoT Enterprise SKU. More information can be found on the Supported SKUs page.
The device agent is shared as an open source project in this repo.
See the Servicing page.
The Device Agent is designed so that it can co-operate with other applications running on the device that need a connection to IoT Hub.
The Device Agent can be assigned the role of provisioning the device for all applications (by retrieving/generating connection strings for all of them). Or, it can be told to just wait for the device to be provisioned - which allows other provisioning clients to be used.
If a provisioning client other than the integrated one with the device agent is to be used, the provisioning client must be able to assign multiple connection strings to different slots in the TPM, so that the device builder can designate which slot the device agent needs to read its connection string from as well as which slots the other applications will read from.
If DPS provisioning is to be used,
- The Edge Runtime has its own integrated client and it support the above requirement (i.e. cannot provision other applications).
- The device agent has its own integrated client and it meets the requirements, however, the Edge Runtime does not support waiting for another provisioning client.
As a result, DPS provisioning for a device that has both the device agent and the Edge Runtime is not currently supported. We are working with the Edge Runtime team on supporting this scenario.
If you are using the device management client iot-core-azure-dm-client and would like to read how it relates to the new client and how to migrate, check out Migration from Old MSIoT DM Client page.