IoT devices pose a number of challenges for developers, including security concerns and having to work with limited hardware capabilities.
We spoke with François Baldassari of connected device specialist Memfault to find out why it might be better for IoT device developers and engineers to have the kinds of DevOps tools that only software teams traditionally have access to.
BN: How are development constraints different in software and hardware development, and what explains the gap in tooling?
FB: The development of embedded software is limited in all dimensions: power, CPU cycles, memory, storage and bandwidth. Additionally, embedded software developers must contend with device heterogeneity, including a wide range of processor architectures, operating systems, available peripherals, and connectivity stacks. This set of constraints and the diversity of media make it difficult to develop a coherent set of tools that can be used by a critical mass of engineers.
BN: Considering that some connected devices transmit very sensitive data, how can developers solve security issues with IoT devices?
FB: Security is poised to be the main topic of IoT over the next decade. Today, serious vulnerabilities can be found in microcontrollers, connectivity stacks, and operating systems. These have gone unanswered for too long, and it is only a matter of time before a major scandal erupts. Developers must adopt a more defensive posture on all of their projects. At the very least, this should include signing off for firmware updates, using hardware MPUs to mark writable memory as non-executable, and updating third-party libraries. Developers should also consider new programming languages such as Rust, which are less prone to certain classes of flaws.
BN: What are the main concerns of IoT device developers?
FB: The IoT developers I talk to are primarily concerned about three things:
- Security: The ubiquitous internet connectivity creates new security challenges that developers must face.
- Software complexity: Advanced techniques such as computer vision and machine learning are increasingly being deployed at the edge. This dramatically increases the complexity, making solving field problems much more difficult.
- Support: Many products were used once and for all. Today’s security and end-user expectations force companies to continually improve and iterate their products. This creates a staffing and tooling challenge.
BN: What approaches should developers consider to improve and secure their products?
FB: Developers need to iterate at a faster pace and put in place the infrastructure and processes to do it. It is no longer enough to update a product once a year, instead:
- Measuring performance in the field
- Send small updates frequently
- Track dependency improvements such as RTOS and libraries
It requires an initial investment in the observability and software update infrastructure, but the payoff is well worth it. The cycle of measurement -> improvement -> updating will lead to better and safer products.
BN: How does third-party code complicate device management?
FB: Today, third-party code is inevitable. It comes with the chips we use, provides essential functionality (such as connectivity), and is often the only way to deploy reasonable cryptography on a device. Device manufacturers need to understand what third-party code they are relying on, what license it is offered under, and what media is provided by its author. Since most third-party code is provided “as is,” make sure your engineers understand what the code is doing under the hood and can step in to fix bugs as they inevitably arise.
BN: In terms of the constraints you mentioned, how have embedded engineers traditionally solved for them and for the heterogeneity of systems?
FB: Traditionally, careful initial analysis has been used to appropriately provision different aspects of the system. Today, electrical engineers continue to do this work, but with much more uncertainty. Unable to accurately quantify the behavior of a machine learning system or computer vision algorithm, they end up having to over-provision things like RAM or battery. Otherwise, their software engineers will be faced with a potentially difficult task of optimizing the application to adapt to the constraints.
Regarding heterogeneity, the firmware was designed specifically for a given system. This meant that companies often started firmware development from scratch for each product. This was often more efficient than developing a robust material abstraction layer. Today, the math has changed as the software has become complex enough that starting from scratch is no longer an option.
BN: Beyond the system and hardware differences, are there other variations in how Embedded Device Engineers should approach development compared to their software counterparts?
FB: Yes, there are still a lot of differences:
- Open source is much less common, so more software has to be specially designed.
- Real-time behavior is much more important. Like graphics programming, embedded software is concerned with microseconds of execution. This excludes many common techniques such as automatic memory management.
- Sometimes physical systems fail. The embedded software engineer needs an intermediate understanding of electrical engineering to debug bus, power, and wireless issues.
- Most embedded systems do not include high level operating systems. File systems, sockets, and other abstractions cannot be taken for granted.
BN: What do you think is the most interesting use of ML and AI and device development right now?
FB: Many on-board systems take the following form: a sensor is connected to an MCU, which performs real-time processing and uploads the results to the cloud. It’s an ideal use case for machine learning. ML systems are surprisingly low in resources at runtime (most effort is spent on “training” the system upstream) and can perform much better on signal analysis than most algorithmic approaches. traditional. I foresee the ML will be used for speech recognition, gesture recognition, computer vision, and many other traditional sensing applications. Watch the work the Edge Impulse team is doing to see where the domain is heading.
Image credit: Jirsak / Shutterstock