Azure IoT-Edge "Device Move" Scenario

Richard G. Hubert 36 Reputation points
2020-10-14T07:34:54.81+00:00

Hi. We use Azure IoT-Edge with both the Transparent-Gateway pattern to new IoT-Devices and Identity-Translation-Gateway pattern to legacy devices. We need to find the best solution to "Move" a device between two IoT-Edge instances.

The Device-Move could be frequent between the IoT-Edge instances, not just once, so the procedure cannot be too complicated/intrusive. Some of the Device-Twin data needs to be common across the "Moves" but this can be handled in the IoT-Hub directly (via an Azure Function, for example).

What we are looking for here is ideas or suggestions for the best (supported) "Move" options.

  • Online-Move: move an IoT-Device between two IoT-Edge instances when both IoT-Edges are online.
  • Offline-Move: move an IoT-Device when the IoT-Edges are offline.
  • Hybrid approach: Move offline after the IoT-Device has been online-registered once on both IoT-Edge instances.
  • Other options?

Thanks for any thoughts on this! It is an important requirement in many real-world IoT-Edge constellations.

Azure IoT
Azure IoT
A category of Azure services for internet of things devices.
382 questions
Azure IoT Edge
Azure IoT Edge
An Azure service that is used to deploy cloud workloads to run on internet of things (IoT) edge devices via standard containers.
541 questions
Azure IoT Hub
Azure IoT Hub
An Azure service that enables bidirectional communication between internet of things (IoT) devices and applications.
1,124 questions
{count} votes

Accepted answer
  1. Kevin Saye 211 Reputation points Microsoft Employee
    2020-10-19T16:49:02.817+00:00

    @Richard G. Hubert interesting use case. As @António Sérgio Azevedo states, there few options for what you are accomplishing -- with the biggest challenge being the offline move.

    I agree that there are limitations in accomplishing what you want. The base limitation being that there is a 1:1 relationship for child to parent when associating a leaf device with an edge device and that IoT Edge has to be online to see the change. The PG has heard this 1:1 relationship feedback and you can vote on it here: https://feedback.azure.com/forums/907045-azure-iot-edge/suggestions/37178092-need-better-parent-child-relationship-with-iot-edg.

    Being familiar with the Nested Edge feature that @António Sérgio Azevedo speaks of, there are also other features that will release that will solve your issue. At the Ignite conference, it was announced that there would be a public preview of the Nested Edge on ~10/30, so I think you will soon have options!

    3 people found this answer helpful.

2 additional answers

Sort by: Most helpful
  1. Richard G. Hubert 36 Reputation points
    2020-10-14T16:04:39.79+00:00

    Ok. I read it. The created and update as shown here will certainly be of use iot-hub-bulk-identity-mgmt We already sync between reported and desired-state Twin content. However, the main challenge in our "Offline Move" scenario are the following. Maybe your team can help here:

    • Although we'd love to have a "pure offline" option, we'd currently be happy if we can make this work after the device has initially been connected to the Iot-Edge gateways -- call them EdgeA and EdgeB -- online and can then be moved at random between EdgeA and EdgeB after these have gone offline.
    • It looks like we'll need to create a unique IoT-Hub-ID in our backend (on the Iot-Hub) for the device for each EdgeA, EdgeB etc. (EdgeN) when the device is connected the first time to an EdgeN (online required). So we end up with N IDs/Twins for the same device. So, we're thinking of putting a "SyncedCommonTwinData" in these Twins and having to locate and sync this portion of the Twins each time a Reported state is changed (in the IoT-Hub). This is because the end IoT-device may have, for example, calibration data changed via Edge-A (locally) and it must find this same calibration when it is attached to Edge-B. This sync operation will have to be kicked-off (somehow) when device-critical (CommonTwinData) is changed locally. Our application will have to warn the user to go online or such in this case.
    • A significantly simpler solution to this could be supported by Azure IoT if the Iot-Hub would allow us to share the SAME Iot-Hub-Device-ID across multiple IoT-Edge gateways, then we would not have a bunch of redundant IDs and Twins to manage. For example, add a property (and portal checkbox) "Share this device across multiple IoT-Edges?

    That is our first design cut in any case ... that we'll try unless we find a better idea. Thoughts?

    1 person found this answer helpful.
    0 comments No comments

  2. António Sérgio Azevedo 7,666 Reputation points Microsoft Employee
    2020-10-15T18:11:55.737+00:00

    Hello @Richard G. Hubert , thank you for taking time and read the shared doc (Import and export IoT Hub device identities in bulk).

    I have also researched further and to address your main challenge where "failure is not an option for us." and "move an IoT-Device between two IoT-Edge instances" offline and online I believe that the best approach would be to use IoT Edge on Kubernetes (Preview)

    • *IoT Edge can integrate with Kubernetes using it as a resilient, highly available infrastructure layer... IoT Edge manages the edge application platform running on top, continuously reconciling the desired state specified in IoT Hub with the state on the edge cluster. *

    As to the specificities of your project and north star "to have a 'pure offline' option" I am afraid I can't guarantee that IoT Edge on Kubernetes will address all the needs. See as well how @Kevin Saye approaches similar challenges as yours here: https://kevinsaye.wordpress.com/2020/06/18/achieving-high-availability-with-azure-iot-edge/

    Finally another possibility is to use IoT Edge Nested Edge that is now in private preview

    • Nested Edge is a new feature of the open-source Azure IoT Edge product that allows customers to deploy IoT Edge nodes across networks organized in hierarchical layers, where only the top layer has connectivity to the cloud... that help them reduce unplanned downtime, increase equipment efficiency, and reduce defects in the manufacturing process.

    Thank you!