Overview

Having software update capabilities ensures a secure IoT by means that it gives IoT projects a chance against security threats that emerged the moment their devices became connected. From that moment on devices are at the forefront of IT security embedded software developers historically never had to face. Shipping for instance a Linux powered device connected to the Internet without any security updates ever applied during its lifetime is not wise move to say the least.

A more positive argument for software update is that it enables agile development for hardware and hardware near development. Concepts like a minimum viable product are applicable for devices, as not all features need to be ready at manufacturing time. Changes on the cloud side of the IoT project are applied to the devices at runtime as well.

Sometimes Software Update is a business model on its own as it makes devices much more attractive to the customer if they are updatable, i.e. they do not only buy a product because of its current feature set but make also a bet on its future capabilities. New revenue streams arise from the fact that feature extensions can be monetized (e.g. “Apps”) without the need to design, manufacture and ship a new device (revision).

Motivation for Bosch IoT Rollouts

Updating software (components) on constrained edge devices as well as more powerful controllers and gateways is as mentioned before a common requirement in most IoT scenarios.

At the time being, this process is usually handled by the IoT solution itself, in some cases backed by a full-fledged device management system. We believe that this approach generates unnecessary duplicate work in the IoT space, in particular when considering the challenges of implementing a safe and reliable remote software update process: the software update process must never fail and also never be compromised as, at the one hand, it is used to fix close to any issue/problem on the device but at the same time also poses the greatest security threat if miss-used to introduce malicious code to the device.

We believe the software update process is independent from particular application domains when seen from the back-end (cloud) perspective. Updating the software for an entire car differs from updating the firmware of a single sensor with regard to the connectivity of the device to the cloud and also to the complexity of the software update process on the device.

Software update itself is often seen as a sub process of general device management.

However, existing device management systems usually lack the capability to efficiently organize campaigns at IoT scale, e.g. splitting the rollout into subgroups, cascading them, automatically stopping the rollout after a defined error threshold etc. They are also usually restricted to a single device management protocol, either a proprietary one or one of the existing standard protocols like LWM2M, OMA-DM or TR-069. Even if they support more than one such protocol, they are often a result of the device management protocol they started with and restricted in their adoption capabilities to others.

At the same time the wide functional scope of a full-fledged device management system introduces unnecessary (and unwanted) complexity to IoT projects.

As a result, we have the need for a domain independent solution:

• that works for the majority of IoT projects

• that goes beyond the pure update and handles more complex rollout strategies needed by large scale IoT projects

• that is focused on software updates in the IoT space

• and that is able to work on its own for simple scenarios while having the capability to integrate with existing device management systems and protocols

Software update cloud service

A cloud-ready software update service requires:

• Technical scalability: connect millions of devices and ship terabytes of software on a global scale.

• Functional scalability: campaigns with hundreds of thousands of individual devices in it.

• Reliability: software update as the last line of defense against device faults and vulnerabilities.

• Managed device complexity: device topologies inside each individual provisioning target.

• End-2-end security & integrity: a chain of trust between the software/firmware release manager and the device itself. Note: Optionally covered by Bosch IoT Rollouts in combination with escrypt by ETAS. For more detailed information we recommend section Authentication and authorization.

• Integration flexibility: connect and integrate through various (non-)standardized device management protocols directly or through federated device managements.