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.
 

Multicore webinar coming to a screen near you

If you're developing software for an embedded system equipped with a multicore processor, have we got a webinar for you.

On Wednesday, February 15, the "two Jeffs" — Jeff Schaffer of QNX and and Jeff Logan of Freescale — will present a webinar on achieving maximum performance on multicore chips. Topics include threading models for creating multiple concurrent tasks, design patterns for increasing parallelism, and techniques for optimizing cache usage.

Did I mention? If you attend the live webinar, you'll be eligible to win a QorIQ P2020RDB-PCA reference design board through Arrow Electronics. Cool, that.

So what are you waiting for? Click the link and register. The webinar happens Wednesday February 15, at 2:00 p.m. EST.
 

Using persistent publish/subscribe (PPS) messaging in medical devices

A QNX-based medical demo
equipped with PPS messaging
and a Qt user interface.

In early 2010, I published two posts (here and here) on persistent publish/subscribe messaging, aka PPS. The posts explored the advantages of PPS over other forms of interprocess communications (IPC) and why it makes automotive instrument clusters, smart energy panels, and other devices easier to develop, maintain, and upgrade.

In a nutshell, PPS lets you create loosely coupled designs based on asynchronous publications and notifications. This “decoupling” offers a great deal of flexibility, allowing you to delay final decisions on module connection points and data flow until runtime. Because such decisions don’t have to be hardcoded, they can be adapted as requirements evolve; they can even change dynamically as the system runs.

It's almost 18 months later, and the two posts remain in the top 10 of my most popular articles. Just one problem: Neither post discusses how PPS could be applied to medical devices — Quelle horreur!

Fortunately, my QNX colleague Justin Moon has filled the gap with the article "Persistent Publish/ Subscribe Alleviates Development Pains in Medical Devices." Read it here in Medical Electronic Device Solutions (MEDS) magazine.
 

No SOUP for you? Using off-the-shelf software in medical devices

A three-part video that explores the role of SOUP in safety-critical products.

Would you put this
in a medical device?

You can build a perfectly safe railway braking system if you never allow the train to move. And you can build a perfectly safe drug infusion system if you never allow it to infuse anything. But what's the use of that?

In the real world, designers of medical devices and other critical systems have to create products that are both safe and functional. They also have to satisfy time-to-market pressures: A safe system is no good to anyone if you take too long to build it.

To cut development time, manufacturers in many industries use commercial off-the-shelf (COTS) software in their products. But medical manufacturers have been reluctant to follow suit. They worry that COTS means SOUP — software of uncertain provenance. And SOUP can make a mess of safety claims, not to mention approvals by the FDA and other agencies.

Or perhaps not. When it comes to SOUP, my colleague Chris Hobbs argues for a nuanced approach. He states that if manufacturers distinguish between opaque SOUP (which should be avoided) and clear SOUP (for which source code, fault histories, and long in-use histories are available), they will discover that COTS software is, in many cases, the optimal choice for safety-related medical devices.

Chris isn't a lone voice crying in the wilderness. He notes, for example, that IEC 62304, which is becoming the de facto standard for medical software life-cycle processes, assumes manufacturers will use SOUP.

Enough from me. Check out this three-part video in which Chris explores the ingredients that can make SOUP the right choice for a medical software design:

Part 1


Part 2


Part 3


Webinar alert
Yesterday, Chris and his colleague Justin Moon presented a webinar on this very topic. If you missed it, no worries: It should soon be available for download through the QNX webinar page.
 

Adobe MAX: Developing AIR apps for the BlackBerry Tablet OS

Interested in developing for the BlackBerry PlayBook? Then check out the presentation that Julian Dolce delivered last month Adobe MAX.

The presentation, titled "Developing AIR apps for the BlackBerry Tablet OS," covers all the bases, from touch gestures and camera capabilities to UI components, alert dialogs, and Webkit support. Better yet, Adobe has posted the presentation with a hotlinked index, allowing you to jump to any topic.

To view (and listen to) the presentation, click here.

