From clean socks to secure transactions, QNX brings it all to Embedded World

Every year, QNX Software Systems exhibits at the Embedded World conference in Nuremburg. And every year, we like to mix things up and do something different. For instance, in years past, we have showcased a robotic vacuum, a heart defibrillator, a pipeline inspection system, an Oscar-winning flying camera, a programmable logic controller, and a control panel for bulldozers — all running on the QNX Neutrino OS.

What have we got lined up this year? Plenty, as it turns out. Once again, our booth will feature several QNX-based products, including:

• An innovative double-drum washing machine that cleans two loads of laundry simultaneously — finally, you can wash lights and darks at the same time!
• A Modular Train Control System (MTCS) from MEN Mikro Elektronik that complies with the EN 50155 functional safety standard and is based on the QNX OS for Safety
• A hardware security module from Worldline that protects secret keys and performs high-speed cryptographic operations for secure data transactions
• A traffic-light controller from SWARCO that helps improve traffic flow and optimizes the use of existing road infrastructure — learn more about this system in this morning’s press release

It’s hard to imagine four systems that could be more different. And yet, the developers of these systems all chose the same OS — a testament to the “bend it, shape it, any way you want it” quality of QNX technology. Not to mention its performance and reliability.

The Bluetooth connection
Of course, we can’t show up at Europe’s biggest embedded systems conference without bringing something new for embedded developers. And so, this year, we are demonstrating the QNX SDK for Bluetooth Connectivity, a new middleware solution for medical devices, industrial automation systems, consumer appliances, and other embedded system applications.

Designed for flexibility, the SDK offers a dual-mode Bluetooth Smart Ready stack that supports classic Bluetooth connectivity as well as connectivity to Bluetooth Low Energy devices. It also supports a comprehensive set of pre-integrated Bluetooth profiles, including the classic PAN, SPP, HDP, HID, FTP, and OPP profiles, as well as the BAS, FMP, HRP, HOGP, and PXP Low Energy profiles. Here’s the SDK at a glance:

For developers of infusion pumps, vital-sign monitors, and other medical devices, the SDK includes an IEEE 11073 Personal Health Data stack certified by the Continua Health Alliance. This stack enables easy interoperability with pulse oximeters, weight scales, and other Bluetooth-enabled peripherals, and addresses the growing demand for health devices that can wirelessly collect patient data, either at home or in a clinical setting.

Of course, the proof of the Bluetooth pudding is in the pairing. So we've also built a demo that shows how the SDK can help developers build vital-sign monitors and other connected embedded systems. The demo system can discover and pair with Bluetooth classic and Bluetooth Low Energy devices, render their data onto a touchscreen display based on Qt 5, and provide a history of heart rate, blood oxygen levels, and other vitals:

A screen capture of the Bluetooth-powered QNX medical demo

Read the press release and product-overview page to learn more about the new QNX SDK for Bluetooth Connectivity.

And if you are Nuremberg this week, drop by and see us! We’re in Hall 4, Booth 534.

Developing software for safety-critical systems? This book is for you

In-depth volume covers development of systems under the IEC 61508, ISO 26262, EN 50128, and IEC 62304 standards

In June, I told you of an upcoming book by my colleague Chris Hobbs, who works as a software safety specialist here at QNX Software Systems. Well, I’m happy to say that the book is now available. It’s called Embedded Software Development for Safety-Critical Systems and it explores design practices for building medical devices, railway control systems, industrial control systems, and, of course, automotive ADAS devices.

The book:

• covers the development of safety-critical systems under ISO 26262, IEC 61508, EN 50128, and IEC 62304
• helps developers learn how to justify their work to external auditors
• discusses the advantages and disadvantages of architectural and design practices recommended in the standards, including replication and diversification, anomaly detection, and so-called “safety bag” systems
• examines the use of open-source components in safety-critical systems

Interested? I invite to you to visit the CRC Press website, where you can view the full Table of Contents and, of course, order the book.

