Software Quality a Matter of Life or Death—and Not Just for the User.

  • Page 1 of 1
    Bookmark and Share

I think it started with that little “check engine” light. I had for some years been blissfully driving a number of cars that were equipped with the enigmatic little light but had managed to avoid any concern because none of them had ever lit up. But now... The first thing I did was open the hood to check and yes, the engine was still there—but now what?

A warning light like that is disconcerting because unless you have invested in one of those do-it-yourself scan tools, you don’t know if you’ve got a minor intermittent problem or some potential costly major failure staring at you. The only thing to do is to take the car in and trust the tender mercies of the repair shop or dealer. And I have a hard time trusting any of them, and the little light, now whether off or on, is a constant source of unease.

It turns out that the little “check engine” light mostly monitors mechanical conditions, primarily those that might affect emission system compliance as mandated by federal regulations. In my case, a squirrel had started to build a nest in the duct leading to my air filter, but the service guy said, “The average ‘check engine’ costs around $350.” I got off for considerably less. Still, the light can also come on for much more serious problems. You can’t tell by just looking at it.

More recently, however, we are facing cars with ever greater software content that affects not only the peripheral functions but also the vital operation and safety features of the vehicles. And when I refer to cars here, I’m also talking about the entire world of devices and systems that surround us all in our daily lives. Cars just happen to be the most familiar of such situations and the ones with the most immediate user interface that can directly affect our well being.

As Toyota executives sit squirming before Congressional committees wishing they could just be waterboarded and have done with it, the suspicion is starting to turn toward “electronics”—read software—as possibly being behind a lot of the recent problems and is something that they really don’t want to talk about. And this does not just apply to Toyota. The software content of automobiles in general is on a rapid growth curve in engine control, braking systems, steering and more. In some cases, such as the systems that are designed to prevent rear-end collisions, it can actually make decisions for the driver.

Add to this the recent demonstration in which the police were able to contact OnStar and have a car-jacked vehicle remotely disabled, and we must realize that automotive software can also be susceptible to remote hacking. So like every other connected system on the planet, cars are also vulnerable to internal software bugs as well as to outside unauthorized access. What if some hacker got into OnStar and was able to send some global command that caused all OnStar-equipped vehicles to be disabled?

There is, of course, a huge motivation on the part of developers to produce bug-free secure code for use in mission- and life-critical systems. In addition, there have been major advances in tools and methodologies to analyze code for correctness; there are seminars and courses devoted to bug-free software development and all of these are hugely positive advances. They are battling the twin dragons of increasing complexity and time-to-market (read $$$). The recent fiasco involving Toyota has shown us where concessions to the twin dragons can lead, especially when coupled with corporate arrogance. This can easily apply to vital systems outside the automotive arena as well.

First, no amount of testing and verification can give 100 percent assurance that code will be correct under all circumstances. Why? Because the lab is not the real world. Because the time it would take to rigorously test and verify several million lines of C code to the point of 100 percent assurance would have to deal with the sun becoming a red giant. So we reach a level of comfort, or an estimate of liabilities. What you don’t do is what Toyota has done and try to convince yourself that everything is just fine. That is going to cost them billions.

Far better to assume from the outset that there will be problems, however seldom or seemingly minor, but perhaps life-threatening. Having a staff and a protocol in place to examine, deal with and correct such things immediately does two things. For one thing, it avoids disaster of the scale we have witnessed with Toyota. Second, even if problems remain minor, it impresses customers in ways that will bear fruit well into the future by positioning the company as responsive, focused on quality and the customer. You can’t enter numbers for this into a spreadsheet, but the potential losses that can be suffered by not doing it should now be clear to all.