Software updates in an IoT context

Eclipse hawkBit — Features, requirements, scenarios et al.

Michael Hirsch and Kai Zimmermann
Eclipse hawkBit
Total solar eclipse image via Shutterstock

Eclipse hawkBit [1] is a new project within the Eclipse IoT Working Group [2], the goal of which is to furnish an open platform for the Internet of Things. hawkBit is a project initiated by Bosch Software Innovations in support of this initiative, joining the Eclipse Vorto [3] and Eclipse Hono [4] projects. It will concentrate on providing a framework that allows for the simple integration of a software update functionality into an IoT solution or platform.

Implementing software on everything from embedded control units to more powerful gateways is a routine task in just about every IoT project. If device software can be updated, the project is presented with a range of new possibilities, not least the chance to confront the increasing number of security issues. As soon as a device is connected, it is vulnerable to a whole new line of attack – and that is something for which developers of hardware and embedded software must be prepared.

On a more positive note, software updates also give embedded software developers the opportunity to work using an agile development model that no longer requires every device function to be fully implemented at the point of hardware manufacture.

There are instances in which the software update is a business model in itself. Products are much more attractive to consumers if they know that not only do they get X array of features, but can expect to benefit from future product updates as well. Smartphones and PCs have long been sold this way, but it is rather rarer in the more traditional sectors in which the IoT is now becoming an exciting new field. Tesla is a good example of software updates marketed as a product feature, and in a sector that has so far not been highly connected. Selling additional functions (apps) after the point of sale could also be an interesting business model in the new sectors now being reached by the IoT.

We must be conscious that, in the context of the IoT, cloud-supported updates bring with them a whole series of challenges that we are simply not familiar with from the updating of servers, PCs, or smartphones. On the plus side, from the backend perspective, software updates for the IoT are relatively independent of the specific domain, meaning that they need only be implemented once. In essence, the requirements for updating a smart home, an assembly line, or a car are the same in each case – though of course there will be a difference in the security required and the operations occurring on the device itself.

SEE ALSO: A simple way to look at Eclipse IoT

Eclipse hawkBit was launched to provide a solution to these exact non-domain-specific requirements. To this end, hawkBit provides a range of features:

  • A device and software repository
  • Interfaces for flexible device integration
  • User interface and interfaces for executing software update operations and managing the repository
  • A modern architecture based on Spring Boot that makes it easy to adapt hawkBit to the user’s individual needs

On the non-functional side, the focus is on:

  • Interface stability for long-lasting devices
  • Interface flexibility for device integration in the project
  • Functional scalability for big IoT rollouts
  • End-to-end security for the software update process

Note: Eclipse hawkBit does not currently possess a ready-to-go device client, and is hoping for active collaboration from the Eclipse community.


Let us turn our attention now to the specifics of the requirements. These are dictated in large part by the simple truth that the software update process is a process that must never fail. On the one hand, it can be an IoT system’s savior, since a successful update can resolve almost any device malfunction. On top of that, cloud interfaces can be modified and expanded to keep abreast of cloud developments. On the other hand, an update is also one of the biggest risks to a device, since it can be used to bypass almost every security mechanism.

A device’s length of service also depends on keeping the software update mechanism stable throughout the device’s service life. This can often be a period of years or even decades. Furthermore, in contrast to PCs and smartphones, manual intervention from a device’s end user is most often not an (affordable) option in the IoT context.

We would like to take a look at three of the most important requirements in more detail. We also briefly mention a further requirement, which is no less important but which Eclipse hawkBit was not designed to address.

Interface stability

IoT devices have service lives ranging from a few years for the consumer market to a few decades in industrial and automotive contexts. We should not forget that there are scenarios in which connected devices might go for extended periods without contact with the backend. For instance, a device might be produced and then spend one or two years in a warehouse. The time periods for a device that has been bought and installed but never connected are even longer; imagine a customer who possesses a cloud-ready heating system or power inverter and yet has never got round to providing it with internet access.

As a result, it can be years before a device makes contact with the cloud for the first time. Nobody expects the technical backend to exist with the same interface as at the time of manufacture. Nevertheless, the software update functionality must at least still work.

Interface flexibility

Interfaces must be as flexible as they are stable, since the IoT does not possess any established standard governing device connectivity or device management. There are all sorts of transport protocols currently in use, ranging from HTTP to MQTT, AMQP, and CoAP. In terms of device management, OMA-DM, LWM2M, and TR-069 provide some degree of standardization, though in practice none has yet firmly established itself across domains. As a result, most projects tend to rely on their own protocol for device management. It is also standard practice to use just a single channel for completing operations such as updating the software on the device and transferring data from the device to the cloud.

Functional scalability

Quite aside from technical scalability – that is, the flexible supply of computing capacity and bandwidth during an update (already offered by a variety of cloud platforms for a very reasonable price) – it is also crucial for large IoT projects that involve thousands or even millions of devices to retain functional control over the entire update rollout process. This includes the ability to split devices into multiple subgroups and to execute the rollout group by group or according to a set schedule, as well as the ability to stop the rollout in a controlled manner should something go wrong. It also means being able to monitor the entire rollout all the way from implementation to evaluation after the process is complete.

The system must also be able to cope with the fact that in a rollout many devices might install the update very late or not at all, perhaps because they are registered but never online. In this sense, it is likely that very large-scale rollouts will never be declared entirely complete.