BTW, Julian is a senior flash developer at QNX. Previously, he worked as director of creative technologies at Fuel Industries, a company that specializes in online branded entertainment. His twitter handle is http://twitter.com/juliandolce
 

Adobe MAX: Developing AIR apps for the BlackBerry Tablet OS

If you're attending Adobe MAX this week, be sure to catch Julian Dolce's session on developing Adobe AIR apps for the BlackBerry^® Tablet OS.

Julian's a dynamite speaker (catch of glimpse his style here), so I promise you'll stay awake for the entire session. He's going to demonstrate key features of the BlackBerry Tablet OS SDK, as well as how to publish apps for it.

Julian will deliver his presentation twice: Monday, Oct 25, at 2 pm, and Wednesday, October 27 at 3:30 pm.

To register for Julian’s Session, click here.

Julian's Twitter handle: http://twitter.com/juliandolce

NEWS FLASH: Earlier this morning, RIM announced that the new BlackBerry Tablet OS SDK and BlackBerry PlayBook simulator are now available for download. Click here for the full skinny.

 

QNX Persistent Publish/Subscribe Service, Part II

News Flash: The persistent publish/subscribe service from QNX has just been shortlisted for a 2010 embedded AWARD. (Yeah, I know, the capitalization is weird.) QNX Software Systems has won two of these awards in the past. Can it score a hat trick? Stay tuned for updates.

And now, back to our regularly scheduled programming...

In the first installment of this two-part series, I provided an overview of PPS and explained how it offered several benefits over the direct, point-to-point connections often used for interprocess communication. Compared to these "brittle" approaches, which tend to break when new features or requirements are introduced, PPS allows developers to create loose, flexible connections between components. As a result, it becomes much easier to add, remove, or replace components without having to modify other components.

Example: Smart energy panel

To appreciate the benefits offered by QNX PPS, consider a smart energy panel that lets a homeowner control heating, air conditioning, burglar alarms, and other subsystems. This system would include temperature sensors, an on/off thermostat, and an HMI that displays the state of the various subsystems.

In a traditional system, the sensors and the HMI are tightly coupled. The HMI often knows exactly what hardware it’s talking to, which makes changing or introducing new devices very difficult. With PPS, the sensors and other devices don’t communicate with the HMI directly; rather, they become publishers of data objects. As a result, it becomes easier to swap out underlying hardware or to add new brands of temperature or control mechanisms. Just as important, multiple panels throughout the home can subscribe to the same objects, without worrying about the impact of multiple callers to a low-level sensor API.


A smart energy panel that uses PPS.

For a whitepaper that goes into more detail on using PPS in a smart energy/building automation system, click here (registration required).

Example: Automotive instrument cluster

For another example, consider an automotive instrument cluster that includes a speedometer, tachometer, temperature gauges, and other instruments. A CAN stack acquires the speedometer and RPM data from the CAN bus and, when new data arrives, issues callbacks into the cluster’s HMI. In a conventional implementation, any modifications to the underlying stack or protocol are directly reflected in the API, forcing modifications to the HMI.

In the PPS model, the CAN stack publishes two data sources, RPM and speed. The HMI then subscribes to those data sources. This loosely coupled approach allows developers to replace or modify the underlying stack or protocol without having to make any changes to the HMI. Prototyping and parallel development are also simplified, since developers can easily simulate the RPM or speed data if the hardware is still being developed.

Persistent storage

PPS provides a key feature for systems running in harsh or unpredictable environments: persistent storage. For instance, in a smart energy system, a user’s requested zone temperature, if implemented as a published data object, will persist across a system restart or power outage.

When the system comes back up, the data object will retain the same temperature value it held prior to the interruption. On startup, PPS will restore the data object, either immediately or on first access — the developer can choose either option.

Designed for humans

When designing a PPS service, you have to decide early on whether it will use binary or human-readable objects. The binary option results in smaller objects. The human-readable option makes for simpler development and debugging. QNX chose door number 2.