A version of this post originally appeared on the QNX Auto Blog.

Developing software for safety-critical systems? Have I got a book for you

Chris Hobbs is the only person I know who holds a math degree with a specialization in mathematical philosophy. In fact, before I met him, I didn’t know such a thing even existed. But guess what? That’s one of the things I really like about Chris. The more I hang out with him, the more I learn.

Come to think of it, helping people learn has become something of a specialty for Chris. He is, for example, a flying instructor and the author of Flying Beyond: The Canadian Commercial Pilot Textbook. And, as a software safety specialist at QNX Software Systems, he regularly provides advice to customers building systems that must comply with functional safety standards like IEC 61508, EN 5012x, and ISO 26262.

Chris has already written a number of papers on software safety, some of which I have had the great privilege to edit. You can find several of them on the QNX website. But recently, Chris upped the ante and wrote an entire book on the subject, titled Embedded Software Development for Safety-Critical Systems. The book:

• covers the development of safety-critical systems under ISO 26262, IEC 61508, EN 50128, and IEC 62304
• helps readers understand and apply remarkably esoteric development practices and be prepared to justify their work to external auditors
• discusses the advantages and disadvantages of architectural and design practices recommended in the standards, including replication and diversification, anomaly detection, and so-called “safety bag” systems
• examines the use of open-source components in safety-critical systems

I haven’t yet had a chance to review the book, but at 358 pages, it promises to be a substantial read.

Interested? Well, you can’t get the book just yet. But you can pre-order it today and get one of the first copies off the press. It’s scheduled for release September 1.

A version of this post appeared in the QNX Auto Blog.

Hypervisors, virtualization, and creating a safety-critical system that keeps up with the Joneses

A new webinar on how virtualization can help you add new technology to existing designs.

First things first: should you say “hypervisor” or “virtual machine monitor”? Both terms refer to the same thing, but is one preferable to the other?

Hypervisor certainly has the greater sex appeal, suggesting it was coined by a marketing department that saw no hope in promoting a term as coldly technical as virtual machine monitor. But, in fact, hypervisor has a long and established history, dating back almost 50 years. Moreover, it was coined not by a marketing department, but by a software developer.

“Hypervisor” is simply a variant of “supervisor,” a traditional name for the software that controls task scheduling and other fundamental operations in a computer system — software that, in most systems, is now called the OS kernel. Because a hypervisor manages the execution of multiple OSs, it is, in effect, a supervisor of supervisors. Hence hypervisor.

No matter what you call it, a hypervisor creates multiple virtual machines, each hosting a separate guest OS, and allows the OSs to share a system’s hardware resources, including CPU, memory, and I/O. As a result, system designers can consolidate previously discrete systems onto a single system-on-chip (SoC) and thereby reduce the size, weight, and power consumption of their designs — a trinity of benefits known as SWaP.

The QNX Hypervisor is an example of a 

Type 1 “bare metal” hypervisor.

That said, not all hypervisors are created equal. There are, for example, Type 1 “bare metal” hypervisors, which run directly on the host hardware, and Type 2 hypervisors, which run on top of an OS. Both types have their benefits, but Type 1 offers the better choice for any embedded system that requires fast, predictable response times — most safety-critical systems arguably fall within this category.

Moreover, some hypervisors make it easier for the guest OSs to share hardware resources. The QNX Hypervisor, for example, employs several technologies to simplify the sharing of display controllers, network connections, file systems, and I/O devices like the I2C serial bus. Developers can, as a result, avoid writing custom shared-device drivers that increase testing and certification costs and that typically exhibit lower performance than field-hardened, vendor-supplied drivers.

Adding features, without blowing the certification budget
Hypervisors, and the virtualization they provide, offer another benefit: the ability to keep OSs cleanly isolated from each other, even though they share the same hardware. This benefit is attractive to anyone trying to build a safety-critical system and reduce SWaP. Better yet, the virtualization can help device makers add new and differentiating features, such as rich user interfaces, without compromising safety-critical components.