End-to-end security

The software update process relies on trust between the device itself and the creator of the software. In between is the software update service, whose task is first and foremost to transfer software onto the device. As a result, it is also the point at which the danger of corruption arises. It should never be the duty of the software update service, as the “man in the middle,” to confirm the authenticity of a software artifact. Its job is to encrypt the transfer, and authenticate and authorize devices and users, but at the end of the day it is up to the device itself to verify software authenticity, for instance via a digital signature. That is why hawkBit deliberately gives no guarantee of end-to-end security.

SEE ALSO: Eclipse Vorto: Interoperability for the Internet of Things

Eclipse hawkBit

Eclipse hawkBit is already addressing some of these challenges. Interface stability with the device is enabled by the simple RESTful API for direct device integration, accessed directly from the device, where it focuses completely on software updates and can easily be kept stable. At the same time, the device management federation API supplies a high level of flexibility for device integration, making it possible to patch in various device connectors.

Meanwhile, work is still ongoing within the community on functional scalability, as we will cover in more detail in the outlook at the end of this article. As we have already mentioned, hawkBit deliberately makes no guarantee of end-to-end security; this will require additional work in an appropriate project.

As well as these specific requirements, hawkBit must of course comply with today’s established standards. These include flexibly applicable interfaces, a modern cloud-ready software architecture, and – of particular importance for an open source project – a high degree of flexibility in using the software for in-house projects.

Integration scenarios

Eclipse hawkBit can be used as a stand-alone application for implementing software updates directly on a device. In this most basic scenario, the administrator uses the hawkBit management UI to manage the repository and execute updates. Devices are connected to the hawkBit server via the direct device integration API.


Fig. 1: hawkBit, simplest user scenario

More comprehensive integration is enabled by the RESTful management API, the features of which are compatible with the management UI. It can be used to:

  • Conveniently ascertain a device’s software version, perhaps for a support portal
  • Trigger an update from a workflow engine
  • Refill the software repository from a continuous integration engine, with a subsequent update on test devices for integration testing
  • Integrate all functionalities into a device management application.

The final element is the device management federation API, which enables the indirect connection of devices via (existing) connectors using an AMQP (0.9) broker. If both interfaces are fully occupied, hawkBit is able to concentrate on managing the repository and update process.


Fig. 2: The possibilities of hawkBit integration

A software update is more than just a file

Software updates most often consist of multiple software components, including operating system, run-time, and application components. The software components themselves also comprise multiple files, for instance the complete update, various binary deltas, and signatures.

Eclipse hawkBit defines a flexible data model that is capable of combining these complex structures, including metadata such as version and description, into a software update. The model can be used to supply devices with multiple software packages and update them in an atomic process.


Fig. 3: hawkBit software update package model

Trying out Eclipse hawkBit

The source code for Eclipse hawkBit [5] can be cloned from GitHub and installed via Maven (listing 1).

$ git clone
$ mvn clean install

Once you have successfully installed the source code, you can launch the accompanying sample application, which makes the management UI available for rolling out software to devices.

The graphical interface can be accessed at http://localhost:8080/UI; users can log in with the following credentials: user: admin and password: admin (listing 2).

$ java –jar ./ examples/hawkbit-example-app/target/hawkbit-example-app-#version#.jar

So that the user does not need to write their own device client for testing, hawkBit comes with a device simulator that is capable of simulating update-ready devices and connecting them to hawkBit via both interfaces (listing 3).

$ java –jar ./ examples/hawkbit-device-simulator/target/hawkbit-device-simulator-#version#.jar

For simulating devices, users can choose from either the graphical interface or the simulator’s RESTful API.

$ curl http://localhost:8083/start?amount=10&api=ddi

The samples also include a management API client that demonstrates the use of the management API as well as automatically generating a few sample software packages for immediate use in the hawkBit sample application.

$ java –jar ./ examples/hawkbit-mgmt-api-client/target/hawkbit-mgmt-api-client-#version#.jar

Using the management UI provided with the hawkBit sample application, users can then roll out the ready-made software packages onto the simulated devices.


Fig. 4: hawkBit: Manual software update example


At the time of writing, the hawkBit project is preparing for its first release, release 0.1, which will incorporate the basic functionalities and interfaces we have described in this article. Release 0.2 will be a further step towards functional completion, particularly in terms of developing a rollout management system to fulfill hawkBit’s defined claim of functional scalability.

From a technical standpoint, we are aiming for further improvements with regard to hawkBit’s flexibility, modularity, and capacity for integration. There are also interesting possibilities for integration with other Eclipse IoT projects such as Leshan [6], so as to supply LWM2M devices with firmware, Hono, to make it easier to connect devices to hawkBit, and Tiaki [7], so devices can find the correct hawkBit server securely and automatically.

Links and literature:


Michael Hirsch and Kai Zimmermann

As Lead Developer, Michael Hirsch is responsible for software provisioning development activities at Bosch Software Innovations GmbH and is a Committer for the Eclipse hawkBit project.

Kai Zimmermann is Product Owner for the Bosch IoT Rollouts cloud service at Bosch Software Innovations GmbH and Project Lead for Eclipse hawkBit.

Inline Feedbacks
View all comments