Five QNX videos more people ought to see

Looking for examples of how people use QNX? You've come to the right place. From outer space to the automotive space, these five videos demonstrate the sheer flexibility and dynamic range of QNX technology. Better yet, you get to hear five users describe, in their own words, why QNX is important to what they do.

QNX in space
First up is Iain Christie of Neptec, the company responsible for creating the SVS and LCS camera systems on the NASA space shuttle. Highlight: when Ian explains the importance of QNX to the shuttle program (1:46). For more on the QNX-based LCS system, see my previous post.



QNX in the clinic
Next up is Vladimir Derenchuk of the Indiana University Health Proton Therapy Center, which uses proton beams to blast difficult-to-treat tumors. Highlight: it's all good, but listen to Vladimir explain why they chose QNX, and how it has helped with FDA approvals (1:34).



QNX in the HVAC
Next up is Hans Symanczik of Kieback & Peter, a German firm that has used QNX in building automation systems for more than 20 years. Highlight: when Hans explains the ultimate benefit of the QNX OS (2:07).



QNX on the air
Next up is Mikael Vest of NTP, a Danish company that supplies QNX-based audio routers to the global television and radio broadcasting industry. Highlight: Mikael himself, who gladly did this interview despite suffering from a flu to end all flus. A real trooper.



QNX on the road
Next up is Rick Kreifeldt of Harman International, a company known in the automotive industry for its ability to push the technology envelope. Highlight: the section where Rick's respect for the QNX team shines through (2:14).



QNX in flight
And last but not least is Thomas Allen from Mechtronix, a company that has developed an innovative, software-based approach to building flight simulators. Highlight: when Allen states that Mechtronix simulators effectively use the same software architecture as the QNX OS (0:45). Years, ago, someone explained to me how the QNX OS isn't simply a well-designed, modular OS; it also encourages well-designed, modular systems. In Mechtronix, we have an example.

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.

QNX versus Linux: Which is best for IEC 62304 medical devices?

A few weeks ago, I invited you to a webinar on this very topic. If you missed the webinar, no worries: the archived version is now available for download. And speaking of downloads, you can now read the accompanying whitepaper, written by my inimitable colleague Chris Hobbs.

If you're wondering whether the paper is for you, here's the official summary:

This paper is for anyone who must select an OS for a safety-critical medical system. It provides information to help with estimates of the real cost of choosing a Linux or QNX OS. It lists requirements identified by standards such as IEC 62304, ISO 14971 and IEC 61508, and offers comparative estimates of the effort required to meet these requirements. These estimates are for initial certification and pre-approval, subsequent re-certifications following OS upgrades, and ongoing costs.

While you're at it, check out these other whitepapers for medical-device developers:

• Clear SOUP and COTS Software for Medical Device Development
• Persistent Publish/Subscribe Messaging in Medical Devices
• Choosing an RTOS for Remote-care Medical Devices

Come to think of it, there's no reason to stop with these, when you can peruse the entire library of medical whitepapers on the QNX website.

Which OS for IEC 62304 medical systems?

The question, to some degree, is rhetorical. I work for an OS company, that company has developed a 62304-compliant OS for medical device manufacturers... you see where this is going.

But don't go yet. This week, my colleague Chris Ault will present a webinar on this very topic, and the content he'll cover should prove useful to anyone choosing an OS for a medical device — or, for that matter, any device that must operate reliably and safely.

In case you're wondering, the Linux question will definitely come up. Linux does lots of things very well, but does it belong in a safety-critical device? Knowing Chris, he'll offer a suitably unambiguous answer — and some solid reasoning to back it up.

Okay, enough from me. To learn more about the webinar, which will be held this
Thursday, September 27, at 2 pm eastern, visit the QNX website.

Qt Creator 2.6 introduces QNX support

This just in: The Qt developer blog has announced a new release of Qt Creator, the integrated development environment for creating applications and user interfaces based on the Qt application framework. (If you're unfamiliar with Qt, check out these previous posts.)

The new release, version 2.6, is now in beta and introduces two key features: support for the QNX OS and a concept called kits.

According to Eike Ziller of the Qt developer blog, a kit is a user-defined combination of compiler, debugger, Qt version, and target device. As a developer, you can freely choose each kit setting independent of all other settings. For instance, you can mix and match compilers and Qt versions. Qt Creator will warn you if it thinks you're choosing a dumb combination, but otherwise gives you free rein over the configuration.

Kits are new to 2.6 and they replace a concept called targets. Targets served a similar function, but were "hardwired". If you deviated from the default setting of a target, you had to manually change all build and run configurations. But now, with targets, the IDE makes these changes for you.

Qt Creator 2.6 supports both QNX and Android, but doesn't support Symbian. According to Ziller, Symbian support had to be dropped because of a lack of maintainers.

Here's a screen capture of the Kit Preferences dialog:



For details on Qt Creator 2.6, visit the Qt developer blog.
 

Video: QNX-powered system fires protons to kill cancer

The QNX-powered proton therapy 
system, or PTS

It zaps cancer cells to kingdom come. Better yet, it wipes them out while leaving healthy cells alone. It's called proton therapy, and it's one of the deadliest weapons in the arsenal against cancer.

Conventional radiotherapy may be potent, but it has a drawback. It can sometimes damage healthy tissue, and this damage can lead to secondary cancers later in life — a problem among children, who may live for many years after treatment and who are more likely to suffer from this side-effect.

There is, then, a real need to avoid radiating healthy tissue while maximizing the damage to the diseased tissue. And that's where proton therapy comes in.

Surgical strikes
Protons are relatively heavy, charged particles. They do minimal damage as they pass through tissue, but inflict significant damage where they stop. The challenge is to control the proton beams so that they stop exactly where you want them — the tumor.

Enter the QNX-powered proton therapy system (PTS) at the Indiana University Health Proton Therapy Center. Using the PTS, a radiotherapist can limit damage mostly to where the tumor is located. The radiotherapist can even "mold" the proton beam into the same shape as the tumor. This accuracy makes proton therapy especially useful for treating tumors located near vital organs. It can also reduce long-term effects sometimes associated with conventional forms of radiotherapy. And it serves as an alternative for patients who have already received other forms of treatment and have incurred damage to healthy tissue as a result — proton therapy can minimize the possibility that more healthy tissue is affected.

Delivering the right dose
The PTS uses the QNX OS in its dose delivery system (DDS) — think of it as the business end of the PTS. The DDS controls devices on the system’s nozzle (the beam transport and detection hardware closest to the patient) and measures dose-related values. The DDS also implements an energy-stacking scheme to obtain uniform depth-dose distributions.

The QNX OS allows the DDS to achieve very fast response times. For instance, if beam delivery must stop for any reason, the OS helps ensure that it stops immediately — and in this application, immediately is the only viable option.



I'm feeling appreciative
Before I let you go, a word of thanks to the folks at the proton therapy center. A year ago, I approached them out of nowhere with a proposal to do a video. Their response was overwhelmingly positive. They willingly gave of their time to discuss the proposal, explain what they do, and, of course, work with us on the video itself. While I'm at it, I'd also like to thank my friend and colleague Nancy Young for her fantastic work on this and all the other QNX videos she has produced in the last couple of years. (Speaking of which, have you subscribed to the QNX YouTube channel yet?)