Acontis releases new EtherCAT motion library for QNX Neutrino operating system

This just in: Acontis, a leading provider of EtherCAT software and realtime hypervisor technology, has announced that its new EC-Motion product is now available for the QNX Neutrino operating system.

So what, exactly, is EC-Motion? In a nutshell, it's a C/C++ motion control library for EtherCAT drives (i.e. the electronic systems that control industrial motors).

According to Acontis, the EC-Motion library supports all of the single-axis movement commands specified in the PLCopen standard, eliminating the need for additional (and costly) hardware. It also allows the developer to:

• implement applications for multi-axis coordinated movements
• operate EtherCAT drives in cyclic synchronous position mode (CSP) or cyclic synchronous velocity (CSV) mode
• easily integrate the EC-Motion library into custom motion applications as well as into a programmable logic controller (PLC) runtime environment

Here's the EC-Motion architecture at a glance:



Demo on BeagleBone computer
Acontis also announced that it will demonstrate EC-Motion for QNX at the embedded world conference, from February 26 to 28 in Nuremberg. The demo will run on a BeagleBone, a credit-card-sized computer based on Sitara ARM AM335x Cortex-A8 processors from Texas Instruments. The demo will show a Yaskawa Sigma-5 EtherCAT drive running in cyclic synchronous velocity mode.

If you plan to attend embedded world, you can catch the demo at the IXXAT Automation GmbH stand, Hall 1/1-538.

For more details, read the Acontis press release.

10 truths about building safe embedded software systems

I wish I could remember his exact words. But it has been a long time — 20 years — and my memory has probably added words that he never wrote and removed words that he did write. That said, this is how I remember it:

"We all strive to write bug-free code. But in the real world, bugs can and do occur. Rather than pretend this isn't so, we should adopt a mission-critical mindset and create software architectures that can contain errors and recover from them intelligently."

The "he" in question is my late (and great) colleague Dan Hildebrand. I'm sure that Dan's original sentences were more nuanced and to the point. But the important thing is that he grokked the importance of "culture" when it comes to designing software for safety-critical systems. A culture in which the right attitudes and the right questions, not just the right techniques, are embraced and encouraged.

Which brings me to a paper written by my inimitable colleagues Chris Hobbs and Yi Zheng. It's titled "Ten truths about building safe embedded software systems" and, sure enough, the first truth is about culture. I quote:

"A safety culture is not only a culture in which engineers are permitted to raise questions related to safety, but a culture in which they are encouraged to think of each decision in that light..."

I was particularly delighted to read truth #5, which echoes Dan's advice with notable fidelity:

"Failures will occur: build a system that will recover or move to its design safe state..."

I also remember Dan writing about the importance of software architectures that allow you to diagnose and repair issues in a field-deployed system. Which brings us to truth #10:

"Our responsibility for a safe system does not end when the product is released. It continues until the last device and the last system are retired."

Dan argued for the importance of these truths in 1993. If anything, they are even more important today, when so much more depends on software. If you care about safe software design, you owe it to yourself to read the paper.

Using dynamic code analysis to support FDA approval

Making a safety case for what goes
in the case

It isn’t enough to create a medical device that is safe to use. You must also demonstrate that it meets safety requirements. Otherwise, how do you know that it is indeed safe? And how can you have it approved by the FDA, MDD, MHRA, or any other regulatory agency?

If you’re familiar with such agencies, you’ll know that they approve the device as a whole, not its constituent parts. And yet, the device manufacturer must still present evidence to demonstrate the dependability of the device software. Hence, close attention to software development practices — together with appropriate validation tools and techniques — is key to securing regulatory approval.

Enter dynamic code analysis. Unlike static analysis, which analyzes source or object code without executing it, dynamic analysis examines compiled code while it is running. As a result, it tests not only the source code, but also the compiler, the linker, the development environment, and, potentially, the target hardware. Dynamic analysis generally involves code coverage analysis and unit testing; together, these can provide an effective way to detect software errors and to demonstrate what software has been exercised.

If you’re interested in how dynamic code analysis can support demonstrations of compliance with safety requirements, look no further than the recent paper, Using Dynamic Software Analysis to Support Medical Device Approval, written by Chris Ault of QNX and Mark Pitchford of LRDA. Among other things, it reviews the key capabilities of dynamic analysis tools and provides tables that map development activities with requirements in the IEC 62304 standard for medical device software.