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.

Space-grade technology... in the palm of your hand

What does your phone have in common with planes, trains, automobiles, and space stations? If it's a BlackBerry 10 smartphone, plenty.

When you pick up a BlackBerry Z10 or BlackBerry Q10 phone, you are tapping into OS technology like no other. Technology that hospitals use to defeat cancer. Technology that power plants use to create energy. Technology that skyscrapers use to save energy. Technology that movie studios use to create mind-blowing special effects. And technology that calls for help if your car gets into an accident. In short, technology that makes a difference in my life, your life, everyone's life.

But enough from me. Especially when the video says it so much better...

Can a safety-critical system be over-engineered?

Too much of a good thing?

It's a rhetorical question, of course. But hear me out.

As you can imagine, many safe systems must be designed to handle scenarios outside their intended scope. For instance, in many jurisdictions, passenger elevators must be capable of handling 11 times more weight than their recommended maximum — you just never know what people will haul into an elevator car. So, if the stated limit for a passenger elevator is 2000 pounds, the actual limit is closer to 22,000 pounds. (Do me a favor and avoid the temptation to test this for yourself.)

Nonetheless, over-engineering can sometimes be too much of a good thing. This is especially true when an over-engineered component imposes an unanticipated stress on the larger system. In fact, focusing on a specific safety issue without considering overall system dependability can sometimes yield little or no benefit — or even introduce new problems. The engineer must always keep the big picture in mind.

Case in point: the SS Eastland. In 1915 this passenger ship rolled over, killing more than 840 passengers and crew. The Eastland Memorial Society explains what happened:

"...the Eastland's top-heaviness was largely due to the amount and weight of the lifeboats required on her... after the sinking of the Titanic in 1912, a general panic led to the irrational demand for more lifesaving lifeboat capacity for passengers of ships.

Lawmakers unfamiliar with naval engineering did not realize that lifeboats cannot always save all lives, if they can save any at all. In conformance to new safety provisions of the 1915 Seaman’s Act, the lifeboats had been added to a ship already known to list easily... lifeboats made the Eastland less not more safe..."

There you have it. A well-intentioned safety feature that achieved the very opposite of its intended purpose.

Fast forward to the 21st century. Recently, my colleague Chris Hobbs wrote a whitepaper on how a narrow design approach can subtly work its way into engineering decisions. Here's the scenario he uses for discussion:

"The system is a very simple, hypothetical in-cab controller (for an equally hypothetical) ATO system running a driverless Light Rapid Transit (LRT) system...

Our hypothetical controller has already proven itself in Rome and several other locations. Now a new customer is considering it for an LRT ATO in the La Paz-El Alto metropolitan area in Bolivia. La Paz-El Alto has almost 2.5 million inhabitants living at an elevation that rises above 4,100 meters (13,600 ft.—higher than Mount Erebus). This is a significant change in context, because the threat of soft and hard memory errors caused by cosmic rays increases with elevation. The customer asks for proof that our system can still meet its safety requirements when the risk of soft memory errors caused by radiation is included in our dependability estimates..."

So where should the engineer go from here? How can he or she ensure that the right concerns are being addressed? That is what Chris endeavours to answer. (Spoiler alert: The paper determines that, in this hypothetical case, software detection of soft memory errors isn't a particularly useful solution.)

Highly recommended.

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.

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?)