That said, hardware and peripheral device interfaces are evolving continuously. How can you maintain compliance with safety-related standards like ISO 26262 and still take advantage of new hardware features and functionality?

Enter a new webinar hosted by my inimitable colleague Chris Ault. Chris will examine techniques that enable you to add new features to existing devices, while maintaining close control of the safety certification scope and budget. Here are some of the topics he’ll address:

• Overview of virtualization options and their pros and cons
   
• Comparison of how adaptive time partitioning and virtualization help achieve separation of safety-critical systems
   
• Maintaining realtime performance of industrial automation protocols without directly affecting safety certification efforts
   
• Using Android applications for user interfaces and connectivity

Webinar coordinates:
Exploring Virtualization Options for Adding New Technology to Safety-Critical Devices
Time: Thursday, March 5, 12:00 pm EST
Duration: 1 hour
Registration: Visit TechOnLine

A version of this post was published on the QNX Auto Blog.

Autonomous forklifts gear up with QNX and HTML5

Warehouse robots need reliable realtime control. They also need an intuitive user interface. Can one OS handle both?

When it comes to forklifts, I am as dumb as they come. I had always assumed that one forklift is much like any other, aside from obvious differences in size and color. Boy, did I get that wrong. A quick perusal of Wikipedia reveals some 30 forklift types, ranging from “walkie stackers” (which, true to their name, are walked, not ridden) to “EX-rated lift trucks” (which, contrary to their name, aren’t designed to carry erotica but to be explosion proof).

Forklifts also come in driverless variants called automated guided vehicles, or AGVs. Case in point: the QNX-powered AGVs built by Euroimpianti, a global leader in automated warehouse systems. These vehicles can, without human intervention, load and unload trucks, as well as move materials from one area of a warehouse or factory to another. Moreover, they can operate 24/7, using a list of prioritized missions downloaded from a central management system.

As you might expect, Euroimpianti uses the QNX Neutrino OS in the realtime control systems of its AGVs. After all, predictable response times and high reliability — qualities essential to safe operation of a driverless vehicle in a busy warehouse — are QNX Neutrino’s stock-in-trade.

But here’s the thing: Euroimpianti has also decided to standardize on QNX Neutrino for the human machine interfaces (HMIs) of its operator panels. Why do that, when the HMIs could run on an OS like Windows Embedded or Android? The answer lies in the many features introduced in the QNX Neutrino OS 6.6 and the new QNX SDK for Apps and Media.

These features include a framework for creating apps and HMIs with industry-standard technologies like HTML5, JavaScript, and CSS, and a graphical composition manager that can seamlessly blend apps and graphical components created in HTML5, OpenGL ES, Qt, and other environments, all on the same display. In addition, the SDK offers secure application management, comprehensive multimedia support, mobile device connectivity, an optimized HTML5 engine, and other features for building mobile-class user experiences into embedded systems — including, of course, AGVs.

To quote Maurizio Calgaro, electronic engineering manager, Euroimpianti, “With its new QNX SDK for Apps and Media, QNX Neutrino enables us to create dynamic HMIs that leverage the latest Web technologies, including HTML5. Our operator panels and control systems can now run on the same, standards-based OS, and that means greater productivity for our developers and, ultimately, faster time-to-market for our solutions.”

The QNX SDK for Apps and Media includes an HTML5 environment to create and deploy applications.

Euroimpianti's QNX-based robotic systems also include Cartesian robots, anthropomorphic robots, and selective compliance assembly robot arms (SCARA). The systems are deployed internationally in the automotive, beverage, cosmetic, food, dairy, electrical, glass, and pharmaceutical industries. Learn more on the Euroimpianti Website, which includes many videos of the robots in action.

Using the same OS for both realtime control and user interface control.

Bend it, shape it, any way you want it

