Comments on: Toyota’s Embedded Software Image Problem

By: About Toyota « Dane's World

About Toyota « Dane's World — Wed, 14 Apr 2010 16:20:26 +0000

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

By: Niall Cooling

Niall Cooling — Tue, 30 Mar 2010 12:21:47 +0000

A good friend of mine (Dr. Brian Kirk), a leaning expert of software and system safety recently was part of a panel (including electrical engineers, a Toyota sudden acceleration car crash survivor, and car safety experts) providing a briefing on the myths Toyota uses to cover up the truth about sudden acceleration. Here’s a video of that:
http://www.youtube.com/watch?v=UJnN8IyIumg

By: Parag Barangale

Parag Barangale — Fri, 26 Mar 2010 18:07:22 +0000

I had a tricky problem which could not get detected, it appeared just once that too while the software was in development stage. I tried it to create it numerous times but it never came up. The device went till the delivery line, for prototype assembly line testing the test engg accidentally setup test bench wrongly and the problem came up.
Logically the code was doing the math operations correctly but I had to rearrange/break the functions for calculation and it resolved the bug.
Some times even code review does not reveal the problem. It gets real tough with embedded devices.
With Toyota I suggest the first thing is to do is to Accept. Unless you accept the problem its difficult to reach for solutions.

By: Tony Leigh

Tony Leigh — Thu, 25 Mar 2010 12:18:48 +0000

I’d be wary of having too much firmware in my car. It’s already hard enough to find car mechanics with a good enough understanding of mechanical engineering to fix difficult problems. Asking them to diagnose and fix problems like those above will only compund the problem. A colleague at work has problems with his BMW occasionally going into ‘limp’ mode for no discernible reason. The garage have had the car for a week, and still haven’t been able to fix it.

Introducing steer-by-wire and brake-by wire could be a minefield. Even if the systems are duplicated, how many cars do you see driving around with just one headlight? And let’s say the steer-by-wire system contains an algorithm to stop the driver turning too sharply and rolling the car. What happens if he swerves to avoid a pedestrian, but the system judges he might roll it and makes him run into the pedestrian instead. Whose fault is it? The driver’s? Or the steer-by-wire system? The lawyers would have a field day.

By: Sterling Eanes

Sterling Eanes — Thu, 25 Mar 2010 01:03:52 +0000

Edsgar Dijkstra said it in the 70′s: “Program testing can be used to show the presence of bugs, but never their absence.”

By: Jon Willoughby

Jon Willoughby — Wed, 24 Mar 2010 21:24:47 +0000

My Camry’s user manual has details on the event data recorder and the circumstances in which they will turn over the data to safety and law enforcement. This article suggests that, in reality, Toyota has been reluctant to do so.

http://www.ecnmag.com/News/2010/03/Toyota-black-box-data/

So what is going on?

By: Sreenivasa Reddy B

Sreenivasa Reddy B — Wed, 24 Mar 2010 12:27:03 +0000

During my career with a worlds leading automotive parts supplier I had comes across with a software design bug. The bug was “if some one jump starts the car when it is parked and key is off car would start running (in jump start the gear is engaged)”, this bug could occur during towing the vehicle while gear engaged, parked in downhill, etc. I was owner of the software module which had this bug. Some real world scenarios are next to impossible to assume while developing such software. Through verifications and validation is the mantra, even then bugs are part and parcel of software.
I would still buy a car which has more software of course not the one which has my code

By: Ayyappan Ramasamy

Ayyappan Ramasamy — Wed, 24 Mar 2010 03:59:58 +0000

They can not say that it is not reproducible.
I had an issue in my supported product and it was not at all reproducible as easily as possible. Then my approach was to give random commands to the device under test. Finally, the defect was reproduced. Problem here is to find the test sequence. So they have to test with random parameters to reproduce it. This may not be a logical one, but sometime we need this kind of testing.

By: Ian Rumley

Ian Rumley — Tue, 23 Mar 2010 23:45:26 +0000

Sometimes these kind of bugs are extremely hard to find. I have had two such memorable bugs in my career that shared some common characteristics: rarely occurred (once very few weeks at the most), and then only in the field, concerned communications (one parallel and one serial), and root cause went back to hardware and were relatively easy to fix. One involved a glitch that was only a few nanoseconds wide and was only found after a fast enough ‘scope was used, and the other a line on the MCU that the data sheet claimed was pulled high but in reality was floating. In both cases the appearance to the developers was simply that data magically appeared at the receiver.

By: Emil Fred

Emil Fred — Tue, 23 Mar 2010 20:29:10 +0000

There are several bugs that you see for a fleeting second during the development cycle. You may not care about it when you are trying to make the product work and it probably will never surface during product test cycle. These are the most dangerous ones especially if the process affected is a critical one. Bug tracking is needed right from R&D and not product testing.
The need for quality firmware is all the more important these days due to the amount of critical processes controlled by firmware like in cars.