This post is inspired by a discussion going on at LinkedIn’s Embedded Systems Group regarding Toyota’s problems with unintended/spontaneous acceleration of some of its cars. In the broader embedded systems community, there’s a suspicion that this is a firmware problem. A bug. Somewhere in the thousands of lines of code that control ignition, brakes and all the trinkets, there’s a malfunction that causes disjunction between pedal and throttle.
Here’s a video posted with the discussion. It’s from UPenn’s Wharton School and features professor Takahiro Fujimoto of Tokyo University. He’s an expert in Toyota:
Fujimoto: I was surprised to see that Toyota was the first to be caught in this trap of what we may call complexity problems. Society and the market are making stricter and stricter demands on all the cars and vehicles in the world. So this could happen to anybody. But I was a bit surprised that this happened to Toyota first, because Toyota executives had [issued] a warning about [being] in a very difficult situation regarding complexity. So they knew that this could happen to anybody.
His sentiment about complexity of manufacturing that degrades quality is echoed in the discussion of LinkedIn:
I think the auto manufacturers have gone too far in creating the complexity in the first place. And I make my living from that same creation process, so this is no small statement for me.
Here’s my opinion: complexity is a product of uncontrolled growth. For public companies, such uncontrolled growth is encouraged through pressure from stakeholders, customers and employees. Anyone who’s worked in a large (nationwide) company will know problems of interdepartmental communication. Though under one name, the company becomes segmented and often isn’t in sync with other parts. The left isn’t quite sure what the right is doing.
Another concern among the embedded systems community is that there isn’t any regulatory body in firmware standards for automobiles. As another poster in the LinkedIn discussion states:
The Toyotas, like other modern cars, are drive-by-wire cars. We have fly-by-wire aircraft. How do aircraft designers ensure very low probability of runaway acceleration during taxing, or landing?
I agree with Ian that “no matter what procedures you put in place it depends on the people doing the engineering”.
I think cars too will have to be designed, manufactured, operated and maintained with the standards and the mindset as in aviation.
Michael Barr, President of Netrino and a well respected expert in the embedded community discusses this in his blog post regarding Toyota’s woes. Although this is only a side note in his post, it carries a good message:
I think it is a net positive that journalists, the mass media, and a broader swath of the general public are increasingly aware that there is software embedded inside cars, airplanes, medical devices, and just about everything else with a power supply or batteries. Firmware has been inside these products for many years, of course. But as I wrote in a recent article in Electronic Design, my experience working with companies across many industries lead me to believe there is a looming firmware quality crisis. Greater public awareness is sure to bring litigation. This will force engineering management to care more about firmware quality than they currently do.
When I try and explain embedded systems to someone unaware, I usually get a response of surprise and amusement in the prevalence of firmware dependent devices in our lives. Most people don’t think about the c code and CAN busses that actually allow their vehicles to function, much less the mcu in their microwave that counts the cook time and turns the carousel at the same time.
But cars are dangerous; microwave less so. Maybe (and not that I know much about Toyota’s quality assurance methods) vehicle electronics should be treated more like medical devices. Ones where failure isn’t an issue. People love the magic of technology and that magic will only saturate our lives, and our vehicles, more and more.
Dane's World 