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.

Hypervisors, virtualization, and creating a safety-critical system that keeps up with the Joneses

A new webinar on how virtualization can help you add new technology to existing designs.

First things first: should you say “hypervisor” or “virtual machine monitor”? Both terms refer to the same thing, but is one preferable to the other?

Hypervisor certainly has the greater sex appeal, suggesting it was coined by a marketing department that saw no hope in promoting a term as coldly technical as virtual machine monitor. But, in fact, hypervisor has a long and established history, dating back almost 50 years. Moreover, it was coined not by a marketing department, but by a software developer.

“Hypervisor” is simply a variant of “supervisor,” a traditional name for the software that controls task scheduling and other fundamental operations in a computer system — software that, in most systems, is now called the OS kernel. Because a hypervisor manages the execution of multiple OSs, it is, in effect, a supervisor of supervisors. Hence hypervisor.

No matter what you call it, a hypervisor creates multiple virtual machines, each hosting a separate guest OS, and allows the OSs to share a system’s hardware resources, including CPU, memory, and I/O. As a result, system designers can consolidate previously discrete systems onto a single system-on-chip (SoC) and thereby reduce the size, weight, and power consumption of their designs — a trinity of benefits known as SWaP.

The QNX Hypervisor is an example of a 

Type 1 “bare metal” hypervisor.

That said, not all hypervisors are created equal. There are, for example, Type 1 “bare metal” hypervisors, which run directly on the host hardware, and Type 2 hypervisors, which run on top of an OS. Both types have their benefits, but Type 1 offers the better choice for any embedded system that requires fast, predictable response times — most safety-critical systems arguably fall within this category.

Moreover, some hypervisors make it easier for the guest OSs to share hardware resources. The QNX Hypervisor, for example, employs several technologies to simplify the sharing of display controllers, network connections, file systems, and I/O devices like the I2C serial bus. Developers can, as a result, avoid writing custom shared-device drivers that increase testing and certification costs and that typically exhibit lower performance than field-hardened, vendor-supplied drivers.

Adding features, without blowing the certification budget
Hypervisors, and the virtualization they provide, offer another benefit: the ability to keep OSs cleanly isolated from each other, even though they share the same hardware. This benefit is attractive to anyone trying to build a safety-critical system and reduce SWaP. Better yet, the virtualization can help device makers add new and differentiating features, such as rich user interfaces, without compromising safety-critical components.

That said, hardware and peripheral device interfaces are evolving continuously. How can you maintain compliance with safety-related standards like ISO 26262 and still take advantage of new hardware features and functionality?

Enter a new webinar hosted by my inimitable colleague Chris Ault. Chris will examine techniques that enable you to add new features to existing devices, while maintaining close control of the safety certification scope and budget. Here are some of the topics he’ll address:

• Overview of virtualization options and their pros and cons
   
• Comparison of how adaptive time partitioning and virtualization help achieve separation of safety-critical systems
   
• Maintaining realtime performance of industrial automation protocols without directly affecting safety certification efforts
   
• Using Android applications for user interfaces and connectivity

Webinar coordinates:
Exploring Virtualization Options for Adding New Technology to Safety-Critical Devices
Time: Thursday, March 5, 12:00 pm EST
Duration: 1 hour
Registration: Visit TechOnLine

A version of this post was published on the QNX Auto Blog.

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 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.

10 truths about building safe embedded software systems

I wish I could remember his exact words. But it has been a long time — 20 years — and my memory has probably added words that he never wrote and removed words that he did write. That said, this is how I remember it:

"We all strive to write bug-free code. But in the real world, bugs can and do occur. Rather than pretend this isn't so, we should adopt a mission-critical mindset and create software architectures that can contain errors and recover from them intelligently."

The "he" in question is my late (and great) colleague Dan Hildebrand. I'm sure that Dan's original sentences were more nuanced and to the point. But the important thing is that he grokked the importance of "culture" when it comes to designing software for safety-critical systems. A culture in which the right attitudes and the right questions, not just the right techniques, are embraced and encouraged.

Which brings me to a paper written by my colleagues Chris Hobbs and Yi Zheng. It's titled "Ten truths about building safe embedded software systems" and, sure enough, the first truth is about culture. I quote:

"A safety culture is not only a culture in which engineers are permitted to raise questions related to safety, but a culture in which they are encouraged to think of each decision in that light..."

I was particularly delighted to read truth #5, which echoes Dan's advice with notable fidelity:

"Failures will occur: build a system that will recover or move to its design safe state..."

