10

What is the best practice to ensure an IoT device has been updated successfully?

What do you need to do in order to test OTA updates and authenticate devices? Taking it a step further, how can you monitor/manage the software versions (updates) of a fleet of IoT devices?

Improve this question
  • 1
    This is too broad, like your other question. And it'll depend a lot on the type of device and mode of deployment. – Gilles 'SO- stop being evil' Dec 7 '16 at 0:22
  • 1
    When you say "fleet ", do you mean a vehicle fleet? If so, I presume communication by (encrypted) SMS, or HTTPS over GPRS, or event satellite, using something like a SkyWave modem. if you can edit your question to clarify, I am sure that it will be reopened. – Mawg says reinstate Monica Dec 7 '16 at 10:07
10

I have software (Windows Server - a little different to 'things' but the principal is the same) that calls in every 24 hours - it sends back various meta data about itself :

  • customer name (or unique ID)
  • software version
  • timestamp of call/request
  • product type / id

The web service parses out the data and inserts (or updates if the customer has an existing row) a row in a database.

This way new customer get automatically added to the DB, existing customers get their 'last seen' timestamp updated and we always have their latest software version. I can run DB queries that tell me which customers are on older versions, and/or which customers have not called in for a while.

We also implemented an auto update (think OTA update) recently and because this is a critical process we implemented specific telemetry for this - that records:

  • Current version.
  • Version to be updated to.
  • Who/when authorised it (if customer acceptance is required).
  • Timestamps and status codes for each of the major steps.

This allows us to determine if certain aspects of the auto update are failing and in many cases lets us call the customer often before they even notice that anything is wrong.

The big difference with 'things' is that you are typically memory constrained, so to do an OTA update of xxx Kb of firmware you need xxx Kb * 2 of memory available (existing firmware + sufficient memory to store new firmware before starting the actual firmware updating)

Improve this answer
  • 1
    thanks for sharing. The memory usage is an important point to make. How do you go about authorization and customer acceptance, when applicable? Do you require a password to accept an update? – Noam Hacker Dec 6 '16 at 20:02
  • 2
    It's a different use case (because it's Windows Server), but we have a UI that pops up an alert when the OTA update has been downloaded - the alert asks the customer if they want to update (and includes links to release notes etc). On a thing I'd probably flash a LED or something to alert the user (assuming you want the user to 'allow' the update) and then have them 'long press' a button to start it... – KennetRunner Dec 6 '16 at 20:11
5

You could, for example, make a request every X weeks/days/hours... to a server with the current version number of the software. You will after be able to use analytics to see the current percentage and number of devices updated.

Improve this answer
  • 1
    Does this account for devices which have been bricked, or have failed to complete an update (maybe stuck in a reboot, download, crash cycle?) – Sean Houlihane Dec 6 '16 at 19:25
  • 1
    In a way, yes. If you have 100 devices on day 1, you push update on day 2, and day 3 you got only 25 devices on analytics, it means something bad happened – WayToDoor Dec 6 '16 at 19:28
  • 1
    that's interesting. is there a way to differentiate between types of failures? – Noam Hacker Dec 6 '16 at 19:57
  • 1
    split the update down into discrete steps (e.g. add new config values, reboot gps, set device id, overwrite firmware, etc) with each having a starting .. call send 'home' and a completed with status xx call sent home. That way you can tell (roughly) where it failed and (hopefully) what the status code was. – KennetRunner Dec 6 '16 at 20:34
4

It's all about a smart synchronization policy

You need a smart synchronization policy that works in tandem with your roll-out approach of your update. The most obvious point in time where the IoT device should sync its version is directly after the update. The rest of the sync schedule is highly dependent on the type of device.

Is it always on and connected via cabled connection where a single sync doesn't cost (a lot) it makes sense to sync pretty periodically to keep your data about the device current.

If the device is somewhere were every bit is costly because you are using expensive satellite connections the sync schedule has to accommodate that circumstance.

Verification of the synchronization

In a sufficiently advanced device (read a price range or operation area that justifies it) each device could be equipped with a client certificate that enables an authenticity check of the synchronization.

Anyways with end customer devices you'll always have devices fall of the radar due to dying batteries, the device falling out of use or simply the customer changing its wireless password and not informing the IoT device. Those might not have to do anything with your update, even if they fall together timing-wise.

Improve this answer
  • I don't think this give a solution to the question of the OP. – WayToDoor Dec 6 '16 at 21:27
  • @WayToDoor my first paragraph advises to sync directly after the update. That gives the information if the new version was successfully reached. Possible counter measures if that has not been the case are way too broad (and not asked for). The rest of my answer deals with monitoring the versions in the field. Which question did I miss? – Helmar♦ Dec 6 '16 at 21:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.