Toyota Case: Vehicle Testing Confirms Fatal FlawsMADISON, Wis. — Among the hundreds of cases brought by individuals across the United States claiming their Toyota vehicles accelerated without warning, only Bookout v. Toyota Motor, tried in Oklahoma County, Okla., resulted in a verdict against Toyota. This was also one of the first unintended acceleration cases to go to trial since the Japanese carmaker began recalling millions of vehicles in 2009 over this very issue. The Oklahoma case was also the first in which plaintiffs' attorneys put the fault squarely on a flaw in the vehicle's electronic throttle control system. They dismissed arguments about floor mats and sticky pedals and focused on the software that controls the electronic throttle. The attorneys supported their argument with extensive testimony from embedded systems experts. Similar testimony and extensive software analysis reports had been filed previously in other courts looking into unintended acceleration. But none of that material became public, because Toyota paid settlements and obtained gag orders before those cases went to trial. The public and the engineering community had to wait until the Oklahoma trial, where all testimony became public. A dozen embedded systems experts were allowed to review Toyota's electronic throttle source code in a secure room in Maryland -- described as the size of a small hotel room. The room, with a guard at the door, was disconnected from the Internet. No cellphones, paper, belts, or watches were allowed inside. The experts viewed Toyota's code on five computers in cubicles. Having spent more than 18 months going in and out of the secure room to study Toyota's code, Michael Barr, CTO of the Barr Group, put together an 800-page report analyzing the 2005 Camry L4's software. On the witness stand, he walked a jury step by step through what the experts discovered in their source-code review. According to Barr's testimony, that review revealed:
Barr testified that the source-code review indicated "both that task could die by the memory corruption, and that also that one of side effects of that would be that this -- for example, that task died, that many of fail safes would be disabled." But is it possible to prove that the experts' discoveries in that cloak-and-dagger source-code room would manifest themselves in a moving vehicle? How do we know how a car might react to malfunctions or an outright failure in Task X? The plaintiffs' attorneys noted that they actually conducted vehicle testing. Though Barr wasn't present when the vehicles were tested, he testified that his group's simulations in the source-code room were tested by a gentleman named Mr. Louden, using 2008 and 2005 Camry vehicles. The purpose was to perform the same testing and demonstration (originally done in the source-code room) to determine what the fail-safes would do in a vehicle in response to task death. Excerpts of the court transcript Q. So Mr. Louden ran multiple tests on the '08 and '05 Camry? A. That's correct. Q. And all looking at how the software task made out? A. That's correct. Q. Was that reported in some fashion? A. Yes. The testing that he performed, he used data logging equipment to record, you know, things like the accelerator pedal position, both sometimes outside the car, what it looked like, electrically. And also inside the computer there was a tool that we had from Toyota called a tech stream. He was able to monitor certain memory locations inside the computer log. Ran to see, for example, whether the computer thought the brake was pressed, in comparison to whether the brake was actually pressed and things like that. Q. Was the data that he collected from these tests compiled into some documentation that people like you could take and read and use? A. Yes, in Mr. Louden's expert reports. Q. All right. And have you reviewed the data and reports of failure relating to the test that was done on the '08 and '05 Camry? A. I have. Q. Have you considered that information as part of your analysis in this case? A. Yes. Q. In terms of talking about, from this slide, memory corruption and task death, have you pulled the piece of the data from some of testing that helps explain what you are talking about? A. Yes. Q. Is that the next slide? A. Yes, it is. Q. Let's look at that. All right. The title here is Example of Unintended Acceleration. The first thing I wanted you to do is tell us what it is we're looking at. A. Okay. So we're looking at a bunch of different pieces of data all plotted together in one graph. And just to generally orient you, elapsed time that is being measured across the bottom in seconds. So this particular piece of the graph begins at time 80 seconds on his clock and ends a little bit after 150 seconds, maybe 155 there. And then on the vertical axis we see the speed of the vehicle. He was measuring that in kilometers per hour. And so we're seeing that in kilometers per hour. I've made some notes here in miles per hour to make it a little easier to understand. Q. Is a plot of some of data that Mr. Louden collected from some of his testing? A. Yes. Q. Can you walk us through it and explain to us what we're seeing here? A. Sure. I've tried to make clear what the different colors of the data mean. So for example, the speed of vehicle is this blue line. The throttle angle is measured here on this red line. And then there is, whether the brake is on and off is a binary signal, on or off. And so it looks like it goes way up to the top of the graph. It just really means the brake was not on, the brake was tapped and the brake is on solid. Q. Just so I'm clear, where we see these intermittent green lines, is that somebody tapping the brake? A. That's correct. Q. And when we see up here at the top, it's a long piece. That means the brake is applied at hilt? A. That's correct. Q. Okay. What were you simulating in this? A. So you can see there is a vertical line here at time, just before 100, maybe 98 seconds. And that is the marker for the point in time it tests when this task-X was killed and the mechanism of killing it was to flip one bit inside the operating system. So those working inside the Code Room indicated particular bit to flip to Mr. Louden. Q. All right. Let me back up and ask you additional questions. In this testing that was done on the vehicle, was the test required to go in and simulate some occurrence in order to have task-x data? A. I'm sorry. I don't understand your question. Q. Did it have -- did the person that run the test have to make the task die? A. Yes. So using the same tech screen, laptop basically as Toyota test equipment hooked up to the car's computer, he was able to simulate the bit flip. Of course we can't -- you know, as scientists we want to test something, we need to be able to make it happen, we need to make it happen in no time. We can't just wait around for that particular bit to flip, which may take a long time. So he was able, using that same computer, to, you know, enter a command and cause that bit to flip. And then that would have the effect of killing that task in the vehicle. And then the rest of data is the data collection of cars's behavior around then. Q. Does he drive this car on the road? A. No. He's doing it on what's called a dynamometer. In Maryland, anyway, when you get your car's emissions tested you put your car on a dynamometer, where the front wheels -- the drive wheels are turning and the car's not going anywhere. He had a similar arrangement. Q. All right. And so, this vertical line, I'm estimating, is somewhere close to 100 seconds into that test, he's able to, using a computer, to kill task-x? A. That's correct. Q. When you say kill task-x, what does that mean in terms of the car's operation? A. Well, the graph is showing that at that time you have [REDACTED] of the [REDACTED] tasks alive, but you don't have this task-x running. And we're seeing what happens to the vehicle, which is a loss of throttle control subsequent to that. Q. And in a previous slide when you were talking about memory corruption, killing task-x and causing a UA, is that an example of that? A. That's correct. Q. Tell us what happen after the task was killed. A. After the task was -- so the setup here with this particular test was that the car had been run in the time, obviously, before 80 seconds and using the accelerator pedal, Mr. Louden had gotten the vehicle up to this 68 miles an hour and he had set the cruise control. So now he had the car driving at cruise control at 68 miles an hour. And then he canceled the cruise control and a little bit later here at this inflection point, the bottom of blue line, he hit the resume button on the cruise. So it'd try to go back to the speed of the vehicle that was previously set, which was about 68 miles an hour. So if it starts at -- I didn't calculate there in miles per hour, but you can see the inflection point at the bottom in the blue, it starts below 68 miles an hour. And then of course, the car begins to accelerate because the car is operating normally. What happens is that the task death caused in this particular test. Because that task was not there when the vehicle actually reached the set point of 68 miles an hour, it should have closed the throttle more and slowed the vehicle -- or not slowed the vehicle, but kept the vehicle going at 68 miles an hour. Instead, the throttle remained open and the vehicle continued to accelerate. And you can see that this total length time with the throttle open, letting in air, and the car accelerating to past two and past the cruise set point, is approximately 30 seconds. So from time, about 100, until a time, about 130. Now, Mr. Louden, as I understand it, at this point got nervous at 90 miles an hour because the vehicle was on the dynamometer. And so at that time he pressed on the brake solidly and continuously this whole time. There's a couple of effects you should be aware of because it was on the dynamometer. First of all, is that on a dynamometer, there is a lot of momentum in the dynamometer itself. So when he started braking there and a fail-safe, called a brake echo, kicked in, at that time the vehicle did not decelerate as fast as it would have on the road. But what we see here is that there was an unintended accelerate or a loss of throttle control that spanned from time 98 until about time 129 when he pressed on the brake solidly at that time. Q. You mentioned at -- was it at this point that the fail-safe kicked in with the brake applied? A. Yes. The -- at -- it would be within that, between that 129 and 130-second gap. Q. All right. So we see in some of these green lines, he just taps the brake and the fail-safe did not come on? A. Yes. That's correct. Q. All right. And now, this is also from the 2008 Camry? A. Right. So this was the first testing that was performed was on a 2008 Camry. [A portion of the testimony not directly related to the vehicle testing is omitted here.] Q. Is there anything else about this particular slide you wanted to tell us? A. Yeah. I just wanted to -- this is one example from the vehicle testing. And I just want a make a few points about and it foreshadows some of other things we're going to talk about. First of all, is that this testing, although it was done on a dynamometer, is representative of what would happen in the vehicle on the road if you resumed cruise control and task-x was dead at the time. It would exceed the speed of your planned -- you know, set speed. And it would not, in this particular scenario, begin to correct anything until the driver acted. So the driver would have to realize that the car had gone above the 68, maybe much above the 68. And then when he stepped on the brake an action was taken in that particular scenario. This testing confirmed that -- so this was related to cruise control. But we've also confirmed that during this time the accelerator pedal is not responsive. So there is two ways you can tell the car how fast you want to go, one is the cruise control buttons and one is the accelerator pedal. And neither of them works during this dead task-x time. The other thing is that this ended, this particular test ended when the driver stepped on the brake. However, we have confirmed in other vehicle testing that I'll talk about later, that if the incident begins with the peddle, [sic] brake peddle [sic] pressed at all, even lightly then the unintended acceleration will continue, potentially, forever unless the driver tries the risky thing of letting go of the brake while the car is driving away with him. 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. Related posts:
http://www.eetimes.com/document.asp?elq=c193891ea5ad430d844d99c440d2e40c&doc_id=1319966 |