Human-readable objects allow developers to debug from the command-line using simple file system utilities, such as cat for subscribe and echo for publish. They also make it easy to create a simple program that subscribes to an object and prints out debugging information, including PPS object and attributes.

For instance, to display all PPS objects in a system, you can simply type:

ls -lR /fs/pps/

To create, query, or modify QNX PPS objects, developers can use industry-standard POSIX API calls: open(), read(), write(), and so on. For instance, to publish to a PPS object, a publisher simply calls open() for the object file. The publisher can then call write() to modify any attribute of the PPS object.

Likewise, to subscribe to an object, a client simply calls open(). The client can then query the object with read(). In response, PPS returns the object name, followed by the object’s current attributes.

For instance, if a car multimedia system publishes the metadata for the currently playing song in an object called “PlayCurrent”, a subscriber that queries PlayCurrent with read() might see something like this:

@PlayCurrent
author::Beatles
album::Abbey Road
title::Come Together
duration::3.45
time::1.24

Caveat: This section provides a high-level overview. Read the preliminary PPS docs to get the full skinny.

Flexible design options

PPS keeps your options open. For instance:

• Multiple publishers to the same object — Multiple publishers can publish to the same PPS object, and each publisher can “own” a different attribute of the object. In a multimedia system, for instance, one component may be the source of a “time::value” attribute, while the HMI may be the source of a “duration::value” attribute.


• Multiple subscribers — PPS clients can subscribe to multiple objects and PPS objects can have multiple subscribers. When a publisher changes an object, all clients subscribed to that object are informed of the change.


• No artificial limits — The number and depth of PPS directories and the number of PPS objects in a directory are limited only by available memory.


• Push and pull — By default, QNX PPS functions as a push publishing system. But it also allows a subscriber to pull data from a publisher, so that publishing occurs on demand.

Reliable storage

Persistent storage requires a reliable file system. So in addition to PPS, QNX Software Systems also provides a choice of high-reliability file systems, including a power-safe disk file system, an embedded transaction file system for NAND flash, and a fault-tolerant file system for NOR flash. PPS can also work with customer-created file systems.

So there you have it: a less brittle way to connect software components together.

p.s. To read Part I of this two-part series, click here.

p.p.s. Thanks again to Andy Gryc for all his invaluable contributions. Thanks also to Nicola Vulpe for making the PPS docs human readable. :-)

QNX Persistent Publish/Subscribe Service, Part I

“There are various reasons that software tends to be unwieldy, but a primary one is what I like to call ‘brittleness’…”

— Jaron Lanier, quoted in an article by Jack Ganssle

“[Roll-your-own] solutions tend to be designed and implemented based on initial connectivity requirements and thus are very brittle when new requirements are introduced. They typically rely on direct, point-to-point connections between communicating applications/components…”

— Jerry Krasner, from an article on Embedded.com

Brittleness. It’s a word that few people associate with software. But to implement connections between software components, C and C++ developers must often define exact and therefore fragile function prototypes. As a result, a change in one component can necessitate a change in other components. For instance, if a developer needs to change the status information returned by a device driver, they might also need to implement a corresponding change in the human machine interface (HMI).

This tight coupling makes things difficult for many embedded designs, particularly those that combine low-level control with high-level user applications. Take, for example, a realtime system for motor control that uses an HMI based on Adobe Flash. The Flash team may have little, if any, idea as to how to design a realtime system, let alone communicate with it. And the realtime team might have zero experience with Flash. The two teams live in different worlds: how do you bridge the gap?



To address these challenges, QNX Software Systems has introduced a Persistent Publish-Subscribe (PPS) service for embedded systems. Small and extensible, PPS allows developers to build loosely connected systems based on asynchronous publications and notifications. PPS also offers data persistence across reboots.

Creating decoupled designs

PPS provides an object-based system that consists of publishers and subscribers: publishers modify the properties of data objects and the subscribers to those objects receive updates when the objects have been modified.

