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.

I've got to get me one of these!

Anyone who has grown up where the snow stays on the ground 6 months a year will know why. Heck, even folks who've never seen snow will understand.

If you're feeling particularly ADD, just jump to the 2:03 mark. But be sure to hang on to your shorts:

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.

Japan's high-tech innovations take on natural disasters

Guest post by my inimitable colleague Noko Kataoka.

Noko Kataoka

When I’m talking to my family in Japan, the conversation often turns to the weather. Not because we have nothing else to talk about, but because the weather is such a serious subject in their region. They experience heavy rainstorms in early summer (followed by scorching heat that lasts for over two months), ferocious typhoons in the fall, and blizzards in the winter that can drop up to 50 cm of snow overnight. Every time I hear a severe weather report I need to call my family and make sure they’re okay.

And, of course, Japan is known for its earthquakes. The country is still working to recover from the “311” (March 11, 2011) disaster, one of the worst earthquakes and tsunamis in history, which killed more than 18,000 people. The country has had to put a lot of thought into how more lives could be saved when Mother Nature chooses to strike again.

Logo of the
Saigai Taisaku Expo

The good news is, Japanese people are very good at advancing technology to address their unique environment. Government agencies and businesses work together on innovative ways to respond to environmental challenges. The country even has tradeshows dedicated to technologies for coping with natural disasters. For instance, the Saigai Taisaku Expo (Disaster Response Expo) showcased many ingenious solutions this year — from highly sophisticated portable toilets for evacuation camps to smartphone apps for earthquake warnings. Here are some solutions that I found interesting:

• An unmanned airplane for establishing radio communications in isolated communities that have suffered infrastructure damage.
   
• A helmet loaded with a head-lamp, radio, earthquake sensor, and wireless communications unit. The helmet not only protects you from physical shocks but also sends emergency messages for safety confirmation, evacuation guidance, and more.
   
• An earthquake estimator that uses earthquake forecast information issued by the Japan meteorological agency to estimate the magnitude of an imminent quake and how long before the shock hits. It can be integrated with public broadcasting systems or digital signage to guide people to safety.
   
• A smartphone navigation app especially designed for natural disaster situations. Using information from GPS and camera, the app displays directions for designated evacuation areas.
   
• An unmanned 3D radar system for estimating damage to buildings. Okay, your building is still standing after a big earthquake — but how do you know if it’s safe to go in?
   
• A public information system that consolidates and manages big data collected by the crisis management information center. In the state of emergency, people can access to emergency-response information they need from their mobile devices.
   

It is particularly interesting to see how new innovations are made possible by technologies such as smartphones and cloud connectivity. We have little immediate influence on how Mother Nature behaves, but people can engineer solutions to help survive natural disasters. And with global climate change causing unexpected weather across the planet, Japan’s innovations in connected systems for environmental challenges may prove useful in other parts of the world, too.

I so need one of these!

You can work hard. You can work smart. Here's a robot vacuum that does both. It's called the Neato BotVac, and it uses laser technology to scan and map a room before cleaning it. Now, that's pretty cool.

Did I mention? It runs on the QNX OS.



Learn more about the Neato BotVac series of robot vacuums on the Neato website.

QNX drives home (quietly) with embedded award

QNX Acoustics for ANC eliminates the need
for costly dedicated ANC hardware.

Every year, the organizers of the Embedded World conference hold the embedded AWARDs to recognize the most innovative software, hardware, and tools for embedded developers. And this year, they selected QNX Acoustics for Active Noise Control, the new QNX solution for eliminating engine "boom" noise in cars, as the winner in the software category.

This marks the third time that QNX Software Systems has taken home an embedded AWARD. The company also won in 2004 for power management technology and in 2006 for its multicore tools and OS — and in 2010, it nabbed a finalist spot for its persistent publish/subscribe messaging. That's a lot of plaques.

So why did QNX Acoustics for ANC get the blue ribbon treatment? I can't speak on behalf of the Embedded World judges, but check out this overview I wrote a few months ago. Or better yet, read this deeper dive from my colleague Tina Jeffrey.

Or skip the middle man entirely and check out the product page, which does a nice job of summarizing what QNX Acoustics for ANC is all about.

A version of this post appeared on the QNX auto blog.