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.

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.

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.

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.

Taking a long, hard look at the ozone hole

For more than 20 years, a Harvard research team has been taking QNX technology to stratospheric heights

The NASA ER-2 high-altitude
aircraft

Hey, do you remember when everyone was in a knot over the ozone hole? You know, the one over Antarctica? The one the size of Antarctica? Based on all the press it has received lately (read: not much), it is yesterday's problem. I, for one, haven’t worried about it — or even thought about it — for a good 10 years.

But here’s the thing. The ozone hole didn’t go away. And it’s not going away soon. Yes, evidence suggests that the hole will heal, but the process promises to take decades — by 2050, if we’re lucky. (Strictly speaking, the hole heals every Austral Spring, but only temporarily; it always returns the next Austral Winter. And it isn’t exactly a hole, since the ozone doesn’t disappear completely from the upper stratosphere. It does disappear from the lower stratosphere, however.)

Did I mention only one hole? Sorry to mislead you. There are, in fact, substantial ozone losses over the Arctic as well, with the loss during the winter of 2011 achieving ozone hole status.

Ozone depletion is serious stuff. It may contribute to an enormous list of problems, from crop failures to eye cataracts to skin cancer. So it’s important to do the hard science and measure its progress, along with any factors that can affect it. Otherwise, how do you argue for a cogent policy on controlling substances and industrial practices to prevent ozone depletion? And do you know whether the policies and practices you put in place are doing any good?

Problem is, measuring and analyzing ozone depletion is a long-term project that takes patience and commitment. Fortunately, the Anderson Research Group from Harvard University seems to have those qualities in spades.

Making the upgrade
The group has been operating continuously since 1979. (For context, that was the year that Philips demonstrated the first Compact Disc. Remember those?) For the first few years, the group used a balloon to carry their instruments high into the atmosphere, but with the discovery of the Antarctic ozone hole in the mid-80s, they graduated to a NASA ER-2 high-altitude aircraft, which flies as high as 21 kilometers. (If the ER-2, depicted above, looks to you like a modded U-2, you’re right.)

The team’s first QNX-based instrument,
which measured OH in the lower
stratosphere, was deployed in an ER-2.

Lots of things have changed since 1979, but for the past two decades, one thing hasn’t: the group’s use of QNX technology. It all started in 1990, when the group decided to replace their homegrown OS kernel with the QNX RTOS v2. They then upgraded to the QNX RTOS v4 in 1992, which is also when they deployed their first QNX-based system, an instrument that measured OH (hydroxyl radical) in the lower stratosphere. More recently, they migrated to the latest generation of the QNX technology, the QNX Neutrino RTOS, aka v6.

Alphanumeric soup
To measure phenomena in the stratosphere, the team created a data acquisition architecture that takes advantage of core QNX strengths, including multitasking, message passing, realtime performance, and transparent distributed networking. Flexibility is a key characteristic of this architecture, since it must support a variety of instruments that measure an alphanumeric soup of airborne radicals and reactive intermediates. These include BrO, ClO, ClONO2, ClOOCl, NO2, OH, HO2, O3, CH4, N2O, CO, and CO2, as well as water vapor, water isotopes, and total water. (Why measure water? Because its presence in the stratosphere can contribute to ozone depletion. And because the increased frequency of heavy storms, such as Hurricane Sandy, may inject more water into the stratosphere.)

Here is the full configuration of the data acquisition architecture, which includes control and acquisition programs running on a flight computer as well as display and interactive commands running on a ground support computer:



According to Norton Allen, a software engineer for the Anderson group, “From the start, we needed an OS platform that would scale with our growing requirements, and that would satisfy our demands for high reliability — sending a plane into the lower stratosphere is a costly proposition, so there’s no room for software failures. At the same time, we needed a standards-based platform that would let us write portable applications. The QNX OS has been able to deliver on all counts."

“We needed an OS platform that would scale
with our growing requirements, and that would
satisfy our demands for high reliability.”
Global scale
I’ve barely touched on the many research activities of the Anderson Research Group. To quote their website, the group “addresses global scale issues at the intersection of climate and energy using a combination of experimental and theoretical approaches drawn from the disciplines of chemistry, physics and applied mathematics.”

So if you’ve got a minute, visit the site. Who knows, you may learn something — I did.

In-car infotainment and the art of doing more with less

No, not that kind of squeezing.

Granted, the title for this blog post doesn't have the pizazz of, say, "Zen and the Art of Motorcycle Maintenance." (Are you old enough to even remember that book?) But it does capture the gist of a webinar that my colleague Andy Gryc will deliver next week.

His title for the webinar is "Squeezing high-end technologies into low-end infotainment systems." Admittedly, it's more direct than mine. Which is fitting, given that Andy has direct experience designing in-car systems. OnStar, for example.