With PPS, publishing is asynchronous: the subscriber of a service doesn’t have to wait for the publisher. This approach eliminates work for the subscriber process, as it doesn’t have to spawn a new thread to receive information from the publisher, synchronize the return of data with that new thread, or poll for a result.

In fact, the publisher and subscriber don’t have to “know” each other; their only connection is an object that has a meaning and purpose for both of them.

This “decoupling” gives the development team greater flexibility, as they can delay decisions on module connection points and data flow until runtime. Because such decisions don’t have to be hardcoded or directly linked, they can be adapted as situations or requirements evolve; they can even change dynamically as the system runs.

In many ways, PPS is similar to process control systems where the objects are control values updated by hardware or software. Subscribers can be alarm-handling code, displays, and so on. In fact, PPS is well-suited to such systems, as well as to others that have a similar data model.

Scalable, persistent, and language independent

PPS offers many benefits, including:

• Loose coupling for scalable design — With PPS, you can easily plug in (or plug out) different publishers or consumers of a data source, without having to create a fine-tuned, highly synchronized API between components.
  


• Greater flexibility than conventional IPC — PPS goes beyond the conventional one-to-one relationship between software components. It also supports one-to-many relationships (one publisher, multiple subscribers) and many-to-one relationships (many publishers, one subscriber).



• Data persistence across reboots — PPS allows data sources to survive a reset, without the need for any special software logic. This state-saving capability, useful for a variety of industrial and automotive environments, is built in: the developer doesn’t have to design or implement any special data failsafe mechanisms to take advantage of it.



• Language independence — Because PPS leverages the services of standard POSIX file systems, it can work with any programming language or application environment, including C, C++, Java, Adobe Flash, ksh, and others. Components written in completely different languages can intercommunicate, without requiring any special knowledge of one another.

In Part II, I cover a couple of short examples that show how developers can use PPS in industrial and automotive systems.

Acknowledgment
My colleague Andy Gryc provided invaluable assistance while I was writing this post. The insights are his; any errors are mine.

MulticoreInfo selects best multi-core posts of 2009

In 2009, the folks at MulticoreInfo published 1800 blog posts on multi-core computing. A couple of days ago, they selected what they believe were the top 10 posts of the year.

I haven't finished reviewing the selected posts, but I've already bookmarked a couple of them. One offers an introduction to parallel computing and other topics; the other explores the difference between concurrency and parallelism — two words that people often use interchangeably. (Count me among the guilty.)

You'll also find links to OpenMP, OpenCL, CUDA, MATLAB, Grand Central Dispatch, and many other topics, both introductory and advanced. To view the article, click here.

Rx for ACVA (Acute Computer Virus Anxiety)

Earlier this week, my computer got hit by a virus — and a nasty one at that.

Being the calm, collected person that I am, I immediately went ballistic. Which resulted in a Class A headache. Which degraded into neck spasms. Which made me crabby. Which made everyone around me crabby. Which made me even crabbier.

But here's the thing: Nothing could lift me out of my funk. And believe me, I tried everything: diazepam, muscle relaxants, jogging, jumping jacks, Jack Daniels, aromatherapy, massage therapy, music therapy, cognitive therapy, psychotherapy, Oprah, peyote, naturopaths, green tea, Ovaltine, Prozac, Muzak, Mongolian throat singing, transcendental meditation, mystical levitation — the whole nine yards. Nothing worked.

Finally, my IS department intervened. They handed me a tool that had proved efficacious in similar situations and encouraged me to engage in some, ahem, therapeutic behavior:



In case you're wondering, I feel much better now, thank you.

Cool Eclipse CDT shortcuts

A sneak peak at an upcoming Eclipse webinar

I’m totally addicted to PhotoShop. But, like every other PhotoShop user, I’ve resigned myself to the fact that I’ll never really master the program. It simply has too many tools, any of which can be used in a thousand different ways.

Eclipse CDT is a lot like that. It’s so feature rich that you can take years to become a true power user.

