Internet Of Things
Safeguarding embedded IoT software with DevOps monitoring
By Johan Kraft, CEO and founder of Percepio I
f you’re an embedded software or IoT device developer, chances are that DevOps is something you have read about but are not yet fully practicing. It is a set of software development practices focusing on short development cycles, frequent releases and rapid feedback, where development and operations are closely connected. It has been a real boost in other types of software development over the past decade, especially within cloud, mobile apps and games. But so far, uptake has been slow among embedded software and IoT device developers. There is every reason to believe that embedded developers stand to gain as much from DevOps as other types of developers, so in this article I will outline an important part of a DevOps strategy for embedded and IoT development, and the benefits it could bring.
But before I begin, let me state one thing: every software has bugs. There is academic research showing that for every 1000 lines of shipped code, 50–100 defects were introduced during development and about 5 per cent of them remain in deployment. Recognizing this and preparing for issues in deployment is a cornerstone of DevOps. This is achieved by systematic monitoring of the software in deployment.
The primary purpose of Internet of Things
Johan Kraft, CEO and founder of Percepio
(IoT) devices is to provide data and insights to improve the customer’s business, for instance through predictive maintenance of machinery. We can apply the same thinking to device software to learn how it performs in the field. This requires what we call a Device Feedback Loop, which is about DevOps monitoring for device software and provides the capability to report any kind of runtime issues in the devices back to the developers, together with diagnostic information that explains what happened. Reporting errors, in particular crashes, is probably the first thing that springs to mind. Crashes reported by customers can be hellishly difficult to analyze, as the received feedback often lacks sufficient detail to allow developers to reproduce the problem. A device feedback loop can alert you the moment a software failure occurs, without any human intervention, and give product teams the information they need to pinpoint the problem. This also allows for improving the testing, so you can avoid similar issues in the future.
Detecting anomalies with a feedback loop 30 March 2022 Components in Electronics
can also improve the security posture of IoT devices. For instance, random crashes might be due to a vulnerability being exploited in partially successful attacks, where malware is injected but accidentally causing a crash. Another type of anomaly is if the processor is running more than normal, which could be due to malicious activity in the device. Learning about such anomalies in the field makes it possible to find and fix the vulnerability at a much earlier stage and reduce the risk of major incidents like data breaches. Automated testing, another important DevOps practice, also benefits from having a device feedback loop. It becomes far easier to analyze crashes and other random issues by automatically collecting detailed diagnostics and reporting the issues to a centralized data management system, where all developers have access to it.
What to consider when
implementing a device feedback loop Implementing a device feedback loop from scratch is not trivial and there are many concerns to consider. I believe that a desirable
solution would include the following:
● Centralized data management to make it easy to collaborate and share diagnostic data within distributed teams, without the need for physical access to the device.
● Device developers should be able to extend and configure the monitoring as they see fit, without having to modify the data management system in the cloud.
● The collected data must survive crashes, even on microcontrollers without a regular file system, and should be uploaded automatically once restarted and reconnected.
● The monitoring must be efficient, with a minimal footprint and execution overhead.
● The monitoring should scale to large device fleets, by suitable data management and automated classification of reports, highlighting new issues that differ from previous reports.
● High security is a must. The solution should not create new attack surfaces and must follow best practices in cybersecurity.
● Issues should be traceable to specific versions of the code and specific
www.cieonline.co.uk
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54