I also remember Dan writing about the importance of software architectures that allow you to diagnose and repair issues in a field-deployed system. Which brings us to truth #10:

"Our responsibility for a safe system does not end when the product is released. It continues until the last device and the last system are retired."

Dan argued for the importance of these truths in 1993. If anything, they are even more important today, when so much more depends on software. If you care about safe software design, you owe it to yourself to read the paper.

Using dynamic code analysis to support FDA approval

Making a safety case for what goes
in the case

It isn’t enough to create a medical device that is safe to use. You must also demonstrate that it meets safety requirements. Otherwise, how do you know that it is indeed safe? And how can you have it approved by the FDA, MDD, MHRA, or any other regulatory agency?

If you’re familiar with such agencies, you’ll know that they approve the device as a whole, not its constituent parts. And yet, the device manufacturer must still present evidence to demonstrate the dependability of the device software. Hence, close attention to software development practices — together with appropriate validation tools and techniques — is key to securing regulatory approval.

Enter dynamic code analysis. Unlike static analysis, which analyzes source or object code without executing it, dynamic analysis examines compiled code while it is running. As a result, it tests not only the source code, but also the compiler, the linker, the development environment, and, potentially, the target hardware. Dynamic analysis generally involves code coverage analysis and unit testing; together, these can provide an effective way to detect software errors and to demonstrate what software has been exercised.

If you’re interested in how dynamic code analysis can support demonstrations of compliance with safety requirements, look no further than the recent paper, Using Dynamic Software Analysis to Support Medical Device Approval, written by Chris Ault of QNX and Mark Pitchford of LRDA. Among other things, it reviews the key capabilities of dynamic analysis tools and provides tables that map development activities with requirements in the IEC 62304 standard for medical device software.

QNX provides OS for new IEC 61508 certified robotics middleware

This just in: Systems Engineering Consultants (SEC), a leading realtime technology company in Japan, has developed new robotics middleware that runs on the QNX Neutrino RTOS Safe Kernel. Like the Safe Kernel, SEC’s middleware is certified to the IEC 61508 standard at Safety Integrity Level 3, or SIL3. (If you’re new to IEC 61508, this certification provides independent validation that a product offers a very high level of reliability when used in safety-critical systems.)

SEC designed the middleware, dubbed RTMSafety, to help manufacturers create safety-related systems for robots, including factory automation robots and personal-care robots used in medical and elderly care settings. RTMSafety allows robotics elements, such as actuators and sensors, to be treated as modular, reusable components.

According to Shintaro Sakurai, an executive director in the engineering division of SEC, “SEC has been working with industry groups and robotics societies to promote component standardization, which we believe will eliminate cost issues that have prevented commercialization of robotics. After much R&D effort, we are getting ready to move into the business phase to offer our customers an IEC 61508 certified middleware platform to run on the QNX Neutrino RTOS Safe Kernel.”

Suggested reading
To learn more about RTMSafety, read the press release.

To learn more about the design of safety-critical systems, read these whitepapers:
Using an IEC 61508-Certified RTOS Kernel for Safety-Critical Systems
Building Functional Safety into Complex Software Systems, Part I
Building Functional Safety into Complex Software Systems, Part II

And to learn more about QNX Software Systems' certified operating systems, visit the QNX Neutrino product page.
 

QNX releases 62304 compliant OS for medical device manufacturers

Building a medical device that meets strict regulatory requirements is a long and sometimes painful process. To help ease the pain (and more importantly, speed up pre-market qualification activities), QNX has released the new QNX Neutrino RTOS for medical devices, which complies with the IEC 62304 standard for medical device software life cycle processes.

If you develop software for medical devices, check out the product overview for the new OS. Then head over to the whitepaper section of the QNX website. You'll find several papers of interest, including:

• Choosing an RTOS for Remote-care Medical Devices
   
• Clear SOUP and COTS Software for Medical Device Development (includes discussion of 62304)
   
• Persistent Publish/Subscribe Messaging in Medical Devices

 

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.
 

QNX announces new wireless and medical solutions at Embedded World

A QNX-based patient-monitoring
demo, demonstrated this week
at Embedded World

This just in: QNX issued two announcements today, one focused on helping developers build wireless connectivity into embedded devices, the other focused on helping medical device manufacturers build products that must pass regulatory approval.

Wireless solutions — QNX has struck up preferred partnerships with LS Research and Silex Technology to develop pre-validated solutions based on ARM-based connectivity modules. Initial implementations will include the LS Research COM6L-BLE wireless evaluation module, which uses TI WL1271L silicon, and Silex wireless modules, which use the Qualcomm Atheros AR6003 Wi-Fi chip. QNX will provide first-line technical support to help customers speed up product design and commercialization. Read the press release.

