What has the QNX auto team been up to?

Well, let's see...

• Alex has been developing drivers for drivers
   
• Andrew wants you to stop worrying and be appy
   
• Thomas from Elektrobit scrambles an egg
   
• Paul goes into isolation
   
• Bernard and Justin think "Hello Bentley" is just the beginning
   
• Paul can't get his mind off ice cream
   
• Andy talks to Pandora about built-in, brought-in, and how HTML5 fits in
   
• Yoram from Red Bend connects the dots between autos and airwaves
   
• Nancy gets cranky over UIs
   
• And Paul spends too much time on YouTube again
   

Why does all the cool stuff happen while I'm away?

Now appearing in both 

Fortune and Daily Planet

Do you ever get the feeling that the party starts the minute you leave the room? Well, it just happened to me. I was on vacation only a few days last week, but while I was away, Fortune magazine and Daily Planet both did pieces on QNX. What's up with that?

But seriously, this is cool. The Fortune article covers several bases: the history of QNX in mission-critical embedded systems, the leadership that QNX enjoys in automotive, and the new QNX concept car that made its debut at 2013 CES. Meanwhile, the Daily Planet video puts you in the front seat of the concept car for a tour of its many features — from voice control and video conferencing to the virtual mechanic. (Is it just me, or do the coolest features all start with the letter 'v'?)

Read the Fortune article here (you'll need a subscription to access it). And view the Daily Planet video here.

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.

All roads lead to QNX at embedded world 2013

Montreal, my home town, was once known as a city of churches. So much so that Mark Twain famously quipped, "this is the first time I was ever in a city where you couldn't throw a brick without breaking a church window."

If Mr. Twain were alive today and able to visit embedded world 2013, he might make a similar comment about QNX. Because it seems that, wherever you turn at embedded world, someone is demonstrating a QNX-based system.

Multimedia and wireless demos
First stop is the QNX booth, where you'll find a natty new demo designed to showcase our support for wireless, video, and HMI technologies. Among other things, the demo shows how QNX lets you work with a mix of application and graphics environments, including Qt 5.0, OpenGL ES 2.0, and Crank Software’s Storyboard Suite.

Power up the demo, and you'll see several applications, including a medical monitor:



and a speedometer:



You'll also find games, a digital thermostat, a photo viewer, an audio meter, and several other demo apps. And did I mention? You can find two of these demo systems in the QNX booth, one based on a Freescale i.MX 6 SABRE Lite board and the other on a TI AM335 Starter Kit board.

PLC demos
If you're a hard-core industrial developer, be sure to catch the two programmable logic controller (PLC) platforms in the QNX booth. These platforms were a group effort: QNX provided the OS; companies like IsaGRAF, KW-Software, and koenig-pa provided the ladder logic and EtherCAT software; and Freescale and TI provided the hardware — one platform is based on a Freescale QorIQ TWR-P1025 Tower System Module, the other on a TI Sitara AM335x ARM Cortex-A8 processor.

The purpose of these platforms is simple: to reduce the time and cost of developing PLCs and other industrial systems. If you're interested, the eval software for the platform based on the Freescale module is now available for download from the QNX website.

QNX CAR platform demo
No, we didn't drive the new QNX concept car to embedded world. But we did bring a demo of the QNX CAR application platform, and from what I hear, it's driving lots of booth traffic (pun fully intended). Here's a snap of the demo, taken on the show floor:



Lotsa partner demos
Take a walk down the aisle, and you'll soon come across several other vendors showing QNX-based systems. Here are the ones we've identified so far:

Acontis is demonstrating its EC-Motion EtherCAT motion library running on the QNX Neutrino RTOS and a TI Sitara AM335x ARM Cortex-A8 processor. Hall 1/1-538.

Crank Software is demonstrating an automotive demo based on the QNX CAR application platform. Hall 4/4-330.

Digia is demonstrating “Qt 5 on the QNX platform – a Cinematic Experience,” which will show many new features in Qt 5 Qt Quick 2. Hall 4/4 – 520.

Freescale and koenig-pa are demonstrating a PLC reference platform that integrates koenig-pa EtherCAT protocol software, ISaGRAF PLC firmware, and the QNX Neutrino RTOS on a Freescale dual-core QorIQ P1025 processor. Hall 4A/4A-206 and Hall 5/5-425.

KDAB is showcasing an IP camera demo written in Qt5 and QML, and running on the QNX Neutrino RTOS and a Freescale i.MX 6 SABRE Lite ARM Cortex-A9 platform. Hall 4/4-622.

KW-Software is demonstrating a PLC development platform developed in collaboration with QNX Software Systems, TI, and koenig-pa. Hall 1/1-446.

MPC Data, a Bsquare Company, is showcasing a high-performance graphics demo based on OpenGL and the QNX Neutrino RTOS. Hall 4A/4A-108.

Xilinx is showcasing a high-precision, low-noise, multi-motor electrical drive demo running on the QNX Neutrino RTOS. Hall 1/1-205.

For more details on these demos, check out the press release that QNX issued this morning.

The joy of talking
Several QNX experts are presenting technical talks at embedded world:

• Clear SOUP and COTS Software for Safety-Critical Systems — Tues, Feb 26, 14:00 - 14:45, Session 03
• The Joy of Scheduling — Thurs, Feb 28, 10:00 - 10:30, Session 19
• Ten Truths about Building Safe Software — Thurs, Feb 28, 14:15 - 15:00, Session 21
• Issues in M2M Communication for Software and Firmware Updates — Thurs, Feb 28, 16:30 - 17:00, Session 24

So, if for some strange and inexplicable reason, you want to avoid all things QNX, don't go to embedded world this week. Because once you arrive, there will be no escape. :-)

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.