From clean socks to secure transactions, QNX brings it all to Embedded World

Every year, QNX Software Systems exhibits at the Embedded World conference in Nuremburg. And every year, we like to mix things up and do something different. For instance, in years past, we have showcased a robotic vacuum, a heart defibrillator, a pipeline inspection system, an Oscar-winning flying camera, a programmable logic controller, and a control panel for bulldozers — all running on the QNX Neutrino OS.

What have we got lined up this year? Plenty, as it turns out. Once again, our booth will feature several QNX-based products, including:

• An innovative double-drum washing machine that cleans two loads of laundry simultaneously — finally, you can wash lights and darks at the same time!
• A Modular Train Control System (MTCS) from MEN Mikro Elektronik that complies with the EN 50155 functional safety standard and is based on the QNX OS for Safety
• A hardware security module from Worldline that protects secret keys and performs high-speed cryptographic operations for secure data transactions
• A traffic-light controller from SWARCO that helps improve traffic flow and optimizes the use of existing road infrastructure — learn more about this system in this morning’s press release

It’s hard to imagine four systems that could be more different. And yet, the developers of these systems all chose the same OS — a testament to the “bend it, shape it, any way you want it” quality of QNX technology. Not to mention its performance and reliability.

The Bluetooth connection
Of course, we can’t show up at Europe’s biggest embedded systems conference without bringing something new for embedded developers. And so, this year, we are demonstrating the QNX SDK for Bluetooth Connectivity, a new middleware solution for medical devices, industrial automation systems, consumer appliances, and other embedded system applications.

Designed for flexibility, the SDK offers a dual-mode Bluetooth Smart Ready stack that supports classic Bluetooth connectivity as well as connectivity to Bluetooth Low Energy devices. It also supports a comprehensive set of pre-integrated Bluetooth profiles, including the classic PAN, SPP, HDP, HID, FTP, and OPP profiles, as well as the BAS, FMP, HRP, HOGP, and PXP Low Energy profiles. Here’s the SDK at a glance:

For developers of infusion pumps, vital-sign monitors, and other medical devices, the SDK includes an IEEE 11073 Personal Health Data stack certified by the Continua Health Alliance. This stack enables easy interoperability with pulse oximeters, weight scales, and other Bluetooth-enabled peripherals, and addresses the growing demand for health devices that can wirelessly collect patient data, either at home or in a clinical setting.

Of course, the proof of the Bluetooth pudding is in the pairing. So we've also built a demo that shows how the SDK can help developers build vital-sign monitors and other connected embedded systems. The demo system can discover and pair with Bluetooth classic and Bluetooth Low Energy devices, render their data onto a touchscreen display based on Qt 5, and provide a history of heart rate, blood oxygen levels, and other vitals:

A screen capture of the Bluetooth-powered QNX medical demo

Read the press release and product-overview page to learn more about the new QNX SDK for Bluetooth Connectivity.

And if you are Nuremberg this week, drop by and see us! We’re in Hall 4, Booth 534.

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.

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.

Flying around the world on solar power

Did you miss it? I missed it. And I really wanted to catch it. Earlier this month — while I was paying attention to gosh knows what — the Solar Impulse team unveiled the first solar-powered aircraft capable of flying around the world. It’s called Solar Impulse 2, and it will embark on its round-the-world tour in March 2015.

The Solar Impulse team thinks big, but they also think smart. For instance, they didn't try to build a globe-circling solar plane right off the bat. Instead, they took a stepwise approach and built a plane that could fly shorter hops — across a continent, for example. The lessons learned from building and flying that first plane, which successfully crossed Europe, Africa, and the US, helped the team develop Solar Impulse 2.

Not surprisingly, Solar Impulse 2 is larger than its predecessor. The wingspan has grown from about 64 meters to 72 meters, the weight from about 1600 kilos to 2300 kilos, and the number of voltaic cells from about 12000 to 17000. That’s a lot of batteries.

Mind you, the numbers tell only part of the story. The Solar Impulse 2 project also required the development of innovative materials and construction methods, including new electrolytes to boost the energy density of the voltaic cells.

This story isn’t just about technology. It’s also about human skill and endurance. For instance, to cross the Atlantic or Pacific ocean, the plane, which has a top speed of 90 km/h, will need to stay airborne for about 5 or 6 days. And that means the pilot will have to sit in an unheated, unpressurized cockpit for more than 120 hours in temperatures that could range from -40°C to +40°C. These guys aren’t just smart; they’re tough to boot.