Last year, at Embedded World 2014, QNX Software Systems demonstrated three systems built by its customers: a touch display that connects washing machines to the Web, an operator panel that controls forklifts and bulldozers, and an inspection system that detects cracks in gas pipelines. These systems perform very different functions, and operate in very different environments, yet they have one thing in common: the QNX Neutrino OS.

Fast-forward to Embedded World 2015, where, once again, QNX will showcase the remarkable flexibility of its OS technology, in everything from a medical device that saves lives to a robot that cleans carpets. Of course, the new demos aren’t just about flexibility. They also showcase how QNX technology can make embedded systems easier to build, easier to certify, and easier to use. Not to mention more reliable.

So if you’re at Embedded World this week, come on over and visit us at Booth 4-358. In the meantime, here's a quick peek at what we plan to showcase:

Demo #1: The autonomous vacuum
Chances are, the QNX booth will have the cleanest floor in all of Embedded World. And for that, you can blame the Neato Botvac robot vacuum.

This Botvac is one smart appliance: Before it starts to suck up dirt, it scans and maps the entire room so it can work as quickly and methodically as possible. It’s also smart enough, and quick enough, to maneuver around furniture and to avoid staircases.

To quote Mike Perkins, vice president of engineering at Neato Robotics, “our autonomous home robots need fast, predictable response times, and the QNX OS enabled our engineers to achieve very high performance on cost-effective hardware. The QNX OS also helped us create a software architecture that can quickly accommodate new features, giving us the flexibility to scale product lines and deliver compelling new capabilities.”

Check out this video of the Botvac in action:



Demo #2: The defibrillator
If you don’t already know, the QNX Neutrino OS is used in dialysis machines, infusion pumps, angiography systems, surgical robots, and a variety of other hospital-based medical devices. But it’s also used in mHealth devices that provide critical therapy or diagnostics when the nearest hospital is miles away. Case in point: the corpuls1, a defribrillator and patient monitor for fire fighters and other first responders, built by GS Elektromedizinische Geräte G. Stemple:




Demo #3: The medical reference demo
The QNX booth will also feature our latest medical reference demo, which integrates a suite of QNX, BlackBerry, and third-party technologies for building connected, safety-critical medical devices. Here is what the demo system looks like:



And here is a sample of what’s under the covers:

● IEC 62304-compliant QNX OS for Medical
● HL7, the international standard for transfer of clinical data
● User interface based on the Qt application framework
● Java runtime engine
● Remote device management and end-to-end security of the BlackBerry BES12 architecture

Demo #4: The QNX SDK for Apps and Media
We released the first version of this SDK almost exactly one year ago. In a nutshell, it extends the capabilities of the QNX Neutrino OS 6.6, enabling embedded developers to create rich user interfaces and applications with HTML5, JavaScript, CSS, and other Web technologies. It also offers secure application management, comprehensive multimedia support, mobile device connectivity, an optimized HTML5 engine, and other advanced features for building mobile-class user experiences into embedded devices.

You can learn more about the SDK on the QNX Website. In the meantime, here’s the home screen of the SDK, showing several of its built-in applications and demos:



Demo #5: The [CENSORED] robot
What kind of robot, you ask? Sorry, you’ll have to wait until the first day of Embedded World, when we will showcase a video of this (very cool) QNX system in action.

Demo #6: The all-new QNX [CENSORED]
Again, I can’t tell you what this is. I can’t even give you a hint. I can mention, however, that it’s a brand new product that will run on an automotive demo system in our booth. But don’t be fooled by the automotive connection! The new product can, in fact, be used in a wide variety of devices, not just cars. Stay tuned.



Visit www.qnx.com to learn more about QNX at Embedded World, including presentations on IoT and safety-critical design. And while you're at it, download this infographic to see how flexible QNX technology really is.

Breaking up is hard to do

Separation can be painful. But often, the failure to separate can result in even more pain over the long haul.