My colleague Andy Gryc, who has helped customers with their Eclipse issues, has seen this problem first hand. And it gave him an idea: What if he canvassed a number of advanced Eclipse users and collected their favorite productivity tips?

Well, he did just that, and the result is a new webinar called “Hot Tips and Tricks for the Eclipse IDE.” I just got an early look at the content, and it’s shaping up to be a great session for anyone who wants to squeeze the most out of their Eclipse-based toolset.

Andy plans to cover automatic code formatting, code folding, advanced search, automatic refactoring, call hierarchy navigation, plug-ins, keyboard shortcuts, custom breakpoint actions, and many other techniques for boosting productivity — more than two dozen topics in all.

Sample techniques
To give you a taste, here are a few techniques that Andy will cover. Keep in mind that I've chosen some of the simpler examples — the webinar will also explore more advanced topics.

Viewing definitions and prototypes
If you press <Ctrl> and hover your pointer over an identifier, it transforms into a hyperlink. Simply click the link to view the identifier’s definition or prototype:



Prompting for command-line arguments
To prompt for command-line arguments when launching an executable, go to the program’s Launch Configuration, click the C/C++ Program Arguments tab, and insert the ${string_prompt} literal:



Detaching views
If you use multiple monitors, detaching a view from the main window can come in really handy. Simply right-click on the header and select Detach:



Again, this is just a sample — Andy will also cover template proposals, variable directory paths, automated header file include, function completion, automatic structure completion, expansion of #define’s, version compare, and many other techniques.

The webinar occurs Thursday, December 10, 2009 at 12:00 noon EST. For more information or to register, click here.

Remember, though, to fire up your Eclipse environment before entering the webinar. That way, you can try out the techniques in real time.

Cool browser keyboard shortcuts

Hey, are you one of those people who still types the complete URL of every website they visit? Well, stop doing that and use the following shortcuts.

For instance, if you type qnx in your browser address field, then press <Ctrl>-<Enter>, your browser will immediately go to:

   http://www.qnx.com

Firefox provides extensions to this shortcut to help you jump to .org and .net sites. For instance, if you type ngconnect, then press <Ctrl>-<Shift>-<Enter>, you get:

   http://www.ngconnect.org

And if you type sourceforge, then press <Shift>-<Enter>, you get:

   http://www.sourceforge.net

In this case, the actual URL is http://sourceforge.net, but the resolution is handled automatically.

These shortcuts provide a nice complement to the automatic URL completion that most browsers now support.

How about you? Do you have any browser shortcuts that you'd like to share?

Need to parallelize your code for multi-core execution?

I'm always on the lookout for websites and tutorials dedicated to writing parallel code, so I was glad to see that Intel's Clay Breshears has written a new programmer's guide called The Art of Concurrency.

I don't know anyone who has used the book — not a surprise, given that it only comes out in May — but the premise looks good. Rather than focus on theoretical programming models, the book promises to provide a hands-on, experience-based approach to parallelizing existing code.

To learn more about the book, visit the O'Reilly website.

Anything good on your geek shelf?

I’ve been enjoying QNX’s new Pocket Geek game and have come to a few conclusions about the diminutive coder:

• He’s a die-hard command-line user (never touches the mouse)
  
  
• He works in an extreme-programming environment (never codes more than 40 hours a week)
  
  
• He’s concerned about IP contamination of his code (if that isn’t why he kisses his black duck, I don’t want to know about it)
  
  
• He owns a penknife (how else do you sharpen a pencil as thick as your forearm?)
  
  
• He never consults his reference library

Now that brings up an interesting point. At no time in the game does the Pocket Geek ever consult the massive tomes looming over his head. So why does he keep them?

If you’re a techie, you probably have a few reference books on your shelf. Are they all gathering dust, like the ones in the Pocket Geek game? Or has one made a real difference to your skills and productivity as a software developer?

Think of it this way: If the Pocket Geek were to read one book that would raise his productivity to new heights, what would it be? The 7 Habits of Highly Effective People? Extreme Programming Pocket Guide? The Joy of C?