In our view, this can be remedied by developing a holistic update management solution that expands the functional scope of available OTA systems. The associated issues and challenges will be examined step by step in this multi-part blog post series. In part 1 of the blog post series, we focus on the problems of classic OTA systems and the organizational model of this update management solution.
Software updates have been an integral part of our smartphone generation for many years. While software updates were initially wired and manually transferred to a mobile device by the user, today we benefit greatly from the wireless connectivity of our smartphones. When software updates are transferred via a wireless interface (e.g. mobile radio or WLAN), they are generally referred to as over-the-air (OTA) updates. In this way, security-relevant software updates or general optimizations of the operating system and application software can be transferred to end devices in short cycles. And usually without user interaction.
"Over-The-Air Update is a Capabilitywhich allows software and configurations to be updated remotely via a network."
Loris Ducrée, OTA expert at doubleSlash
As many devices are now equipped with a wireless interface, OTA updates have also become increasingly important in the fields of industrial equipment, household appliances, medical technology and the automotive sector. In many cases, companies decide to develop a software solution adapted to their product portfolio for the distribution of OTA updates. The focus is often primarily on the development of basic/technical components, for example to enable secure communication with the devices or secure transmission of software artefacts via encrypted communication channels.
The development of an OTA system inevitably requires a lot of resources, but to a certain extent (like other companies) reinventing the wheel.
What is usually neglected at the end of the development phase, however, is the general management of software artifacts with regard to
- their distribution over time on the basis of a predefined campaign plan
- their dependencies on each other or
- their compatibility with the devices
- their validation and release before productive delivery to devices
- their availability to certain customer groups in connection with subscription business models (for example, certain software artifacts may only be available to a subset of all customers because they have taken out a corresponding subscription)
- their admissibility in certain markets due to any applicable market regulations
In our view, an OTA system can only be used sustainably with such modules. At this point, we are talking about an update management solution that builds on or integrates one or even several existing OTA systems without having to develop them from scratch.
Basic OTA functionalities (in particular direct communication with the devices and the delivery of software updates) are provided as usual by connected OTA systems. Missing functionalities for the organization of software updates are in turn provided by the update management solution.
Organizational model
The creation of a sustainable and holistic update management solution requires a clear organization. In our view, the following roles are required for this:
The role of the Artifact developer provides for the development of software artifacts for specific device components, such as control units. Artifact developers act as external interface partners for the update management solution and provide the software artifacts they have developed and versioned. The often very technical hardware and software requirements known to the artifact developer (e.g. compatibility with device components) are supplied in the form of metadata.
As soon as software artifacts are available, these can be Release manager are compiled and managed to form a release. If a total of 5 device components need to be updated to implement a certain feature (e.g. activating a voice assistant via a multifunction steering wheel), the functional release could reference 5 different software artifacts in certain versions. This activity may require a certain amount of technical expertise in order to be able to select only the required and, above all, mutually compatible software artefacts from all existing software artefacts.
After completion, the release manager transfers the release to the Test managerwho can test the release and then approve it. Ideally, these tests are automated as far as possible and applied to as many devices and their variants as possible in order to increase the validity of the test results. The primary goal of this validation phase is the subsequent delivery of the software artifacts of a release with the lowest possible error rate. This is because a high error rate due to inadequate validation can have serious consequences:
- High costs for repairing or replacing devices if they are damaged by faulty software artifacts.
- Loss of trust from device users if software updates are not available or if the functionality of devices is restricted by faulty software artifacts.
- High costs to MNO (Mobile Network Operator) for data transmission, even if delivered software artifacts are not functional.
Secured and released releases can now be accessed through the Campaign manager are delivered to device groups. Examples of such device groups are
- All devices of a specific model in the "Germany" market
- All devices of a specific customer
- All devices with certain software versions
- ...
If an automated compatibility check shows that the release to be delivered or the software artefacts it contains are not compatible with the devices in a device group, the release must be adapted accordingly by the release manager and then validated and released again by the test manager.
If, however, unexpected and not immediately rectifiable faults occur in the devices during delivery, it may be necessary to use an authorized service technician. Service technician required. As a rule, affected device owners must visit an authorized workshop, for example, in order to restore the full functionality of their devices.
The focus of the entire update management solution is on the satisfaction of the Device owner. They primarily benefit from product improvements and new functions that are made available to their devices in short cycles. A prolonged absence of software updates or even damage to devices due to faulty software updates inevitably leads to a loss of trust and rejection of the device manufacturer.
The continuous further development and operation of the update management solution itself is carried out by the DevOps Team.
As, for example, direct data transfer / communication with the devices and the management of these devices are not the focus of the update management solution, suitable Interfaces connected. These include interfaces to OTA systems, device management systems, CRM systems, subscription management systems and artifact repositories.
Conclusion
In part 1 of the blog post series, we learned the following:
- The continuous optimization of devices through OTA updates is becoming increasingly important in many industries.
- Although numerous OTA systems already exist, they usually have a similar and insufficient range of functions with regard to the management of software artifacts.
- The creation of a holistic update management solution offers high added value in the long term.
- The integration of existing OTA systems as the foundation of the update management solution significantly reduces development costs.
- The creation of a sustainable and holistic update management solution requires a clear definition of the roles involved.
In the next part of this blog post series, the relevant process steps and the data model, including its technical components, will be presented.
