Commissioning / Bootstrapping for headless industrial IoT device


#1

What we do now

We currently are using a YOCTO built version of Linux for Raspberry Pi 3. This allows us to:

  • Write a custom configuration file to the boot partition on the sd card from Windows. This contains information such as how to reach servers and identification keys.
  • Our embedded application is able to see this file and uses it on launch. This doesn’t require any on-device (keyboard / monitor) to be connected to the device.

What we want to do

How do we do this with Ubuntu Core?

Considerations:

  • We distribute thousands of these devices a year. It’s not practical to manually enter this information via keyboard.

What we’ve looked at

  • There appears to be a Serial Assertion, but this seems to be a way to identify our device to the Ubuntu / brand store.
  • pepare-device hook - this seems related to what we need, but it’s not obvious how we can incorporate this into our workflow.
    – does this hook allow for any user input?
    – how do we run this with device specific values?
    – Is the “device service” a custom service or is this the api defined somewhere?

#2

there are multiple ways here … the easiest is probably to simply forget about the OS and have all your software on top in one single (or multiple) snap package … seed these snaps via your own model assertion into the image and have the app do its setup duty (obtaining config files from servers and configure apps or the system) on first boot … you could even put these bits into snap config hooks so you can change them via a single snap command.

a more deeply integrated approach would be to use the gadget prepare-device hook and do similar steps as above but on a lower level.

regarding your three points:

  • hooks are in general not interactive so they would not be able to take any user input.
  • typically device specific settings are based on something like a serial number, you could also make it based on a MAC address or anything else unique to the device
  • the “device service” from the example would be something like the serial vault, which you can use to i.e. manage a private store (one that manages only your snaps in a non public way, allows you to use specific model or user assertions and through that also device configurations that you can in turn handle via a config snap from your store)