No, I’m not talking love, marriage, or other affairs of the human heart. I am talking software design. In particular, the design of complex software systems that must perform safety-critical functions. The software, for example, in a medical device, automotive ADAS unit, or train-control system.

In systems like these, separation is critical: software components must be cleanly isolated from one another. Otherwise, you risk the chance that the behavior of one component will inadvertently interfere with the behavior of another. For this reason, component isolation is a key thrust of functional safety standards like IEC 61508 and ISO 26262.

Several forms of interference, all undesirable.

Interference can take many forms. For instance, a component could improperly use file descriptors or flash memory needed by other components. Or it could enter a tight loop under a failure condition and starve a more-critical component of CPU time. Or it could write to the private memory of another component.

You could, of course, run every component on separate hardware. But that becomes an expensive proposition. Moreover, the market trend is toward hardware consolidation, which, for reasons of economy, merges previously discrete systems onto a single platform.

It’s important, then, to embrace software-based separation techniques. These include OS mechanisms to prevent resource deprivation, time starvation, data corruption, and so on. For instance, the adaptive time partitioning provided by the QNX Neutrino OS can ensure that a software component always gets a minimum percentage of CPU time, whenever it needs it. That way, other components can't prevent it from running, either unintentionally or maliciously.

Software separation is as much art as science. In fact, my colleague Yi Zheng goes further than that. She argues that there is as yet no precise methodology for separating system functions. There are no textbooks, no pat answers.

So is separation only a matter of asking the right questions? That would be an oversimplification, of course. Skill also comes into play, as does experience, not to mention a good dose of thoroughness. But really, you should read Yi’s article, “The Art of Separation”, in Electronic Design and judge for yourself.

The end of software testing? No, not really

Testing: no longer about establishing
the correctness of a system

A few years ago, I penned a whitepaper that contained these words:

"No amount of testing can fully eliminate the bugs and security holes in a complex software system, as no test suite could possibly anticipate every scenario the system may encounter."

As it turns out, I wasn't whistling dixie. My colleague Chris Hobbs, who has forgotten more about software design that I could hope to learn in multiple lifetimes, notes that:

"... a modern, pre-emptible, embedded operating system with about 800 assembler instructions in its core has more than 10³⁰⁰ possible internal states. To put this into perspective, the Eddington Number (the number of protons in the observable universe) is about 10⁸⁰.

Don't know about you, but those numbers far exceed what my brain can grasp. And if that's not enough, the 10³⁰⁰ figure applies only to the OS core — it doesn't account for the huge number of additional states that are introduced when you start running applications and their supporting libraries.

So why bother with testing when you can only hope to exercise, say,
0.00000000000000000000000000000000000000001% of the system's possible states? It all has to do with a concept called confidence from use.

Rather than attempt an explanation here, I invite you to read a paper that Chris has published, titled "Testing as a road to confidence-from-use". Chris not only explores the concept, but discusses the degree to which confidence-from-use data gathered on one version of a system can be applied to a slightly modified version. Recommended for anyone interested in software testing or reliability.

Japan's high-tech innovations take on natural disasters

Guest post by my inimitable colleague Noko Kataoka.

Noko Kataoka

When I’m talking to my family in Japan, the conversation often turns to the weather. Not because we have nothing else to talk about, but because the weather is such a serious subject in their region. They experience heavy rainstorms in early summer (followed by scorching heat that lasts for over two months), ferocious typhoons in the fall, and blizzards in the winter that can drop up to 50 cm of snow overnight. Every time I hear a severe weather report I need to call my family and make sure they’re okay.

And, of course, Japan is known for its earthquakes. The country is still working to recover from the “311” (March 11, 2011) disaster, one of the worst earthquakes and tsunamis in history, which killed more than 18,000 people. The country has had to put a lot of thought into how more lives could be saved when Mother Nature chooses to strike again.

Logo of the
Saigai Taisaku Expo

