The Growing Importance of Safety-Critical Software in IoT

The Internet of Things introduces new, sometimes unanticipated, safety risks. 

Safety-critical applications, of course, have relied on software for decades. The Apollo flight program John F. Kennedy launched in 1961, for instance, used onboard flight software. But the proliferation of connected devices in industrial environments has enabled a world in which software runs core processes in jets, chemical and nuclear plants, building and public-safety alarms, and self-driving cars. 

Generally, the topic of cybersecurity overshadows issues of software quality. “I think the software world has woken up to security. I don’t think they’ve woken up yet to safety constraints,” said Kate Stewart, senior director of strategic programs at the Linux Foundation and a finalist for the IoT World Leader of the Year Award.

[IoT World is North America’s largest IoT event where strategists, technologists and implementers connect, putting IoT, AI, 5G and edge into action across industry verticals. Book your ticket now.]

When it comes to IoT and the blurring of digital and physical worlds that can transform operational efficiency and functionality of devices ranging from medical devices to military equipment. But innovation is also fueling a collision course of software development paradigms, as cybersecurity pundit Bruce Schneier wrote in “Click Here to Kill Everybody: Security and Survival in a Hyper-connected World.” 

One the one hand, there’s the agile software development paradigm prioritizes speed and adaptability. On the other is the slow-moving software-development methodology found in the aerospace, industrial, medical and medical fields. “This is the world of rigorous testing, or security certifications, and licensed engineers,” Schneier wrote.

At the Linux Foundation, one of Stewart’s focus areas is the Zephyr Project, which developed a real-time operating system that prioritizes safety and security for resource-constrained devices. 

“In Internet of Things, people focus their lens on what they’re comfortable with,” Stewart said. “I focus on the deep embedded side and collecting data safely and securely.” The latter involves collaborating with safety experts who are not traditionally focused on software. “A lot of the language around the existing standards in the safety field is 20 to 30 years old,” she said. And the elements that are related to software are often outdated, given the change in software development methodology and increases in code volume since. 

One challenge is the sometimes fuzzy question of how a software update might cause unexpected safety-related problems. Software developers working in critical infrastructure do considerable analysis before they release software. “When you are doing a lot of security updates to that software, does that invalidate your initial analysis? What do you need to do to make sure that by applying a bug or security fix that you’re not going to be making things worse? We don’t necessarily have the best tools right now for figuring that out,” Stewart said. 

Another hurdle is the traditionally closed nature of security standards. “There are a whole series of [safety] standards right now that everyone looks to, and the interesting challenge from an open source perspective is that these standards are all closed,” Stewart said. “Open source developers don’t necessarily want to be paying $3,000 to look at the standards.” 

Such challenges provide a reason for further collaboration between safety, regulatory and software experts, Stewart said. “We’re working right now with people who [specialize in safety] and at the various certification authorities, as well as potentially some of the regulations to understand what’s really important, and how we make safe software development practical for everyone.”