Overview

Our system, if fully implemented, consists of three main components.

All components are accompanied by unit testing and component testing code. We also have integration test code running in our testing environment; any feasible combinations of known component versions or configurations are continuously integrated. If desirable, we can even support continuous deployment on your embedded targets as well. More on that topic further down in our information sections.

We can also offer any of those components on their own; we have also integrated the device agent in existing devices next to pre-existing software. The same goes for the ‘package generator’, which we have set up in a different project, uniforming the way of firmware generation.

Device agent

Our device agent component is running in each device. It will allow the device to connect to one or more backends to communicate and execute any firmware change or configured actions. The device takes the initiative to connect to the backend at regular intervals (also configurable). This way the devices are not exposed to the outside world and this keeps our system design simpler as well. Communication between the device agent and the backend will always be encrypted using HTTPS/TLS. This means that also in highly firewalled and regulated networks our system can still function.

Device firmware package generator

This component contains a reference example environment from where you can easily create a customer-specific device firmware image. It can optionally run in a Docker container so that only a dependency on docker is required to develop your firmware. The package generator can be used to build all required sub-components based on configurable input components and customer-specific changes or additions. It can upload any created package to a testing system or directly to any of the set up back ends. There is also support for automatic generation of differential firmware packages, signed/encrypted firmware packages and version information control. The package generator can incorporate any Yocto, Buildroot or practically any known Linux build platform artifacts as well.

Backend

Our backend is the central place where all devices connect and where all firmware packages can be stored. Based on the size of your device-pool, there can be multiple backend instances of course. CDN-hosted firmware packages are also supported from our systems and components.
If you choose for our manged backend hosting, we can scale the backend as soon as required and also pro-actively monitor it. Alarms can be triggered for any device anomalies. For example, alarms sent on Telegram, email and calling external APIs. We setup separate private servers for every customer. On request we can optionally support running our software on your server platform/location of choice.

Continuous integration

With regard to firmware development in general we think that testing is the most important thing you should do. But in reality testing of firmware on physical hardware can be quite challenging. Testing is one of the things we have kept in mind during the design of every component in our system. We even have developed special integration software which can be deployed on any of our components. Device firmware based on our reference implementations can be tested starting from day 1. We rely on testing using both simulators and physical hardware.

In our testing environment we test any plausible combination of components of any project. We test that if we change anything in the device firmware or device agent, the overall functionality of the update system keeps intact. The same goes for changes in the backend; they are tested on any in use firmware version. This way we can assure that in the unlikely case of an operator pushing a firmware package with a problem, we can afterwards update the device again or go back to a previous known version.
In some cases a device based on our software can also detect a broken firmware itself in which case it can automatically rollback to the previous version. In such an event the backend can be notified of this afterwards, which could be configured to result in an active operator alarm.

Continuous deployment

We place a lot of trust in our update system. We even support and guarantee automatic and unattended updates to devices based on our system. The sub-components of device firmware are based on vanilla opensource components. These components get updated quite frequently by so-called up-stream developers. Based on the correct location (for example LTS, Long Term Support trees), even relatively older releases will keep getting (security) updates. We think this it the true power of open source. Because there is no business incentive behind this and because of that the community keeps updating these components, one can always have these free-of-charge.
Because we also value secure firmware and best practices with regard to firmware development in general, we think that you should update often and quickly. Because this implicitly brings you the risk of breaking things, this should be tested thoroughly before pushing automatically generated firmware updates to devices. But… we have a health(y) framework for testing that beforehand. And in case you still want to be in control after all, this can be configured to wait for a ‘pending operator approval’ event.

If you apply this kind of testing, you can probably push firmware updates quickly. This can be strongly desired because of fixed CVE issues (https://cve.mitre.org/). In such a case your devices are no longer vulnerable than needed or known, or maybe even get updates before an issue becomes known. And more on a legal level, you can be prepared upfront before the possibility of the government taking action with regard to IOT regulation. That is also probably something which you have not thought about before you started thinking about making ‘connected devices’.