IoT 中心设备重新预配概念IoT Hub Device reprovisioning concepts

在 IoT 解决方案的生命周期中,设备在 IoT 中心之间频繁移动。During the lifecycle of an IoT solution, it's common to move devices between IoT hubs. 此项移动的原因可能包括以下情况:The reasons for this move may include the following scenarios:

  • 地理位置/GeoLatency:当设备在两位置之间移动时,通过将设备迁移到更近的 IoT 中心来改善网络延迟。Geolocation / GeoLatency: As a device moves between locations, network latency is improved by having the device migrated to a closer IoT hub.

  • 多租户:可以在同一 IoT 解决方案中使用设备并将其重新分配给新客户或客户站点。Multi-tenancy: A device may be used within the same IoT solution and reassigned to a new customer, or customer site. 可使用不同的 IoT 中心为这位新客户提供服务。This new customer may be serviced using a different IoT hub.

  • 解决方案更改:可将设备移到新版或更新后的 IoT 解决方案中。Solution change: A device could be moved into a new or updated IoT solution. 这种重新分配可能需要设备与连接到其他后端组件的新 IoT 中心通信。This reassignment may require the device to communicate with a new IoT hub that's connected to other back-end components.

  • 隔离:类似于解决方案更改。Quarantine: Similar to a solution change. 出现故障、被盗用或已过时的设备可能会重新分配到仅可更新和恢复其符合性的 IoT 中心。A device that's malfunctioning, compromised, or out-of-date may be reassigned to an IoT hub that can only update and get back in compliance. 一旦设备正常运行,它就会迁移回主中心。Once the device is functioning properly, it's then migrated back to its main hub.

在设备预配服务中重新预配支持可满足这些需求。Reprovisioning support within the Device Provisioning Service addresses these needs. 设备可以根据设备注册项上配置的重新预配策略自动重新分配到新的 IoT 中心。Devices can be automatically reassigned to new IoT hubs based on the reprovisioning policy that's configured on the device's enrollment entry.

设备状态数据Device state data

设备状态数据由设备孪生和设备功能组成。Device state data is composed of the device twin and device capabilities. 此数据存储在设备预配服务实例和设备所分配到的 IoT 中心中。This data is stored in the Device Provisioning Service instance and the IoT hub that a device is assigned to.

使用设备预配服务进行预配

设备初次使用设备预配服务实例进行预配时,将执行以下步骤:When a device is initially provisioned with a Device Provisioning Service instance, the following steps are done:

  1. 设备向设备预配服务实例发送预配请求。The device sends a provisioning request to a Device Provisioning Service instance. 服务实例基于注册项对设备标识进行身份验证,并创建设备状态数据的初始配置。The service instance authenticates the device identity based on an enrollment entry, and creates the initial configuration of the device state data. 服务实例根据注册配置将设备分配给 IoT 中心,并将该 IoT 中心分配返回给设备。The service instance assigns the device to an IoT hub based on the enrollment configuration and returns that IoT hub assignment to the device.

  2. 预配服务实例将任何初始设备状态数据的副本提供给所分配的 IoT 中心。The provisioning service instance gives a copy of any initial device state data to the assigned IoT hub. 设备连接到已分配的 IoT 中心,并开始进行操作。The device connects to the assigned IoT hub and begins operations.

随着时间推移,IoT 中心的设备状态数据可能通过设备操作后端操作进行更新。Over time, the device state data on the IoT hub may be updated by device operations and back-end operations. 存储在设备预配服务实例中的初始设备状态信息保持不变。The initial device state information stored in the Device Provisioning Service instance stays untouched. 此未动的设备状态数据为初始配置。This untouched device state data is the initial configuration.

使用设备预配服务进行预配

根据情况的不同,当设备在 IoT 中心之间移动时,可能还需要将先前 IoT 中心上更新的设备状态迁移到新的 IoT 中心。Depending on the scenario, as a device moves between IoT hubs, it may also be necessary to migrate device state updated on the previous IoT hub over to the new IoT hub. 设备预配服务中的重新预配策略支持此迁移。This migration is supported by reprovisioning policies in the Device Provisioning Service.

重新预配策略Reprovisioning policies

