Eclipse hawkBit Refines Its Software Distribution Methods

The Eclipse hawkBit project was created to provide a back-end service for managing and orchestrating software updates for IoT devices. While the last official release for the project was in February of 2021, much has been in the works since. Several updates are expected to be released by Q4 of this year to deliver even more features. But first, a refresher on what hawkBit is all about. 

Client-Agnostic Framework, Active Monitoring, and Rollout Control

The main component of Eclipse hawkBit, the Update Server, sits between the management UI and API and the Direct Device Integration (DDI) and Device Management Federation (DMF) APIs, as shown below. The DDI API enables direct integration of devices with hawkBit, while the DMF API involves third-party device management services or applications.

Combined with its client-agnostic framework, this enables hawkBit to support easy and flexible rollouts. And its rollout management has three key features that support this:

• Installation status of previous groups that affect the cascade of update deployment
• Emergency shutdown of rollouts if a group exceeds the defined error threshold
• Progress monitoring for individual, as well as overall, rollouts

By making hawkBit client-agnostic, we hoped to make it as useful as possible to the largest number of people, leaving it up to the community to provide the client implementations. There have been several implementations of Eclipse hawkBit already, including for Arduino and Yocto Linux. Moreover, the Eclipse Hara subproject provides a clean implementation of the DDI API written in Kotlin, meaning it can be used with any language supported by the Java Virtual Machine (JVM). 

Overall, hawkBit was built to:

• Help organizations meet legal requirements for providing fixes for security vulnerabilities in devices
• Accelerate time to market with the ability to add further functionality post-product release
• Enable new business cases, such as a feature store or subscription models for device updates

Assigning Updates by Device

The initial suite of features built into hawkBit were obviously meant to facilitate these purposes. So are our updates.

If you are not familiar with hawkBit, here is a quick overview of its core concepts. The central concept is the software module. A module may contain one or several artifacts (files) to be deployed on the devices. You can group software modules in distribution sets. When launching a deployment, you can select the targets manually or through a target filter. 

The first one deals with how fine-grained the distribution of distribution sets is. We’re adding the ability to express compatibility between distribution sets and targets.

Currently, distribution sets go out to all targets. This is fine in scenarios where organizations only have one type of hardware to update. For example, if you have a business where you rent e-bikes, all of which are the same exact model, then you could update them all simultaneously, no problem. But if you have different models, some of which are perhaps older and not compatible with the new software, that could be an issue.

As of now, there’s no way to express that, and no user guidance in hawkBit. But this update will give hawkBit users the ability to create target types.

So, you can assign a type and say that all targets of this type are compatible with distribution sets of certain types, and hawkBit will enforce that compatibility matching. You can also filter by target types to make the whole process easier. 

Invalidation of Distribution Sets

We’re also adding the ability to invalidate distribution sets. 

Mass rollouts are the most convenient way to do mass updates, rather than trying to update each device one at a time. But if those updates lead to errors or, worse, bricked devices, there isn’t an easy way to stop them. 

So, we have added the ability to invalidate distribution sets. We also added some finer grained controls. The first step is to choose the type of cancellation.

Once you’ve chosen the type of cancellation, hawkBit will show you which actions will be taken as a result. 

As well, if you later go to send that distribution set out again…

…then hawkBit will automatically prevent it. 

Quality-of-Life Additions

We’re also adding a few other, smaller features that are worth mentioning. 

The first is an artifact encryption plug point. This allows artifacts that are currently stored within rollouts to be encrypted. That way, you never have software lying around in an unencrypted manner. 

Another addition is the Installed Base. This feature extends the DDI API with the installedBase endpoint, which provides the latest installed distribution set information. This makes it useful for factory reset and device sync scenarios. 

We’ve also added the optional ControllerAttributes property to the THINGCREATED message of the DMF API, which provides the attributes of the thing, as in this example. 

```

{

    "name": "String",

    "attributeUpdate": {

        "attributes": {

            "exampleKey1" : "exampleValue1",

            "exampleKey2" : "exampleValue2"

        },

        "mode": "String"

    }

}

```

Finally, we’ve added UI deep-linking for targets, as in this example. 

`<hawkbit-server-url>/UI/#!deployment/target=<target_id>`

If you’re curious about what else we’ve been up to, or would perhaps like to get involved with the project, we’d encourage you to check out our GitHub page, or join the community conversation on Gitter Chat.