But I digress. I'm sure you'd like to know what Andy plans to cover, so here's the overview:

Squeezing high-end technologies into low-end infotainment systems

Today's infotainment systems have it all – full multimedia, mobile device integration, POI-enabled navigation, speech recognition, high-resolution graphics, and cloud connectivity. The only problem is all of these features come with a big price tag.

Join Andy Gryc, automotive marketing manager, for this webinar, where he answers the question: Is it possible to build an infotainment system that meets today's customer demands with yesterday's price tag?

A 50-minute session (plus Q&A), this webinar covers a number of techniques to help slim down your next infotainment's BOM cost; it also suggests ways to target the luxury segment as well as the more cost-conscious, high-volume one with the same basic technology.

Date: Tuesday October 23, 2012

Time: 12:00 pm ET

Duration: 1 hour, including Q&A

Registration: Click here to register

Who should attend: Automotive software engineers and managers

This post also appeared on the QNX Auto Blog.

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.

New service pack brings new features, higher performance to QNX Neutrino OS 6.5

If you use the QNX Neutrino OS 6.5 for your embedded projects, you owe it to yourself to check out the brand new service pack released by QNX Software Systems.

Service Pack 1 offers a number of enhancements, including:

• Optimized memory management for higher performance (improvements are particularly noticeable with the newer ARM Cortex-A8 and A9 processors)
 
• Updated networking stack (io-pkt) for better stability and higher performance
 
• Updates to security protocols, including ALTQ support for packet filtering and IKEv2 for setting up security associations
 
• Improvements to file systems for greater robustness and efficiency
 
• Updates to the USB stack, including better stack performance and stability, as well as support for the new USB classes CDC-ECM, CDC-ACM, and CDC-NCM
 
• 36-bit paddr support for the Freescale u-boot bootloader found in newer processors such as the P4080

To download Service Pack 1, or to learn more about it, visit the downloads section of the QNX website.
 

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.
 

New M2M webinar: When embedded meets mobile

If you live and work in the embedded world, you can't help but notice that M2M has become the industry's new watchword. And if you're like me, you can't help but smile, since embedded devices that either talk with each other or with back-end systems have, in fact, been around for decades. (QNX, for one, was helping developers create peer-to-peer networks of embedded systems as far back as the 1980s.)

Still, the world has changed. The proliferation of mobile networks, along with the ready availability of wireless modules that allow embedded devices to connect to those networks, has created many new opportunities for remote diagnostics, predictive maintenance, location monitoring, and so on.

But don't take it from me, a reigning non-expert on M2M. :-)  Instead, check out tomorrow's M2M webinar, presented by two people who have spent a lot of time thinking about M2M and what it means for next-generation embedded systems: Bob Monkman of QNX and Iain Davidson of Freescale.

Here's an overview the webinar, along with a registration link. Note that you have a choice of two sessions: one at 11:00 am EST, the other at 2:00 pm EST.

Embedded Meets Mobility: M2M Considerations & Concepts
For decades, multitudes of embedded machines have been specialized islands of vertical fixed-function intelligence with unique attributes. As the need and opportunity evolves to connect and coordinate between these embedded machines and the people that need to interact with them, many factors must be considered. Machine to Machine (M2M) offers new efficiencies in operational management of networked devices, the addition of new services and new business models for stakeholders within the value chain. Freescale and QNX will present an overview of revenue opportunities for M2M and the essentials of developing secure, reliable and scalable M2M networks, managed device endpoints, coupled with management concepts for devices in cloud computing.

Thursday, May 31, 2012
11:00 am EST and 2:00 pm EST
Register here
 

Designing safe software systems? I've got three articles to keep you on track

Believe it or not, the men in this video are performing a safety procedure:



So are the men in this video:



I know what you're probably thinking: What's so safe about standing near, or hanging from, a moving train? Are these people nuts?

