Nowadays there are several well engineered open projects available for updating remote, embedded and IoT devices, and they may serve different industries for prototyping an end-to-end solution without starting from scratch. In the scope of delivering software artifacts remotely, Eclipse hawkBit is definitely one of those great open projects. In particular the hawkBit methodology to handle Software Distributions enables the delivery of artifacts independently from the operating system installed on the target device. Examples of possible artifacts to be deployed are: Android APKs, Android OS Updates, Linux OS images, Docker images to microcontroller’s blobs. There could be many use cases applied to real world scenarios to consider when updating any device. In particular those involving the device itself, in other words on the embedded client domain. It is reasonable to consider the client as a crucial block in the overall architecture of an updatable system. In particular, handling device’s local business logic and execution strategy behind a remote update. Use cases develop around functional and non-functional requirements. Some critical use cases are driven by non-functional requirements. Common situations to faced during an update cycle could be:
- How should the devices react to connection timeouts during download, in terms of user experience?
- How should the device orchestrate effectively, the server states of an entire update cycle?
- How should the device handle the update of the client software itself?
- What if an update artifact is malformed?
- ...
It is clear that many of these questions have their answers in the remote device context and no matter how good the hawkBit server is operating on the backend, a poor client implementation can make the entire update process unreliable, especially in a production environment.
The scope of the project is to provide a reference agent software implementation featuring the Eclipse hawkBit device API. Such reference implementations are initially driven by operating systems and application frameworks that today constitute the main platforms for the majority of IoT and embedded devices. These devices include but are not limited to: Open Embedded, Android, QT, etc. The scope of the project is to fill the gap that was intentionally left out by the hawkbit project. The purpose is to provide an artifacts management system for handling software updates on the device. By providing a solid open source reference implementations of a hawkBit client, which is driven by proven use cases for updating a remote device, the project can be beneficial toward the adoption of the hawkBit by closing the loop between backend and the target device.
The scope of the project is to provide a reference agent software implementation featuring the Eclipse hawkBit device API. Such reference implementations are initially driven by operating systems and application frameworks that today constitute the main platforms for the majority of IoT and embedded devices. These devices include but are not limited to: Open Embedded, Android, QT, etc. The scope of the project is to fill the gap that was intentionally left out by the hawkbit project. The purpose is to provide device update management, andclient solutions for handling software updates on the device. By providing a solid open source reference implementations of a hawkBit client, which is driven by the fundamental use cases for updating a remote device, the project can be beneficial toward the adoption of the hawkBit update server as a backend solution.
Fundamental blocks of the client design are:
- hawBit DDI Client, which implements API towards the update server
- the Service, which is the runtime execution context of the DDI Client. The service includes the DDI client as a library
- messaging systems (IPC) between the Service and the Service Consumer
The Service Consumer is implemented in the Application context and it communicates with the Service by using an interprocess communication mechanism provided by the Server. The proposed model is independent from the particular device operating system and all the blocks can be implemented in any language. In particular the DDI Client implementation is based on a straightforward states interaction which can serve as a reference for other implementations.
The first implementation has been developed to serve Android OS based embedded devices. In fact, the lack of an OSS distribution model for Android OS and application updates, that could be used in other specific industries other than consumer context (smartphones), facilitates the adoption of existing OSS device management systems for embedded Android and IoT appliances. In this scenario we have seen the opportunity to use Eclipse hawkBit as the artifacts (Android apps and OS updates) content delivery platform and of course we needed to handle such artifacts on the device.
Because Android SDK is based on a JVM Runtime environment, we have decided to develop the DDI Client block neutral with respect to the operating system. In this way, the same code could be used in a Linux operating system. Of course the Service and the IPC towards the service consumer are Android specific, nevertheless a Linux based Service using DBUS as IPC can fit perfectly the reference design.
There are important aspects that has to be considered in the update process which can be applied to any other Platform/OS in particular related to the particular update strategy:
- Single copy update
- Dual copy update (A/B)
Nowadays due to the larger size in MMC memories, we have an increased number of devices implementing the redundant A/B double copy update. Our current Android client implementation supports both.
HawkBit is a device neutral platform and it can provision artifacts also to Microcotroller based embedded systems. Having identified a common artifacts management workflow it is possible to provide an implementation based on free RTOS by writing the just DDI Client block as a Task without the need of any other sophistication.
The hawkBit project has been released under the Eclipse IoT umbrella and of course we find such a place the perfect fit also for the Hara project as the last mile for implementing a complete Eclipse IoT OSS solution for handling software updates.
We don't have details about potential trademark conficts with the name Hara, we are open to change the name in case.
- 0.4.x already released
- Initial contribution for 1.0 expected: 11/2019
- First working and tested build of 1.0: 11/2010
- DDI Client and Service for QT
- Linux Service (Java) which uses the current implementation of the DDI Client
- Free RTOS DDI Client
- Log in to post comments