We certainly don't mean to be "All Toyota All the Time" news; but we wanted to make sure that our readers have the opportunity to see snippets of what went on in the court room of Bookout v Toyota in Oklahoma. We created an exclusive three-part series based on trial transcript. The story above is the last in the series. The two others include:
Kris, I am glad you feel that way. This case, I think, has legs, since most consumers as of today still believe that Toyota case is an old story; it's finished with Toyota's recall of millions of vehicles. But another trial, just like this one (buildling the case on the software flaws), is about to start in Santa Ana, Calif. next week.
Again, this vehicle in the Oklahoma case, 2005 Camry, by the way, is NOT on Toyota's recall list.
"Q. So in other words, if you're driving down the road and you put your foot on the brake to slow down, for whatever reason, during that time period task-x is where it actually dies, the vehicle starts to accelerate.
You've got to actually back off the brake and try and catch it?
A. That's correct. Which is both counter intuitive because your car is zooming away and you have to let go of the brake. And it's also dangerous because as you let off the pressure of the brake, at least you were applying some mechanical pressure, but as you let off the car speeds up. And so that may increase the risk in the short term, at least, before this fail-safe would take effect."
This is absolutely amazing! Counter intuitive - I'll say so!
It is interesting to note however that many sudden accelerations seem to happen as the driver is pulling in gently to a parking space or pulling out of a parking space. Could it be that with very light braking the brake switch is giving a rather indeterminate signal to the ECU which is being misinterpreted? This needs teasing out more
Actually, on the contrary, this testimony sounds less damaging to me.
First, the brakes did work throughout task x death.
Second, the problem of power not being cut, when brakes were applied, only occurs if task x death occurs WHILE you are braking. Otherwise, it seems that braking did cut the power. Just that the driver neeeds to be awake enough to realize that speed is going up and up.
Third, it's not all that un-intuitive to pump the brakes if you feel they aren't doing the job. Just like you push again and again on the leveator button, if the eleveator doesn't come. This detail had already been explained, actually. But last time around, it was not clarified that death of task x only made the brake fail-safe incomplete if task x died while the brake pedal was pushed in.
Thanks Junko for the detailed coverage. The analysis described in the transcript is very useful & educative. As an engineer who has worked on non-critical automotive code, the article series gave a whole new understanding of the challenges and process required to test & qualify a critical automotive system
"We can't just wait around for that particular bit to flip, which may take a long time."
The quoted testimony does not reveal much detail about the nature of the forced failure testing. Was this bit flip part of EDAC-protected memory, and if so, were multiple bits flipped? Specifically, was the test designed to overpower the error detection & correction capability of an error correcting code applied to particular variables in memory, or was this an example of memory locations that were unprotected?
If you are testing an error correcting code in an application, you know in advance the power of the code, as allocated to detection vs correction of bit errors, so you know in advance that the code can detect up to X errors in Y bits, and correct up to Z errors in the same Y bits, so part of your testing would be to confirm the behavior when you overwhelm the code with too many errors.
I'm not suggesting anything, just asking questions about how the testing was conducted, and how it relates to proof of what really happened on the road.
As development or verification engineers know, during the course of product development, design & verification teams can be somewhat adversarial in the sense that verification's job is to find ways to break the design, and there are always ways to break a design -- any design. The question then becomes whether the conditions that break the design are in scope or out of scope with respect to the requirements that must be met. If the only breakage is out of scope and the design meets all of its requirements, it likely moves forward to production.
It is also noteworthy that it appears that the brakes still functioned even under Task X death, if they were pumped. Whether pumping the brakes in an emergency could be deemed expected driver behavior might depend on whether one assumes the driver is a younger person who has no experience with non-ABS brakes, or an older driver who learned the pump the brakes technique in a pre-ABS era.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.