On the other hand, you may know exactly what is happening: The men are exchanging railway tokens. In a nutshell, only one token exists for any given section of track, and only the train driver possessing the token can access that section. (If you're a software developer, think mutex.) The idea, of course, is to prevent two or more trains, especially those traveling in opposite directions, from using the same section of track at the same time.

From what I can gather, token-based systems have proved highly effective in preventing train-to-train collisions. Indeed, they remain in use in several areas, particularly on heritage railway lines.

That said, the world of rail transportation has moved on. High-speed freights, such as the TGV postal in France, zoom along at over 250 km/h, while passenger trains, such the China Railway High-speed, carry passengers at speeds reaching 350 km/h. The Shanghai Maglev Train, meanwhile, operates at a jaw-dropping 430 km/h — and is designed for speeds up to 500 km/h.

Available and correct
None of these trains could run without software control systems. Let me re-phrase that: safe software control systems. A safe software system possesses two key characteristics: It always responds when a response is required, and it always provides the correct response.

For instance, the software system controlling a train’s brakes must be available whenever required — a delayed response could result in an accident. The software system must also apply the brakes appropriately — too little can result in a collision, and too much can damage the train or cause a derailment.

To meet these requirements, the software system needs to use a real-time OS (RTOS) that meets specific claims of reliability and availability. But the software that runs on top of the OS (i.e. the part you design) must also embody these qualities. Which is where my colleague Chris Hobbs comes in.

Chris spends a lot of time thinking about the design of safe software systems — when he isn't actually helping people design them. So, not surprisingly, he has produced a series of articles and white papers to ground developers in key concepts and to help companies develop a safety culture. Electronic Design magazine has published three of his pieces so far, and I wouldn't be surprised if they publish more in the future.

Without further ado, here are the Electronic Design articles:

The Limits of Testing in Safe Systems — Key takeaway: Testing can prove the presence of faults, but it can't prove their absence. It isn't enough to test your systems; you must use other methods, such as design validation, as well. That said, testing can tell you a lot, especially when you apply statistical analysis to your test results, and when you use techniques like fault injection to estimate remaining faults and to observe how the system behaves under fault conditions.

Define And State Your Safety Requirements Before Design and Test — Key takeaway: Safety must be built into a system from the start, and everything you do should follow from the premise that all software contains faults and these faults may lead to failures. As you build your system, you must reduce the number of faults included in the design and implementation, prevent faults from becoming errors, prevent errors from becoming failures, and handle failures when they do occur.

Clear SOUP And COTS Software Can Reliably Serve Safety-Critical Systems — Key takeaway: Some device manufacturers want to use COTS software, but worry that COTS means SOUP — software of uncertain provenance. And SOUP can make a mess of safety claims... or perhaps not. If you take a nuanced approach and distinguish between opaque SOUP (which should be avoided) and clear SOUP (for which source code, fault histories, and long in-use histories are available), you may, in fact, discover that COTS software is a good choice for your safety-related project.
 

Qt Commercial 4.8.1 comes to QNX Neutrino RTOS

QNX patient-monitoring demo
equipped with a Qt-based UI.

If you didn't read the Qt Commercial Blog last week, you probably missed out on important news: The latest release of the Qt Commercial framework not only offers 200 functional improvements over its predecessor, but also introduces support for the QNX Neutrino RTOS.

According to blog's author, Tuukka Turunen (cool name, that), "Developers looking to develop their products on QNX with Qt Commercial can rest assured that Digia... supports their project with a full support and services team." This is welcome news for the many developers who'd like to use Qt and the QNX Neutrino RTOS together in a commercial device or application.

If you're new to Qt, it's a popular framework for writing applications and graphical user interfaces. It's also cross-platform: You can write your applications once and deploy them across multiple desktop and embedded operating systems, without having to rewrite your source code. This "write once, deploy across" feature helps explain why a number of QNX customers — particularly those in the medical industry — have asked for Qt Commercial support.

In case you're wondering, Qt Commercial is a, well, commercial version of Qt. :-)  It's available from Digia, a Finnish company that offers licensing, support, and services to companies who wish to Qt in commercial applications, on either desktop or embedded platforms.

If you visit here often, you may have already seen the QNX patient-monitoring demo, which sports a user interface built with Qt. But if you haven't, check out this video filmed at last year's Embedded World Conference in Nuremburg. Among other things, the video showcases some nifty BlackBerry PlayBook integration:



Any chance you'll be in Moscow on April 19? If so, you can meet up with Digia at QNX Russia 2012, the largest event for the Russian QNX community.
 

Vector's software testing tools now support QNX Neutrino RTOS Certified Plus

Learn how you can become
eligible to win this cool T-shirt

This just in: Vector Software, a provider of software tools for testing safety-critical embedded applications, has announced that its VectorCast suite now supports QNX Neutrino RTOS Certified Plus, an OS that combines the benefits of the QNX Neutrino RTOS Safe Kernel and the QNX Neutrino RTOS Secure Kernel.

According to the press release, the "The VectorCAST product suite has supported the QNX Neutrino RTOS since 2009... this latest integration helps our customers accelerate time-to-market by streamlining product planning, design, and validation."

QNX Neutrino RTOS Certified Plus offers both IEC 61508 certification at Safety Integrity Level 3 (SIL 3) and Common Criteria ISO/IEC 15408 certification at Evaluation Assurance Level 4+ (EAL 4+). Its certification credentials — combined with its microkernel architecture, POSIX-compliant API, and adaptive partitioning technology — make Certified Plus well-suited to systems that have both functional safety and security requirements.

To read Vector's press release, click here.