The good news is, Japanese people are very good at advancing technology to address their unique environment. Government agencies and businesses work together on innovative ways to respond to environmental challenges. The country even has tradeshows dedicated to technologies for coping with natural disasters. For instance, the Saigai Taisaku Expo (Disaster Response Expo) showcased many ingenious solutions this year — from highly sophisticated portable toilets for evacuation camps to smartphone apps for earthquake warnings. Here are some solutions that I found interesting:

• An unmanned airplane for establishing radio communications in isolated communities that have suffered infrastructure damage.
   
• A helmet loaded with a head-lamp, radio, earthquake sensor, and wireless communications unit. The helmet not only protects you from physical shocks but also sends emergency messages for safety confirmation, evacuation guidance, and more.
   
• An earthquake estimator that uses earthquake forecast information issued by the Japan meteorological agency to estimate the magnitude of an imminent quake and how long before the shock hits. It can be integrated with public broadcasting systems or digital signage to guide people to safety.
   
• A smartphone navigation app especially designed for natural disaster situations. Using information from GPS and camera, the app displays directions for designated evacuation areas.
   
• An unmanned 3D radar system for estimating damage to buildings. Okay, your building is still standing after a big earthquake — but how do you know if it’s safe to go in?
   
• A public information system that consolidates and manages big data collected by the crisis management information center. In the state of emergency, people can access to emergency-response information they need from their mobile devices.
   

It is particularly interesting to see how new innovations are made possible by technologies such as smartphones and cloud connectivity. We have little immediate influence on how Mother Nature behaves, but people can engineer solutions to help survive natural disasters. And with global climate change causing unexpected weather across the planet, Japan’s innovations in connected systems for environmental challenges may prove useful in other parts of the world, too.

Oscar-winning Flying-Cam system takes to the skies with QNX technology

Flying-Cam has been at
the forefront of unmanned
aerial filming since 1988.

Ever wonder how film crews manage to achieve death-defying camera angles that take your breath away? Well, wonder no more, because I am about to show you one of the most advanced tools of the trade. It's called SARAH, it runs on the QNX OS, and it recently won a Scientific and Technical Award from the Academy of Motion Picture Arts and Sciences for its contribution to movie making.

The SARAH unmanned aerial system is the brainchild of Flying-Cam, a company founded in 1988 by Emmanuel Prévinaire, who, in 1979, developed the first unmanned close-range aerial camera for motion pictures. SARAH represents the latest generation of Flying-Cam technology and has been in service since 2012 — yet its credits already include Skyfall, Oblivion, Prisoners, Smurfs II, and Mr. Go.

The Flying-Cam SARAH unmanned aerial system in action, filming a scene for Mr. Go. 

So why did the folks at Flying-Cam choose the QNX OS? Several factors contributed to the decision, including flexible architecture, predictable response times, and advanced profiling tools. To quote Tony Postiau, head of aerial robotics engineering at Flying-Cam, "we have been thoroughly impressed with the QNX OS. It works extremely well on our hardware and uses system resources efficiently, leaving most of the hardware processing power available to our application — a crucial attribute that we looked for.”

To find out more about QNX and the Flying-Cam SARAH system, check out the press release that QNX issued this morning.

And for a look at SARAH in action, here's a promotional video that demonstrates how it helps film crews capture angles that would be impossible for full-size helicopters, cable systems, or other traditional camera support devices:

QNX at Embedded World: three distinct systems, one OS platform

A whole new way to

take QNX out for a spin.

Quick: what do washing machines, bulldozers, and pipeline inspection tools have in common? Simple: they all demonstrate the remarkable flexibility of the QNX OS.

Next week, at Embedded World, QNX will showcase three systems built by three different customers, for three different markets. Each system addresses different technical challenges and targets different end-users. And yet, in each case, the development team behind the system chose the same OS — a testament to the “bend it, shape it, any way you want it” quality of QNX technology.

Of course, not everyone can attend Embedded World. So for anyone who can’t go (or for anyone who plans to go and would like a taste of what they’ll see), here’s a sneak peek of the three systems. Mind you, this isn’t everything we will demonstrate next week — but that’s the subject of another post. :-)

