Over-the-air updates: in-house development or standard solution
Due to the increasing focus on IT security in the IoT sector, over-the-air updates are becoming an important core function for IoT devices. As with many other topics, the question here is: in-house development or standard solution? The right choice can have a significant impact on both the development of the product and from a financial and operational perspective.
This article first briefly compares aspects of development and operation and then analyses the costs of both variants. The focus is placed both on the one-off fixed costs and on the variable costs scaled with years of operation and devices.
Differences from a technical perspective
From a technical perspective, one of the most important points is the functional scope of the OTA solution (OTA = ‘over-the-air’). For the further development of the software, it is particularly relevant whether the changes can be retrofitted to target devices that have already been delivered. This is usually not a problem for pure software customisations. However, as IoT devices are usually delivered as a complete device, configuration must also be managed outside of the application. In the simplest case, for example, a compromised SSH key needs to be replaced; in (rare) more complex cases, new hardware interfaces need to be activated or other changes made to the operating system configuration.
During operation, the main focus is then on gaining insight into the status of a device and the efficient management of a large number of devices. For example, the following scenarios must be covered:
- A software version contains a critical security vulnerability. It must be determined as quickly as possible which devices have this version installed. These devices must also be updated to a new version immediately.
- An error has occurred in a newly released version. This must be removed from all devices immediately.
- A customer has a problem with the operation of their device. The error situation is not yet known and must be resolved. In this situation, it is important to know exactly which software version is in use on the affected device and when which changes were made.
Both from a development and operational perspective, there are some important requirements that must be supported in any case. In the case of specially developed OTA solutions, it is important to include these problems from the outset and to look for solutions despite the additional work involved. With standard solutions, these problems are in most cases already solved by the OTA software and therefore require no further consideration.
Maintenance of the OTA solution
The OTA solution itself must also be maintained. In the case of an in-house development, this maintenance must also be solved separately. This primarily includes the following topics:
Like the IoT devices themselves, the OTA software can also contain errors. These errors must be identified, rectified and rolled out. In this case, it may also be necessary to update part of the OTA solution on the IoT devices. Depending on the system, this can again be a challenge and increases complexity.
Furthermore, the OTA software usually also requires a server. This also means that an infrastructure has to be set up and maintained. Ideally, of course, ongoing data backups must also be created, as a loss of update data is usually a very costly affair.
With standard solutions, these problems are also already solved in most cases. In particular, the maintenance of the OTA software (including OTA clients) is entirely the responsibility of the provider of the standard solution and is therefore not the responsibility of the IoT manufacturer. Depending on the system, the infrastructure for standard solutions is handled either by the provider or the IoT manufacturer. A distinction is made here between so-called ‘OTA-as-a-Service’ and ‘on-premises’ solutions.
While the provider of the OTA software is responsible for the infrastructure including data backups in the OTA-as-a-Service variant, these issues are the responsibility of the IoT manufacturer in the case of on-premises offerings. Which variants are offered must be clarified in advance to ensure a smooth start.
Costs incurred
The resulting costs of the two variants also vary greatly. The costs for in-house development consist of two parts: in the first step, high initial expenditure is required to implement the software. In the next step, additional costs are incurred on an ongoing basis for the maintenance of the software. The exact costs for in-house development (as for any other software) are difficult to plan in detail. Unexpected additional costs can arise at any time due to unplanned delays. In most cases, these additional costs fall directly to the IoT manufacturer.
In contrast, standard solutions have costs that can be planned in detail. Depending on the provider, there are also initial and ongoing costs in this case. However, both can vary greatly. On the one hand, there are solutions where there are no initial costs and the initial expenses are covered by the running costs. On the other hand, there are also solutions where there is no service contract and therefore no ongoing costs. In this case, the provider lives purely from the initial costs for the software solution (although this variant is not really widespread among OTA solutions).
When does in-house development pay off?
In order to determine when an in-house development is worthwhile, a break-even analysis is carried out depending on the operating time (years) and number of devices (units). ARCANIX Configuration Management is used as a reference product for a standard solution.
The pricing model for ARCANIX Configuration Management consists of no initial costs, but ongoing maintenance fees. These include both the operation of the software and the provision of security fixes and new software versions. The fees depend on the number of devices used.
As a cost estimate for in-house development, 20 days of initial effort and 10 days of annual effort are calculated at a standard industry hourly rate of €90/development hour (this hourly rate may be lower for internal development teams). With a properly developed in-house solution, the number of devices is negligible, as these only scale the necessary server costs and these are negligible compared to the development effort.
With an observation period of 10 years (due to the rapid life cycle of software systems, 10 years is a rather long period for the maintenance of a device series), the following table results:
| Cost factor | In-house development | Standard solution | ||||
| 100 Devices | 500 Devices | 1000 Devices | 2500 Devices | 5000 Devices | ||
| Initial costs | 14 400 € | 0 € | 0 € | 0 € | 0 € | 0 € |
| Annual costs | 7 200 € | 600 € | 3 000 € | 6 000 € | 15 000 € | 30 000 € |
| Total (1 year) | 21 600 € | 600 € | 3 000 € | 6 000 € | 15 000 € | 30 000 € |
| Total (3 year) | 36 000 € | 1 800 € | 9 000 € | 18 000€ | 45 000€ | 90 000 € |
| Total (5 year) | 50 400 € | 3 000 € | 15 000 € | 30 000 € | 75 000 € | 150 000 € |
| Total (10 year) | 86 400 € | 6 000 € | 30 000 € | 60 000€ | 150 000€ | 300 000 € |
This shows that due to the high running costs of in-house development, the initial outlay is almost negligible. A break-even point is only reached when the running costs of the standard solution approach the maintenance costs of the in-house development. According to the model, this is only the case at around 1200 devices. From 3600 devices, the break-even point is already reached after the first year and the standard solution is not advisable. In practice, this calculation is somewhat more complex, as ARCANIX Configuration Management offers customised pricing models for more than 100 devices. These depend on the specific customer requirements. This shifts the break-even point significantly upwards.
The right choice for sustainable operating cost optimisation
The comparison between in-house development and standard solutions shows clear operating and cost differences. In terms of cost-effectiveness, standard solutions are more advantageous for most companies, provided there are no highly specialised requirements. In-house developments usually only pay off in one of two cases: If a very high number of devices need to be maintained or if the necessary functions are not mapped by any existing standard solution.
English 
German