Results collected as part of the Barr Group's annual Embedded Systems Design Survey raise serious worries about the safety of the small computers powering the myriad machines that make up our electronic worlds—from ATMs to thermostats to the systems inside of cars. The engineering consulting firm polled some 2,400 engineers, finding that a full third of respondents were either not designing to safety standards (22 percent) or had no idea whether they were or not (11 percent).
Moreover, of the polled engineers, 22 percent said they worked on systems that could kill. "We asked what was the worst thing that could happen if the device you are designing today were to malfunction in the field and more than 500 respondents said one or more people could die!," writes Barr Group co-founder and CEO Andrew Girson at EE Times. "Many of these respondents are in the industrial automation, medical device, automotive, and aerospace/defense industries."
Embedded systems are everywhere and make up a huge but undersung segment of the computing world. It's been estimated that some 98 percent of all microprocessors wind up in an embedded system, with the remainder making up the consumer devices we usually would call computers. "Embedded" generally means that a system is controlling some thing, some kind of a machine. You can imagine a modern (or even not so modern) airliner as a vast universe of these things, while the processor in a thermostat amounts to a relative particle. The things of the Internet of Things are all embedded systems, by definition.
"We asked what was the worst thing that could happen if the device you are designing today were to malfunction in the field and more than 500 respondents said one or more people could die!"
Programming embedded systems involves all kinds of fun challenges. Mostly, it's done via the most bare-bones reductions of the C programming language possible (Embedded C, generally), or even just whatever assembly language corresponds to the processor in question. Embedded software is supposed to be featherweight and is usually all about using the smallest amount of resources possible to do the most amount of computing work.
In a lot of ways, embedded programming is like the opposite of the overall software engineering trend toward assuming that machines have relatively unlimited physical computing resources. Programming languages get bulkier and more and more feature-rich, but the embedded world is still trying to build with skeletons. There's a certain nobility to it.
There's also a nobility in debugging and testing embedded systems. Relative to the stuff whirring away on your laptop or tablet right now, the consequences of failure in an embedded system are a whole different world. Specifically, a potentially deadly world. (Read about the THERAC-25 radiation therapy machine, for a classic example.)
It isn't that safety standards for embedded systems don't exist. The agencies that produce standards include (but are not limited to) the IEC, FDA, FAA, NHTSA, SAE, IEEE, and MISRA. They're out there, but are apparently being ignored 33 percent of the time.
It actually gets worse. Not only are standards being ignored, other best practices are as well, including static analysis (where code is examined line by line without actually running the program) and code review (where some other programmer inspects another programmer's code). From Barr directly: "Proactive techniques for increasing safety and security are used less often than they should be. Only 38 percent of respondents currently subject all their software source code to peer review, and respondents use static analysis tools in less than half of current projects."
"The fact is that we all need to acknowledge in this age of IoT that our devices are becoming more critical to the infrastructure of the world," Girson writes. "We all must devote the time, resources, and dollars to improving reliability. If we do so, in the long run, lives will be saved."
More detailed results from the survey will be presented in a webinar on March 8.