80 lines
5.6 KiB
Markdown
Executable File
80 lines
5.6 KiB
Markdown
Executable File
---
|
|
title: What is hawkBit?
|
|
weight: 10
|
|
---
|
|
|
|
Eclipse hawkBit™ is a domain-independent back-end framework for rolling out software updates to constrained edge
|
|
devices as well as more powerful controllers and gateways connected to IP based networking infrastructure.
|
|
|
|
|
|
|
|
## Why Software Updates in IoT?
|
|
|
|
Having software update capabilities ensures a secure IoT by means that it gives IoT projects a fighting chance against
|
|
pandora's box that they opened the moment their devices got connected. From that moment on devices are at the forefront
|
|
of IT security threats many 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 kind of a
|
|
suicidal act these days.
|
|
|
|
A more charming argument for software update is that it enables agile development for hardware and hardware near
|
|
development. Concepts like a minimum viable product can be applied for devices as not all features need to be ready at
|
|
manufacturing time. Changes on the cloud side of the IoT project can be 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. In addition new revenue streams may arise from the fact that feature extensions can potentially be
|
|
monetized (e.g. Apps) without the need to design, manufacture and ship a new device (revision).
|
|
|
|
## Why hawkBit?
|
|
|
|
**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**, sometimes 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 must never be compromised as, at the one hand, it can be used to fix
|
|
almost any issue/problem on the device but at the same time also poses the greatest security threat if mis-used to
|
|
introduce malicious code to the device.
|
|
|
|
In addition we believe the software update process to be relatively **independent from particular application domains**
|
|
when seen from the back-end (cloud) perspective. Updating the software for an entire car may differ 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 package update process on the device. However, the process of rolling out the software, e.g. uploading an
|
|
artifact to the repository, assigning it to eligible devices, managing the roll out campaign for a large number of
|
|
devices, orchestrating content delivery networks to distribute the package, monitoring and reporting the progress of the
|
|
roll-out and last but not least requirements regarding security and reliability are quite similar.
|
|
|
|
Software update itself is often seen as a sub process of general device management. In fact, most device management
|
|
systems include functionality for triggering groups of devices to perform an update, usually accompanied by an artifact
|
|
repository and basic reporting and monitoring capabilities. This is true for both systems specifically targeting IoT as
|
|
well as systems originating from the mobile area.
|
|
|
|
Existing **device management systems** usually **lack** the capability to **efficiently organize roll outs at IoT scale
|
|
**, e.g. splitting the roll out into sub groups, cascading them, automatically stopping the roll out 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 many IoT projects. This is particularly true for IoT solutions working with constrained
|
|
devices where requirements regarding generic device management are often very limited only but a secure & reliable
|
|
software update process is still mandatory.
|
|
|
|
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 **roll out strategies** needed by large scale IoT projects.
|
|
* that at the same time 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.
|
|
|
|
## Cloud Ready
|
|
|
|
* **Technical Scalability**: connect millions of devices and ship terabytes of software on a global scale.
|
|
* **Functional Scalability**: rollouts 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.
|
|
* **Integration flexibility**: connect and integrate through various (non-)standardized device management protocols
|
|
directly or through federated device managements. |