OS for medical devices — QNX has also announced the upcoming QNX Neutrino Realtime Operating System for medical devices, which will comply with the IEC 62304 medical device standard for software life cycle processes. To further help medical-device manufacturers, QNX has introduced on-site audits, proven-in-use data, training courses on designing dependable systems, and assistance to meet compliancy requirements. Read the press release.

Both announcements coincide with the Embedded World congress in Nuremburg, where QNX Software Systems is exhibiting its latest products and delivering talks on in-field debugging, realtime scheduling, and publish/subscribe messaging.
 

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.
 

LDRA, QNX help medical device developers gear up on IEC 62304 standard

Image courtesy LDRA

Until a few weeks ago, I had never heard of LDRA.

My bad. LDRA has been in business for more than 35 years, developing tools that automate code analysis and software testing for safety-, mission-, security- and business- critical systems. (A lot of hyphens, I know, but did you really want me to say "critical" four times? :-)  In other words, LDRA has been helping systems work reliably for even longer than QNX.

Fortunately, my colleague Bob Monkman isn't as clued out as I am. In fact, he recently got together with LDRA to develop a new webinar, "Optimizing the Development of Certified Medical Devices".

The webinar, which happens this Wednesday at 2:00 p.m. EST, covers several topics, including:

• Using IEC 62304 development templates
• Specifying requirements to ensure requirements traceability through all phases of development
• Leveraging safe design training courses and pre-audit consulting
• Securing code — 70% of security vulnerabilities rise from programming errors
• Scheduling code inspections — early inspections eliminate errors
• Gaining IEC 62304 compliance using qualifiable and certified products from LDRA and QNX
   

Unified tooling
Don't go just yet. I also want to mention that LDRA recently ported their tool suite — which includes tools for lifecycle software testing for all phases of development — to the QNX Momentics Tool Suite and QNX Neutrino RTOS.

This makes for nice integration between LDRA tools and QNX tools. For instance, if the LDRA tool suite identifies a code violation, you can view the error interactively from within the QNX Momentics IDE — no need to switch tooling environment. Good, that.


Using the QNX Momentics IDE to inspect a violation caught by the LDRA tool suite.

To view two full-size screen captures showing LDRA-QNX integration, visit the Hughes Communications website.

And for more details on the LDRA suite for QNX, check out the press release.

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.
 

QNX updates EAL 4+ certified secure RTOS

This just in: QNX has announced an update to its QNX Neutrino RTOS Secure Kernel. The new version supports a greater variety of single-core and multi-core processors and boasts faster kernel performance in periods of heavy memory utilization. It also allows developers to take advantage of Persistent Publish/Subscribe (PPS) messaging, which I've discussed in previous posts (see here, here, and here).

Like its predecessor, the new version:

• offers certification to Common Criteria ISO/IEC 15408 Evaluation Assurance Level (EAL) 4+
• supports adaptive partitioning, an efficient form of time partitioning that prevents software processes from being starved of CPU cycles
• supports symmetric multiprocessing (SMP) on multi-core processors

Who is this product for? Primarily companies that build power plants, defense systems, subway control centers, government networks, and other mission-critical applications.

To find out more about the secure kernel, click here.
 

Whitepaper: Building functional safety into complex software systems, Part II

Recently, our local town councillor called a neighborhood meeting to discuss the construction of a new apartment building at the top of my street. Halfway through the meeting, one of my neighbors stood up and made this demand:

“I want a 100% guarantee that the blasting required for this project won’t damage the foundation of my house.”

Let’s face it. When it comes to anything that could threaten our property, our family, or our health, we all want a 100% guarantee. Problem is, the one constant in life is that there are no absolute guarantees.

This rule applies to software as much as to anything else. Just try to create a software system that is both reasonably useful and absolutely dependable. It’s well-nigh impossible. Unfortunately, the same rule also applies to software validation methods: no method is absolutely foolproof. The more complex a software system becomes, the more this rule applies.

A difficult pill to swallow? You bet. But acknowledging it is key to designing a system that successfully achieves functional safety.

Which brings me to Chris Hobbs’ latest paper, “Building Functional Safety into Complex Software Systems, Part II.” For Chris, functional safety must be built into a software system from day one. Moreover, all work should follow from the premise that software always contains faults and that these faults may lead to failures. We must, as a result, include multiple lines of defense when designing a system:

isolate safety-critical processes

