The Internet of Things has many faces: devices, machines, vehicles, sensors, actuators and even RFID chips are all part of IoT. Programming embedded software is however often more difficult than conventional software development and is also more error-prone as very little memory is available, as the effort required for updates is disproportionately higher for a large number of global devices and because the most important factor, security, is sometimes left out. In some cases, developers also lack the necessary skills, especially since IoT must combine more and more knowledge in various disciplines such as internet protocols, databases, cloud computing and mobile applications.
This shows how complex IoT software development is. IT managers and IoT software developers should therefore be prepared accordingly. The following dos and don’ts give practical advice on what to consider and what not to do when developing embedded software.
Safety first: According to the figures of the Honeypot Analysis by IT security specialist Kaspersky, in the first half of 2019 there were 105 million cases of cyber-attacks on IoT devices, nine times as many as in the same period last year. This makes end-to-end or continuous encryption from sensor to cloud and secure device authentication, e.g. via device certificates, all the more important.
Automated testing: Ongoing automated testing should be part of the budget planning and is important to ensure the functionality of software throughout the entire life cycle of the IoT device.
Continuous integration: By continuously assembling and testing components, software quality can be increased significantly. At the same time, continuous integration is the basis for automated software deployment, providing the lowest possible downtime thanks to integration problems being detected early on.
Standards: Companies should rely on widely used protocols and standards such as MQTT or OPC UA for IoT software development to ensure future-security and continuous updates and to avoid possible vendor lock-ins. The industry-wide trend is also clearly moving in the direction of standardized protocols.
Sufficient budgeting: IoT projects in industry and other vertical markets do not appear out of the blue. In software development, costs for corrections, adjustments and for later updates and testing must be “priced in”. That’s why: it’s better to plan a little more budget, since IoT software has to support devices in the field over longer periods of time. On the other hand, the added value of an IoT project quickly becomes apparent.
Proprietary protocols: Manufacturer-specific protocols should be avoided in IoT projects. Instead, developers should focus on open standards to ensure interoperability and scalability of the IoT infrastructure.
Unscheduled security adjustments through patches can take their revenge later, as this makes it difficult to close security holes afterwards. Devices must have a secure update mechanism.
Test automation with existing equipment often proves difficult because access is usually blocked by firewalls. It is therefore better to test in simulation environments.
In the IoT world, error diagnosis via classic logs or log files is made more difficult by the fact that there are usually a large number of devices. More often than not, there is also a gateway connection in between. According to Dev-Insider, logs must therefore be made available centrally in a targeted manner, especially since there is sometimes less storage space available on the devices themselves. A possible solution to the problem is a central log database (or syslog-ng).
Getting lost in unnecessary features: Programmers can tend to lose the thread in a plethora of features instead of concentrating on the essential items. In this case – less is definitely more. The user experience is more important than having a large variety of features.
As the dos and don’ts listed here show, there are sometimes serious differences between classical software development and that for IoT devices. In both cases, however, safety is the be-all and end-all. Ease of use is often treated as a secondary consideration but should also be at the top of the list. Continuous automatic testing is also important, preferably in simulated environments rather than on devices themselves. This allows sources of error to be eliminated quickly and at the same time does not impede ongoing production.