Functional safety is no longer a “nice to have” or “should have” in many applications, having moved to “must have” in spaces like automotive, industrial automation, medical devices, and aviation. Passing the functional safety testing process can be rigorous, especially if you’re going through it for the first time. But even the best experts take at least six months to get software certified. 

To understand exactly what functional safety is, what the testing process is like, and how and when a developer should get started, I spoke to Bill Lamie, the President and CEO of PX5 RTOS, and someone who’s been through the rigors of functional safety testing on this week’s Embedded Executives podcast.

Hello Embedded Engineers, Developers and Makers! Welcome to In Case You Missed it: Embedded Insights, the weekly news show all about Embedded technologies and solutions from Embedded Computing Design.

In a world of disagreement, virtually all experienced software developers would agree that there can never be enough software testing! We have all experienced the feeling that the latest software release is defect-free, only to be confronted with yet another issue.

PX5 announced that PX5 FILE now supports the industry-standard FAT (File Allocation Table) file system format, sharing application data between other platforms from embedded devices to desktop computers. Designers have the capability to leverage PX5 FILE for real-time storage across RAM, FLASH, SD cards, etc.

In business, “table stakes” represents a minimum requirement to participate in a market. Today, there are over a hundred open-source and commercial RTOS in the embedded market. A vast majority of them don’t have functional safety certification. Given this, it’s evident that RTOS functional safety certification is not “table stakes” today, but maybe it should be!

Networking applications are an integral part of our daily lives, supporting efficient communication, enabling entertainment and collaboration, and providing access to information. For today’s computing networks and internet, developers creating these applications can benefit from standardized interfaces that allow network code to be written seamlessly across various systems, like real-time operating systems.

It’s midnight the day before the product release and your system just crashed. As you follow the execution back from the point of the fault, you find yourself deep inside the Real-Time Operating System (RTOS) code. If you don’t have professional support, your only option is to try and figure out why the RTOS is failing yourself. Of course, you have to first figure out how the RTOS works to even have a chance at understanding what is going wrong. If you are fortunate enough to figure this all out, you are then tasked with trying to fix the issue – and then ensure the fix is propagated back into the next 3^rd party RTOS release.