Washing machine touchscreen from Dalian Eastern Display
Imagine a web-connected washing machine that can play your favorite music and videos, provide tips on removing stains, and let you choose laundry settings with the tap of a touchscreen. The system from Dalian Eastern Display lets you do all this and more, and it’s one of many solutions that Dalian is creating for IoT smart appliances.

For instance, this screen lets you quickly choose your fabrics, including cotton, wool, or polyester. It also provides a mixed setting — handy for people who aren’t sure of the difference. Me, for instance.



Once you’ve chosen the right fabric, you can fine-tune the parameters of your wash cycle, including time, temperature, speed, and water level:



Meanwhile, this menu lets you configure everything from your network connection to the system’s sound settings:



Murphy PowerView 780 display for heavy machinery
If you build equipment that has an engine and demands a rugged display, chances are its owners and operators will benefit from a Murphy PowerView 780. Designed for use with electronic or mechanical engines in everything from boats to bulldozers, the PowerView 780 integrates engine, transmission, and diagnostic information into an easy-to-read user interface. The PowerView 780 is built for extreme outdoor environments and features a 7-inch bonded LCD that is readable in direct sunlight. Better yet, it’s easily configurable to application needs. Using Murphy’s PowerVision Configuration Studio™, developers can customize the user interface with their own graphics or display parameters, track maintenance schedules, log operation data and faults, and add OEM branding.



Murphy, the company behind the PowerView 780, is a global supplier of controls and instrumentation for almost any application that involves engines or engine-driven equipment. The company is celebrating 75 years of serving the oil and gas production, engine OEM, construction, irrigation, agriculture, power generation, and work and pleasure boating markets.

LineExporer pipeline inspection system from NDT Global
When it comes to oil and gas pipelines, safety is job one. But to ensure safety, you need to keep pipelines properly maintained — and to maintain them, you need accurate and reliable inline inspection tools. That's where NDT Global comes in. NDT is a leading supplier of ultrasonic pipeline inspection and pipeline integrity management services worldwide, with operations in Germany, Russia, the US, Canada, Mexico, U.A.E., Malaysia and Singapore. At Embedded World, QNX Software Systems will showcase an NDT LineExplorer inline inspection tool for 10" pipelines that can detect and measure corrosion and cracks, depending on the sensor carrier.



For more information on QNX at Embedded World, visit the QNX website.

Striking a balance between reliability and availability

Can you achieve one without

sacrificing the other?

Maybe it's just me, but a lot of people seem to use reliability and availability interchangeably. I often hear people say 99.999% reliability when, in fact, they are referring to availability.

So what is the difference between the two? And why is that difference important? I'm glad you asked. :-)

In a software-based system, availability refers to how often the system responds to events or stimuli in a timely manner; reliability, on the other hand, refers to how often the responses are correct. The distinction can be a matter of life or death. For instance, in some medical devices, it is preferable to have no response (where little or nothing happens to the patient) than a wrong response (where the device harms the patient irreparably). Whereas in other systems, any response of sufficient accuracy or quality may be preferable to no response at all.

But here's the thing. Regardless of whether a system is more sensitive to availability or reliability, it should still take pre-defined (and carefully considered) actions when a dangerous condition arises. For instance, if the control system for a high-speed train fails, it will move to its design safe state, which will probably involve applying the brakes.

So far, so good. The problem is, many systems are components of larger systems. So even when a component is avoiding a genuinely dangerous situation, its behavior may put stress on the larger system and lower that system's availability.

Moreover, the behavior of an overall system when an unanticipated condition occurs can be very difficult to predict, for the simple reason that the system depends on multiple, largely independent, components moving to their design safe states. None of those components, and their safe states, can be considered in isolation. For instance, in 1993, Lufthansa Flight 2904 overran a runway because the reverse thrust deployment system operated exactly to specification. Unfortunately, the system designers hadn't anticipated conditions during a cross-wind landing.

