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.

Acontis releases new EtherCAT motion library for QNX Neutrino operating system

This just in: Acontis, a leading provider of EtherCAT software and realtime hypervisor technology, has announced that its new EC-Motion product is now available for the QNX Neutrino operating system.

So what, exactly, is EC-Motion? In a nutshell, it's a C/C++ motion control library for EtherCAT drives (i.e. the electronic systems that control industrial motors).

According to Acontis, the EC-Motion library supports all of the single-axis movement commands specified in the PLCopen standard, eliminating the need for additional (and costly) hardware. It also allows the developer to:

• implement applications for multi-axis coordinated movements
• operate EtherCAT drives in cyclic synchronous position mode (CSP) or cyclic synchronous velocity (CSV) mode
• easily integrate the EC-Motion library into custom motion applications as well as into a programmable logic controller (PLC) runtime environment

Here's the EC-Motion architecture at a glance:



Demo on BeagleBone computer
Acontis also announced that it will demonstrate EC-Motion for QNX at the embedded world conference, from February 26 to 28 in Nuremberg. The demo will run on a BeagleBone, a credit-card-sized computer based on Sitara ARM AM335x Cortex-A8 processors from Texas Instruments. The demo will show a Yaskawa Sigma-5 EtherCAT drive running in cyclic synchronous velocity mode.

If you plan to attend embedded world, you can catch the demo at the IXXAT Automation GmbH stand, Hall 1/1-538.

For more details, read the Acontis press release.

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.

Prefer your whitepapers in German? Have I got a link for you

Germany has long been a strong market for QNX technology, particularly in the industrial, medical, and automotive sectors. Consider, for example, the many cars from Audi, BMW, Mercedes, and Porsche that ship with QNX technology on board.

It's no surprise, then, we've been redoubling our efforts to publish our latest technical whitepapers in German. So if you sprechen sie Deutsch (I hope I said that right) better than you speak English, I invite you to visit the German section of our whitepapers page.

Papers include:

Wann genau benötigt man ein Echtzeitbetriebssystem?

Funktionale Sicherheit komplexer Software-Systeme – Teil 1

HTML5 – die Zukunft des In-Car Infotainment?

For the full list of papers, click here.

Using Crank Storyboard to create an automotive user interface

Just how adept is the QNX CAR application platform at supporting a variety of user interface technologies and toolkits?

From the beginning, we've promoted flexibility as a key quality of the QNX CAR application platform. For instance, the platform lets you work with a variety of user interface technologies, including HTML5, Qt, OpenGL ES, and others. What's more, it lets you blend UI components built with different technologies on the same display, at the same time. You're not forced into using a single API or toolkit.

When it came time to build our new technology concept car, we decided to put this flexibility to the test. After all, the whole point of the concept car is to demonstrate the capabilities of the QNX CAR platform. So, for the first time, we tried building a user interface with the Storyboard Suite from Crank Software.

How well did the QNX CAR platform and Storyboard work together? I think the results speak for themselves. For instance:



Of course, this photo can't demonstrate the smooth animations and snappy performance of the car's user interface. For that, I recommend one of the videos shot at CES, including the excellent video from TI.

So why did we choose Storyboard? For one thing, it allowed our concept team to take UI components created in Photoshop and import them directly into their live design. Rather than spend days or weeks recreating the UI in code, the team's engineers were able to start with what the UI designer provided. Which made prototyping and fine-tuning the UI a lot easier.

Mind you, that wasn't the only reason the team used StoryBoard. But instead of listening to me blather about it, check out this video:



Key takeaway: If you're building a UI for your QNX-based system, you owe it to yourself to check out Crank's Storyboard Suite. You can learn more on the Crank website.

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.