On-Device Update Service

Motivation

Maintaining up-to-date trigger definitions on the edge device requires a secondary software process outside the SDK(but still running on the edge). This is shown in the architecture diagram here.

This implementation is up to the customer, but a sample is outlined here and provided as part of the SDK.

Background Service

The update service is a background systemd service that runs at set cron intervals. This service can first check for connectivity by pinging the smart capture update server (also shown here). If connectivity is established, it will proceed to download updated trigger configurations.

This systemd service will parse an adjacent config file for different variables, like the device name, the update time, the retry policy, and others (see list below).

This config file is a critical part of the smart capture bring up process when users provision a new edge device.

Run Loop

  1. Ping the cloud-enabled update server to establish connectivity.
  2. If connectivity is established, continue. Else, log the attempt and exit.
  3. Given the device name, query the update server for the most recent version of all triggers to be deployed to this device.
  4. Write triggers to a temporary file
  5. Atomically swap new temporary file with the trigger file.
  6. Log the time that triggers were updated, unlock the file, exit.

Config JSON

The config JSON will hold the following fields, with a sample JSON gist.

  • Device Name (string)
  • Update Frequency (int seconds)
  • Retry Policy (enum: exponential backoff, set time, etc.)
  • Logging Location (string filepath, default /var/syslog)
  • Update Server Host (string host name)
  • Update Server Port (integer)

Did this page help you?