Enough from me. I invite you read the ECN article "Balancing reliability and availability", written by my colleague and senior software developer Chris Hobbs. Chris discusses how it's possible to strike a balance between reliability and availability — and why designing safe software can require the ability and willingness to think from the outside in.

Six 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 six 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.

The isolation imperative: protecting software components in an ISO 26262 system

Software components can be impolite, if not downright delinquent. For instance, a component might:

• rob other components of CPU time
  
• rob other components of file descriptors and other system resources
  
• access the private memory of other components
  
• corrupt data shared with other components
  
• create a deadlock or livelock situation with other components
  

Shameful, I know. But in all seriousness, this sort of behavior can wreak havoc in a safety-critical system. For instance, let's say that a component starts to perform a CPU-intensive calculation just as the system enters a failure condition. Will that component hog the CPU and prevent an alarm process from running?

The answer, of course, is that it damn well better not.

It becomes important, then, to prevent components from interfering with one another. In fact, this principle is baked into the ISO 26262 functional safety standard for road vehicles, which defines interference as:

"...the presence of cascading failures from a sub-element with no ASIL [Automotive Safety Integrity Level] assigned, or a lower ASIL assigned, to a sub-element with a higher ASIL assigned leading to the violation of a safety requirement of the element”

To put it crudely, less important stuff can't stop more important stuff from happening.

So how do you prevent interference? One approach is through isolation. For instance, a system may implement spatial isolation between application processes. This would include mechanisms for interprocess communication and interprocess locking that prevent one process from inadvertently affecting another.

Mind you, there are multiple types of interference, so you need to implement multiple forms, or axes, of isolation. Time for a picture:




In general, you need to determine what does, and what doesn't, need to be isolated. You also need to identify which components are apt to be delinquent and build a cage around them to protect more critical components. Which brings me to a recent paper by my inestimable colleagues Chris Hobbs and Yi Zheng. It's titled "Protecting Software Components from Interference in an ISO 26262 System," and it explores techniques that can help you:

• implement the component isolation required by ISO 26262
• demonstrate that such isolation has been implemented

And while you're at it, check out the other titles in our "safe" whitepaper series. These include "The Dangers of Over-Engineering a Safe System" and "Ten Truths about Building Safe Embedded Software Systems."

And don't worry: there's nothing delinquent about downloading all of them.

This post originally appeared in the QNX auto blog.

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.

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 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.

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.

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

QNX, SIAT CAS to establish software center of excellence in China

The SIAT CAS campus

This just in: QNX has announced that it will collaborate with the Shenzhen Institutes of Advanced Technology, a branch of the Chinese Academy of Sciences (SIAT CAS), to establish a center of excellence for embedded software. The goal is to enable software designs for mass transit systems, power networks, telecom systems, and other infrastructure projects that have rigorous demands for reliability and safety.

SIAT CAS is a research and educational organization responsible for evaluating technologies used in infrastructure projects. It has already evaluated QNX technology for various projects and, under the expanded collaboration, will employ additional QNX products for research and education.

“Safety and security in critical infrastructures are key requirements in China. QNX software technology is known for its reliability and is a preferred choice for mission- and safety-critical systems,” said Professor T. John Koo, the founding director of the Center for Embedded Software Systems at SIAT CAS and a QNX user since 1996.

For its part, QNX Software Systems will train SIAT CAS researchers and engineers on QNX technology on an ongoing basis. Both organizations will assign project managers to work together on joint project activities.

SIAT CAS has a mandate to enhance the indigenous innovation capabilities of the manufacturing and services industries in the area of Guangdong, Hong Kong, and greater China. For more information on the organization, visit the SIAT CAS website. And for more information this announcement, read the QNX press release.

On a related note, QNX is currently holding its second annual China Technology Innovation Conference in Beijing and Shanghai. You can read about the conference here.