Did I mention? QNX Software Systems is the official realtime OS partner for the Solar Impulse team, and the plane uses the QNX OS for several control and data communication functions. Which is, well, cool.

The plane is scheduled to launch in about 310 days. And this time, I’ll be paying attention. By the way, here's the part that I missed:



See previous posts on the Solar Impulse project.

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.

Six QNX videos more people ought to see

Looking for examples of how people use QNX? You've come to the right place. From outer space to the automotive space, these six videos demonstrate the sheer flexibility and dynamic range of QNX technology. Better yet, you get to hear five users describe, in their own words, why QNX is important to what they do.

QNX in space
First up is Iain Christie of Neptec, the company responsible for creating the SVS and LCS camera systems on the NASA space shuttle. Highlight: when Ian explains the importance of QNX to the shuttle program (1:46). For more on the QNX-based LCS system, see my previous post.



QNX in the clinic
Next up is Vladimir Derenchuk of the Indiana University Health Proton Therapy Center, which uses proton beams to blast difficult-to-treat tumors. Highlight: it's all good, but listen to Vladimir explain why they chose QNX, and how it has helped with FDA approvals (1:34).



QNX in the HVAC
Next up is Hans Symanczik of Kieback & Peter, a German firm that has used QNX in building automation systems for more than 20 years. Highlight: when Hans explains the ultimate benefit of the QNX OS (2:07).



QNX on the air
Next up is Mikael Vest of NTP, a Danish company that supplies QNX-based audio routers to the global television and radio broadcasting industry. Highlight: Mikael himself, who gladly did this interview despite suffering from a flu to end all flus. A real trooper.



QNX on the road
Next up is Rick Kreifeldt of Harman International, a company known in the automotive industry for its ability to push the technology envelope. Highlight: the section where Rick's respect for the QNX team shines through (2:14).



QNX in flight
And last but not least is Thomas Allen from Mechtronix, a company that has developed an innovative, software-based approach to building flight simulators. Highlight: when Allen states that Mechtronix simulators effectively use the same software architecture as the QNX OS (0:45). Years, ago, someone explained to me how the QNX OS isn't simply a well-designed, modular OS; it also encourages well-designed, modular systems. In Mechtronix, we have an example.

Space-grade technology... in the palm of your hand

What does your phone have in common with planes, trains, automobiles, and space stations? If it's a BlackBerry 10 smartphone, plenty.

When you pick up a BlackBerry Z10 or BlackBerry Q10 phone, you are tapping into OS technology like no other. Technology that hospitals use to defeat cancer. Technology that power plants use to create energy. Technology that skyscrapers use to save energy. Technology that movie studios use to create mind-blowing special effects. And technology that calls for help if your car gets into an accident. In short, technology that makes a difference in my life, your life, everyone's life.

But enough from me. Especially when the video says it so much better...

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.

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.

Video: QNX-powered system fires protons to kill cancer

The QNX-powered proton therapy 
system, or PTS

It zaps cancer cells to kingdom come. Better yet, it wipes them out while leaving healthy cells alone. It's called proton therapy, and it's one of the deadliest weapons in the arsenal against cancer.

Conventional radiotherapy may be potent, but it has a drawback. It can sometimes damage healthy tissue, and this damage can lead to secondary cancers later in life — a problem among children, who may live for many years after treatment and who are more likely to suffer from this side-effect.

There is, then, a real need to avoid radiating healthy tissue while maximizing the damage to the diseased tissue. And that's where proton therapy comes in.

Surgical strikes
Protons are relatively heavy, charged particles. They do minimal damage as they pass through tissue, but inflict significant damage where they stop. The challenge is to control the proton beams so that they stop exactly where you want them — the tumor.

Enter the QNX-powered proton therapy system (PTS) at the Indiana University Health Proton Therapy Center. Using the PTS, a radiotherapist can limit damage mostly to where the tumor is located. The radiotherapist can even "mold" the proton beam into the same shape as the tumor. This accuracy makes proton therapy especially useful for treating tumors located near vital organs. It can also reduce long-term effects sometimes associated with conventional forms of radiotherapy. And it serves as an alternative for patients who have already received other forms of treatment and have incurred damage to healthy tissue as a result — proton therapy can minimize the possibility that more healthy tissue is affected.

