QNX acoustics technology shortlisted for 2014 embedded AWARD

Okay, first things first. I didn't get the capitalization wrong. The name of the award really is spelled that way. I thought it odd at first, but I'm getting used to it. And besides, who am I to complain? After all, I spend a good part of my life promoting a product whose name is spelled all uppercase, and... where was I? Oh yes, the award!

Every year, the folks who organize the embedded world Exhibition&Conference hold the embedded AWARDs, which honor the most innovative software, hardware, and tools for embedded developers. And this year, the competition judges selected QNX Acoustics for Active Noise Control as a finalist in the software category.

If you aren’t familiar with our ANC solution, allow me to provide an overview — which will also help explain why the embedded AWARD judges are so impressed.

Automakers need to reduce fuel consumption. And to do that, they employ techniques such as variable engine displacement and operating the engine at lower RPM. These techniques may save gas, but they also result in "boom" noise that permeates the car's interior and can lead to driver distraction. And who needs more distraction?

QNX Acoustics for Active Noise Control can integrate 

seamlessly into a vehicle's infotainment system.

To reduce this noise, automakers use ANC, which plays “anti-noise” (sound proportional but inverted to the offending engine tones) over the car's speakers. The problem is, existing ANC systems require dedicated hardware, which adds design complexity, not to mention significant Bill of Materials costs. And who needs more costs?

Enter QNX Acoustics for ANC. Rather than use dedicated hardware, QNX ANC provides a software library that can run on the existing DSP or CPU of the car's head unit or audio system. This approach not only reduces hardware costs, also enables better performance, faster development, and more design flexibility. I could go on, but I will let my colleague Tina Jeffrey provide the full skinny.

Did I mention? This wouldn’t be the first time QNX Software Systems is tapped for an embedded AWARD. It has won two so far, in 2006 and 2004, for innovations in multi-core and power-management technology. It was also a finalist in 2010, for its persistent publish/subscribe messaging. Here's to making it a hat trick.

This post first appeared on the QNX Auto Blog.

QNX takes the wraps off two new technology concept cars

You may be wondering why I've been quiet lately. Well, as turns out, I've been anything but quiet. I've just been noisy somewhere else! And that somewhere else is the QNX auto blog, where you can learn about two new technology concept cars that QNX unveiled this week at 2014 CES.

So if you haven't been to the auto blog lately, don't stop, don't hesitate, don't prevaricate; just get yourself down there. And if you still need convincing, here's a taste of what you'll see:



and another:



and yet another:



and still another:

Jim, where did you say you parked the car?

Sometimes, you can ignore winter parking regulations with impunity. And sometimes...

Just the thing for your autonomous car

Don't know about you, but when I finally get a car that does all the driving for me, I'm going to become very lazy, very fast. Which means I'll be super unhappy every time my car needs a fill-up. Think about it: I will have to haul my butt out of the car and fill the tank myself. The horror!

But you know what? It turns out my fears are groundless. Because Husky Corporation and Fuelmatics AB have collaborated on a — you guessed it — automatic refueling system:



Kidding aside, this system could be of benefit long before autonomous vehicles become ubiquitous. According to Husky, it can cut 30% off the time it takes to refuel, so gas stations could sell more gas in the same amount of time, and with fewer lineups.

Also, this could be just the thing for any region where winter has the upper hand — virtually all of Canada, for instance. If you're ever stepped out of your car in -30 C temperatures to gas up, you know of which I speak.

What do you mean, you haven't read the latest QNX newsletter?

Seriously, folks, there's no excuse. All you have to do is subscribe. It's easy, it's painless, and it's free of clauses asking for your first-born child.

What's that, you say? You're not the subscribing type? Hey, no worries, I'm cool with that. In fact, you can be cool with it, too, since you can also access the newsletter (aka "The Source") by visiting this QNX webpage. So bookmark it in your browser. And don't go another month without keeping track of what's happening at QNX.

What has the QNX auto team been up to?

Well, let's see...

• Andy connects the dots between self-driving cars and soccer games
   
• Tina manages to squeeze ‘anti-noise’, ‘SpongeBob SquarePants’, and ‘constructive interference’ into a single blog post
   
• Paul looks forward to fewer bumps, scuffs, and scratches
   
• Tina spells out the challenges for an important initialism
   
• Romain finds the stats on driver distraction a little, well, distracting
   
• Paul suddenly realizes what he wants for Christmas
   
• Yoshiki feels his navigation system doesn’t understand him
   
• Paul can't wait until December
   
• And Rob from TI can’t wait to get back on the road
   

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.