根据具体情况,设备通常会在重启时向预配服务实例发送请求。Depending on the scenario, a device usually sends a request to a provisioning service instance on reboot. 还支持按需手动触发预配的方法。It also supports a method to manually trigger provisioning on demand. 注册项上的重新预配策略将确定设备预配服务实例处理这些预配请求的方式。The reprovisioning policy on an enrollment entry determines how the device provisioning service instance handles these provisioning requests. 该策略还确定是否应在重新预配期间迁移设备状态数据。The policy also determines whether device state data should be migrated during reprovisioning. 单个注册和注册组可使用相同的策略:The same policies are available for individual enrollments and enrollment groups:

  • 重新预配并迁移数据:此策略是新注册项的默认策略。Re-provision and migrate data: This policy is the default for new enrollment entries. 当与注册项关联的设备提交新的请求时,此策略将执行操作 (1)。This policy takes action when devices associated with the enrollment entry submit a new request (1). 根据注册项配置,可将设备重新分配给其他 IoT 中心。Depending on the enrollment entry configuration, the device may be reassigned to another IoT hub. 如果设备正在更改 IoT 中心,则将删除初始 IoT 中心内的设备注册。If the device is changing IoT hubs, the device registration with the initial IoT hub will be removed. 来自该初始 IoT 中心的已更新设备状态信息将迁移到新的 IoT 中心 (2)。The updated device state information from that initial IoT hub will be migrated over to the new IoT hub (2). 迁移期间,设备的状态将报告为“正在分配”。During migration, the device's status will be reported as Assigning.

    使用设备预配服务进行预配

  • 重新预配并重置为初始配置:当与注册项关联的设备提交新的预配请求时,此策略将执行操作 (1)。Re-provision and reset to initial config: This policy takes action when devices associated with the enrollment entry submit a new provisioning request (1). 根据注册项配置,设备可以重新分配给另一个 IoT 中心。Depending on the enrollment entry configuration, the device may be reassigned to another IoT hub. 如果设备正在更改 IoT 中心,则将删除初始 IoT 中心内的设备注册。If the device is changing IoT hubs, the device registration with the initial IoT hub will be removed. 将向新的 IoT 中心提供预配服务实例在预配设备时接收到的初始配置数数据 (2)。The initial configuration data that the provisioning service instance received when the device was provisioned is provided to the new IoT hub (2). 迁移期间,设备的状态将报告为“正在分配”。During migration, the device's status will be reported as Assigning.

    此策略通常用于恢复出厂设置而无需更改 IoT 中心。This policy is often used for a factory reset without changing IoT hubs.

    使用设备预配服务进行预配

  • 从不重新预配:设备从不重新分配到不同的中心。Never re-provision: The device is never reassigned to a different hub. 此策略用于管理后向兼容性。This policy is provided for managing backwards compatibility.

管理后向兼容性Managing backwards compatibility

2018 年 9 月之前,设备分配到 IoT 中心具有粘性行为。Before September 2018, device assignments to IoT hubs had a sticky behavior. 当设备经由预配过程返回时,它只会分配回同一个 IoT 中心。When a device went back through the provisioning process, it would only be assigned back to the same IoT hub.

对于已依赖此行为的解决方案,预配服务包括后向兼容性。For solutions that have taken a dependency on this behavior, the provisioning service includes backwards compatibility. 目前,根据以下标准对设备维护此行为:This behavior is presently maintained for devices according to the following criteria:

  1. 在设备预配服务中提供本机重新预配支持之前,设备与某 API 版本相连。The devices connect with an API version before the availability of native reprovisioning support in the Device Provisioning Service. 请参阅下面的 API 表。Refer to the API table below.

  2. 设备的注册项没有在设备上设置重新预配策略。The enrollment entry for the devices doesn't have a reprovisioning policy set on them.

此兼容性可确保先前部署的设备经历与初始测试期间相同的行为。This compatibility makes sure that previously deployed devices experience the same behavior that's present during initial testing. 要保留以前的行为,请勿将重新预配策略保存到这些注册中。To preserve the previous behavior, don't save a reprovisioning policy to these enrollments. 如果设置了重新预配策略,则重新预配策略优先于该行为。If a reprovisioning policy is set, the reprovisioning policy takes precedence over the behavior. 通过允许重新预配策略优先,客户可以更新设备行为,而无需重置设备映像。By allowing the reprovisioning policy to take precedence, customers can update device behavior without having to reimage the device.

以下流程图有助于显示行为出现时的情况:The following flow chart helps to show when the behavior is present:

后向兼容性流程图

下表显示了在设备预配服务中提供本机重新预配支持之前的 API 版本:The following table shows the API versions before the availability of native reprovisioning support in the Device Provisioning Service:

REST APIREST API C SDKC SDK Python SDKPython SDK Node SDKNode SDK Java SDKJava SDK .NET SDK.NET SDK
2018-04-01 及更早版本2018-04-01 and earlier 1.2.8 及更早版本1.2.8 and earlier 1.4.2 及更早版本1.4.2 and earlier 1.7.3 及更早版本1.7.3 or earlier 1.13.0 及更早版本1.13.0 or earlier 1.1.0 及更早版本1.1.0 or earlier

Note

这些值和链接可能会有所更改。These values and links are likely to change. 这只是占位符,尝试确定客户可以在何处确定版本以及预期的版本是什么。This is only a placeholder attempt to determine where the versions can be determined by a customer and what the expected versions will be.

后续步骤Next steps