Delivering the right dose
The PTS uses the QNX OS in its dose delivery system (DDS) — think of it as the business end of the PTS. The DDS controls devices on the system’s nozzle (the beam transport and detection hardware closest to the patient) and measures dose-related values. The DDS also implements an energy-stacking scheme to obtain uniform depth-dose distributions.

The QNX OS allows the DDS to achieve very fast response times. For instance, if beam delivery must stop for any reason, the OS helps ensure that it stops immediately — and in this application, immediately is the only viable option.



I'm feeling appreciative
Before I let you go, a word of thanks to the folks at the proton therapy center. A year ago, I approached them out of nowhere with a proposal to do a video. Their response was overwhelmingly positive. They willingly gave of their time to discuss the proposal, explain what they do, and, of course, work with us on the video itself. While I'm at it, I'd also like to thank my friend and colleague Nancy Young for her fantastic work on this and all the other QNX videos she has produced in the last couple of years. (Speaking of which, have you subscribed to the QNX YouTube channel yet?)

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.
 

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.
 

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.
 

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.

Video: QNX Hits the Airwaves with NTP Audio Routers

Imagine running a multinational radio service that broadcasts 1,500 hours of programs a day, in almost 60 languages, with transmitters that reach every nook and cranny of the globe — from Tirana, Albania to Houston, Texas.

That, in a nutshell, describes China Radio International, one of many international broadcasters that rely on QNX-powered audio routers from Danish company NTP Technology A/S.

Serving an audience of millions calls for seriously reliable equipment. It's no surprise, then, that NTP's audio routers are engineered for 24/7 operation, with self-monitoring capabilities, module hot-swapping, redundant power supplies, and, of course, the QNX Neutrino OS.

Why QNX? Because it offers the fault-tolerant software architecture that NTP needs to achieve nonstop operation. It also provides the realtime performance to handle multiple feeds and signals simultaneously, and the dynamic upgradeability to support new features without service interruptions.

Enough from me. Grab the popcorn, dim the lights, and listen NTP's Mikael Vest describe the challenges of modern broadcasting, and how QNX technology helps address them:



Before I go, I have to mention how much we enjoyed working with Mikael. When I cold-called him about doing a video, he immediately said yes. No hesitation, no maybe's, just a let's-do-it attitude. And when it came time to shoot the video, Mikael came through with flying colors, despite suffering from a flu to end all flus. A real trooper and a great guy.

For previous posts on NTP, click here and here.

 

Is multicore a viable choice for medical devices?

Will even relatively simple devices
eventually require multicore?

Multicore processors, and the software required to run on them, can increase the complexity of any embedded system. Some industries, notably networking, have long embraced this added complexity. The medical device market isn't one of them.

It's easy to see why, as this same complexity could potentially hinder or prolong the process of securing FDA approval for a medical device. Getting approval is already hard enough and long enough; any new technology that might further extend the ordeal is rightly looked upon with skepticism.

And yet, multicore is the way of the future for medical devices, save for relatively simple products. We've seen this trend in other markets, including automotive, and the medical device market will, in all likelihood, follow suit.

Should medical developers be concerned? Yes, but not too much. As my colleague Justin Moon argues, the techniques needed to validate multi-core medical systems are, in fact, the same proven techniques that developers already apply to single-core systems. These techniques include testing, statistical analysis, fault tree analysis, and design verification. Meanwhile, the tools and OS technology needed to create, analyze, and optimize multicore-capable applications are, in many cases, quite mature.

And, of course, let's not forget a key benefit of multicore: significantly increased performance (through concurrency) without an attendant increase in power consumption and heat dissipation.

But enough from me. To get the argument straight from the horse's mouth, read Justin's article, Smart OS strategy makes multicore viable for medical devices, which EE Times published earlier this month.

Testing, statistical analysis, and design validation complement one another to validate a software system, whether it is running on one or multiple cores. (Click image to magnify.)
 

QNX-powered flight simulators help airline pilots earn their wings

As a pilot, how do you learn to handle a critical problem, such as a hydraulic failure in mid-flight, when that problem may occur only once (if ever) in your career? And how do you practice difficult maneuvers until you get them right, without endangering yourself or anyone else? In a flight simulator, of course!

