Why IoT developers need access to better tools [Q&A]

Internet of things

Internet of things devices pose a number of challenges for developers, not least security issues and having to work with limited hardware capability.

We talked to François Baldassari of connected device specialist Memfault to find out why it may be better if IoT device developers and engineers were to have the kinds of DevOps tools that only software teams have traditionally had access to.

BN: How are development constraints different in software and hardware development, and what accounts for the gap in tooling?

Advertisement

FB: Embedded software development is constrained in every dimension: power, CPU cycles, memory, storage, and bandwidth. Furthermore, embedded software developers have to contend with the heterogeneity of devices, including a wide range of CPU architectures, operating systems, available peripherals, and connectivity stacks. This set of constraints and diversity in medium make it difficult to develop a consistent set of tools that can be used by a critical mass of engineers.

BN: Considering that some connected devices transmit highly sensitive data, how can developers address security issues with IoT devices?

FB: Security is poised to be the single biggest topic in IoT this coming decade. Today, serious vulnerabilities can be found across microcontrollers, connectivity stacks, and operating systems. These have gone unaddressed for too long, and it is only a matter of time before a major scandal emerges. Developers must adopt a more defending posture on all of their projects. At the very least, this should include signing firmware updates, leveraging MPU hardware to mark writable memory as non-executable, and keeping 3rd party libraries up to date. Developers should also consider new programming languages such as Rust which are less prone to some class of defects.

BN: What are the chief concerns you hear from IoT device developers?

FB: IoT developers I talk to are concerned about three things first and foremost:

  • Security: ubiquitous internet connectivity is creating new security challenges developers must wrestle with.
  • Software complexity: advanced techniques such as computer vision and machine learning are increasingly deployed at the edge. This increases complexity significantly, which makes solving field issues much more difficult
  • Sustaining: many products used to be once and done. Today, security and end user expectations mean companies must continuously improve and iterate on their products. This creates a staffing and tooling challenge.

BN: What approaches should developers consider to improve and secure their products?

FB: Developers must iterate at a faster pace, and put the infrastructure and processes in place to do so. It is no longer enough to update a product once a year, and instead we must:

  • Measure performance in the field
  • Push small updates, frequently
  • Keep up with improvements in dependencies such as RTOSes and libraries

This requires upfront investment in observability and software update infrastructure, but the payoff is worth it. The cycle of measure -> improve -> update will lead to better, more secure products.

BN: How does third party code complicate device management?

FB: Today, third party code is inevitable. It comes bundled 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 makers must understand what third party code they depend on, what license it is offered under, and what support is provided by its author. Because most third party code is provided 'as-is' make sure your engineers understand what the code does under the hood, and can step in to fix bugs as they inevitably come up.

BN: In terms of the constraints you mentioned, how have embedded engineers traditionally solved for them and for heterogeneity in systems?

FB: Traditionally, careful upfront analysis was used to appropriately provision different aspects of the system. Today, electrical engineers continue to do this work, but with much more uncertainty. Unable to precisely quantify the behavior of a machine learning system, or a computer vision algorithm, they end up having to either over-provision things like RAM or battery. Otherwise, their software engineers will face a potentially difficult task optimizing the application to fit within the constraints.

Regarding heterogeneity, firmware used to be purpose built for a given system. This meant that companies often started firmware development from scratch for every product. This was often more effective than developing a robust hardware abstraction layer. Today, the calculus has changed as software has gotten complex enough that starting from scratch is no longer an option.

BN: Beyond system and hardware differences, are there other variations in how embedded device engineers have to approach development compared to their software counterparts?

FB: Yes, there still are many differences:

  • Open source is much less prevalent, so more software must be purpose-built.
  • Real-time behavior is much more important. Similarly to graphics programming, embedded software cares about microseconds of execution. This excludes many common techniques such as automatic memory management.
  • Physical systems sometimes fail. Embedded software engineer need an intermediate understanding of electrical engineering to debug buses, power, and wireless issues.
  • Most embedded systems do not include high level operating systems. Filesystems, sockets, and other abstractions cannot be taken for granted.

BN: What are you currently seeing as the most interesting use of ML and AI and device development?

FB: Many embedded systems take the following form: a sensor is connected to an MCU, which does some real time processing and uploads the results to the cloud. This is an ideal use case for machine learning. ML systems require surprisingly few resources at runtime (most of the effort is spent 'training' the system upfront) and can achieve much better results on signal analysis than most traditional algorithmic approaches. I anticipate ML to be used for speech recognition, gesture recognition, computer vision, and many other traditional sensing applications. Look to the work the team at Edge Impulse is doing to see where the field is headed.

Image credit: Jirsak / Shutterstock

Comments are closed.

© 1998-2022 BetaNews, Inc. All Rights Reserved. Privacy Policy - Cookie Policy.