reduce faults

prevent faults from becoming errors

prevent errors from becoming failures

All this begins with the best available expertise and a crystal-clear definition of the system’s dependability requirements — what Chris refers to as “sufficient dependability.” This definition is essential: It not only provides an accurate measure for validating the system’s functional safety, but also eliminates vague (and therefore meaningless) requirements.

We must also follow rigorous standards and practices throughout the system design and development, and implement a comprehensive validation program that includes not only traditional state-based testing at the module level, but also statistical testing and design verification.

I’m just scratching the surface of Chris’s paper. For the full story, download the paper here.
 

QNX unveils first RTOS to offer both safety and security certification

A couple of days ago, I mentioned that QNX always likes to make a big splash at the annual embedded world conference. Well, the big splash for this year is now public: QNX has taken the covers off the first RTOS product to provide both safety and security certification.

Yesterday, QNX announced QNX Neutrino RTOS Certified Plus, which offers both IEC 61508 certification at Safety Integrity Level 3 (SIL 3) and Common Criteria ISO/IEC 15408 certfication at Evaluation Assurance Level 4+ (EAL 4+).

The goal of this product is simple: To help developers of railway control systems, medical devices, automotive systems, wind turbines, and other mission-critical applications reduce the time and expense of certifying their end-products.

You see, safety and security certification at the system level can cost millions of dollars and take years to achieve. Using a pre-certified OS can help cut that cost and accelerate certification efforts. A few operating systems provide safety or security certification, but not both. QNX Neutrino RTOS Certified Plus is the first OS to fill this gap.

Whitepapers
Chris Hobbs, a kernel developer at QNX, has authored several papers on creating applications that meet rigorous reliability and functional safety requirements, including IEC 61508 SIL 3. For a list of these papers, see my previous blog post.
 

Whitepaper: Building functional safety into complex software systems

My colleague Chris Hobbs writes books, designs software, sings Schubert, teaches pilots, and, if all that isn't enough, pens papers on functional safety. Speaking of which, I've just started reading Chris's latest paper, "Building Functional Safety into Complex Software Systems, Part I," which contains the following anecdote:

"Thirty-seven seconds after it was launched on June 4 1996, the European Space Agency’s (ESA) new Ariane 5 rocket rained back to earth in pieces. This failure was rather costly: some US $370 million, and a stinging embarrassment for ESA.

It has become one of the best known instances of software that had been exhaustively tested and even field proven — in this case, more accurately, sky-proven — ceasing to function correctly though it had not been changed. What had changed was the context in which the software ran..."

This story highlights the paper's thesis: that the functional safety of today’s complex, multi-threaded software systems cannot be validated by traditional, state-based testing alone.

In theory, such systems are deterministic. And in theory, all of their states and state transitions can be identified. But in practice, these states and transitions are so numerous that they cannot be counted, let alone tested.

Does this mean we must throw up our collective hands in despair? Not at all, says Chris. He emphasizes that it is still possible to build functionally safe complex software systems — but since I don't want to spoil the story, I'll stop talking now and invite you to read the paper.

And while you're at it, I invite you to check out other papers Chris has written on safety-critical systems and software:

Fault Tree Analysis with Bayesian Belief Networks for Safety-Critical Software

Using an IEC 61508-Certified RTOS Kernel for Safety-Critical Systems

Protecting Applications Against Heisenbugs

 

Using an IEC 61508 SIL3-certified RTOS for safety-critical systems

An operating system (OS) kernel designed for safety-critical systems can't simply be reliable or elegantly designed. For instance, it must also:

• protect applications from harming one another or the kernel itself


• guarantee CPU time for higher-integrity code in systems that combine applications of different safety integrity levels


• allow the developer to predict when processes will be scheduled for execution


• prevent applications from acccessing or corrupting internal kernel information

The requirements become especially severe for an OS kernel certified at IEC 61508 Safety Integrity Level 3, or SIL3. In fact, a system certified at SIL3 must have a probability of dangerous failure below 1 in 10 million per hour of operation.

Achieving such a low risk of failure is non-trivial, to say the least. In fact, it's well-nigh impossible to satisfy the above requirements unless they are baked into the very design of the kernel.

Recently, Chris Hobbs of QNX wrote an article on the characteristics of SIL3-certified kernel. The article, published last week in Industrial Embedded Systems magazine, also touches on some development techniques for creating safety-related applications. To read the article, click here.

Support Package
If you are attempting to navigate the complexities of the IEC 61508 certification process, you might also want to check out QNX's IEC 61508 Certification Support Package.