Mechtronix is one of the biggest, and fastest growing, flight simulator vendors in the world. And to get there, they've taken the road (or should I say flight path) less traveled. Rather than equip their simulators with all the hardware deployed on actual planes — the traditional method — they use software to replicate most of an airplane's behavior.

Eliminating hardware offers numerous benefits. It cuts costs dramatically. It makes the simulators lighter and easier to transport. And it makes them easier to maintain, since the customer no longer needs a specialized avionics engineer. But enough from me — let's hear Thomas Allen, VP of Technology at Mechtronix, describe the company's approach and how the QNX OS helps make it possible:



Two things stand out for me. The first is QNX's talent for juggling many concurrent tasks and gazillions of I/O points. This ability to support intense multitasking, while delivering fast and predictable response times, is essential to replicating the experience of flying a real plane.

Second, I was fascinated to hear how the system design adopted by Mechtronix parallels the architecture of the QNX OS. Years, ago, someone explained to me how the QNX OS isn't simply a well-designed, modular OS; it also encourages well-designed, modular systems. In Mechtronix, we have an example.
 

OIS ports ORBexpress communications middleware to latest rev of QNX Neutrino OS

You may not know it, but the QNX Neutrino OS is used in a large number of software-defined radio (SDR) devices, such as this handheld military radio from Harris. A key QNX partner in the SDR market is Objective Interface Systems (OIS), who make ORBexpress, a high-performance, real-time implementation of CORBA technology optimized for embedded systems.

This week, OIS announced that ORBexpress now supports the latest rev of the QNX Neutrino RTOS on a variety of ARM, Power, and x86 processors, including both single-core and multi-core parts. For more on the announcement, read the press release.
 

Taking QNX to the moon

Imagine driving a vehicle over rugged, unforgiving terrain filled with humongous rocks and craters.

I know, it sounds like a blast!

Now imagine if you had to control the vehicle via remote control.

Well, that could still be fun.

Now imagine if the signals from your remote control took 1.5 seconds to reach the vehicle, and if you had to wait another 1.5 seconds to see how the vehicle responds to your commands.

Hm, that could be a challenge.

In fact, overcoming this delay is just one of many challenges facing the 30 companies and development teams contending for Google Lunar X prize.

The mandate of the Lunar X prize is simple: Send a rover to the Moon; drive it for at least 500 meters; and transmit video, images, and data back to the Earth. The devil, of course, is in the details.

First of all, landing on the moon and beaming back videos only gets you the base prize of $20 million. To earn the full $30 million, your lunar rover has to drive at least 5000 meters, survive two weeks of minus 182 degrees C, and take a photo of the Apollo landing site. (Presumably, the photo would put to rest rumors that NASA filmed the moon landing in Neil Armstrong’s basement, but don’t count on it.)

Mind you, all this assumes the rover arrives safely on the moon in the first place. For that to happen, the lander module carrying the rover must travel more than 400,000 kilometers at maximum speeds of more than 10 kilomoters/sec. It must then decelerate by more than 2.5 kilometers/sec and fly a few hundred meters above the lunar surface until till it finds a nice cushy landing spot.

Meet Asimov, the latest incarnation
of the Part-Time Scientists' lunar rover.

So who the heck would take on such a challenge? The Part-Time Scientists, that’s who.

The Part-Time Scientists team is the first Google Lunar X PRIZE participant based primarily (though by no means completely) in Germany. They are also considered among the top 5 most likely teams to succeed.

I plan to post several articles on the team and their progress over the coming months, but in the meantime, consider this:

It isn’t 1969 anymore — The unmanned systems competing for the X PRIZE will need to pack a lot more software intelligence than the Apollo spacecraft. To handle the many real-time tasks on their lander and rover, the PTS team has chosen the QNX operating system.

These are guys are a blast — Most members of the PTS team have real jobs. They work on this project in their spare time, out of sheer love and enthusiasm. In fact, when they do publicity around their project, children represent a large portion of their target audience. They clearly want the next generation of budding scientists to share the same passion for engineering and space exploration that they themselves have. Good, that.

Stay tuned for subsequent posts, where will dig deeper into the role that QNX plays in this exceedingly cool project.

And did I mention? You can follow the Part-Time Scientists on Twitter and on Facebook.