Timeline: Toyota Faces More Battles in Liability War

MADISON, Wis. — The Oklahoma jury verdict in Toyota's sudden acceleration case, in which the automaker was found liable for the first time since it started recalling millions of vehicles in 2009, could turn the tide for hundreds of cases still waiting for trial in multidistrict litigation (MDL) in the federal court in Santa Ana, Calif.

Bookout v. Toyota is noteworthy because this is the first time a real jury heard the case and delivered a verdict. More importantly, the case is significant, not because of the verdict, but because the plaintiffs' lawyers went to trial alleging a software defect contributed to unintended acceleration.

Calling the Oklahoma case an outlier, as has been suggested by some of Toyota's defenders, is probably premature.

"I think this [verdict] will give momentum" to many other personal injury and wrongful death cases waiting for trial, Carl Tobias, a professor at the University of Richmond School of Law, told us. However, "a number of additional jury trials" will have to take place before we can determine what the Oklahoma case means and before we might see a broader settlement by Toyota.

Numerous outside experts claimed in the past that the sudden acceleration events could be caused by an electronic defect in Toyota vehicles. But for a long time, no evidence was made public to prove that theory conclusively. The Oklahoma verdict has shown a way to break the complex software issue in the electronic throttle system and explain it to a jury, thus establishing it as a central issue for a number of cases in which plaintiffs have said floor mats and sticky pedals can't explain their accidents.

A defect in the Toyota electronic throttle system has become the focus of arguments by plaintiffs' attorneys in the cases in the multidistrict litigation.

Toyota's victory
Toyota won many unintended acceleration cases over the last few years. It successfully blamed the problems on driver error, faulty floor mats, or stuck accelerator pedals. In parallel, however, it settled other cases.

In cases in which the plaintiffs' attorneys submitted a full report on a flaw in the vehicle's electronic throttle control system, a pattern emerged: Toyota opted to settle before the case went to trial.

The first settlements came in December 2012, when Toyota agreed to pay more than $1 billion to resolve hundreds of lawsuits claiming economic losses vehicle owners suffered as a result of the recall. However, that settlement did not resolve hundreds more lawsuits involving wrongful death and injury.

The first Toyota settlement in one of those cases came early in January in Van Alfen v. Toyota Motor Corp., No. 2:11-8120. That case, scheduled for trial in February, would have been the first personal injury case in the multidistrict litigation to go to trial. It would serve as a bellwether for many other lawsuits that have been consolidated before US District Judge James Selna.

Paul Van Alfen was driving a Toyota Camry on Interstate 80 near Wendover, Utah, on Nov. 5, 2010, when it suddenly accelerated. Skid marks showed that Van Alfen tried to stop the vehicle as it exited I-80, according to police. The car went through a stop sign at the bottom of the ramp and through an intersection before hitting a wall. Van Alfen and his son's fiancee, Charlene Jones Lloyd, were killed. Van Alfen's wife and son were injured.

EE Times has confirmed with Michael Barr, CTO of Barr Group, who served as an expert witness in the Oklahoma trial, that he had done a software analysis on the Toyota vehicle in both the economic loss and Van Alfen cases.

The trial of another unintended acceleration case (Estate of Ida Starr St. John v. Toyota Motor Sales USA Inc. et al., No. 8:10-cv-01460), also part of the multidistrict litigation, had been scheduled to begin Tuesday in an Orange County, Calif., courtroom. However, that trial has been postponed until March. The Associated Press reported on Friday that US District Judge James Selna postponed the trial because of "court congestion."

Ida Starr St. John, 83 at the time of her accident, was driving a 2005 Toyota Camry in April 2009 when it suddenly accelerated on to the grounds of a Georgia elementary school. The vehicle crashed into the school's gymnasium. No children were injured, but the accident allegedly fractured several of St. John's vertebrae and left her with other injuries.

"Hold on now. The SENSORS measuring each one of these four parameters are definitely different sensors. If indeed task X is reading all of them and recording them, then that's a different matter. Of course, that would be a bad idea. It doesn't make a lot of sense to have the same app that operates on parameters be the one that stores them in the black box."

All the sensors feed either directly into the ECU or via the CAN bus. As I understand it the EDR reads stored variables from the CAN bus. So you are right: task X reads all the variables and records the values. These are sampled by the EDR and recorded on a continuous loop basis on a 1 second basis.

I agree with you that to combine control monitoring and data recording tasks all within Task X is a bad idea. The sensor outputs should have been fed direct to the EDR then the values would not have gone haywire if Task X died. It is normal industrial practice to keep control, switching/isolation and monitoring functions separate from one another. In this case it seems that Toyota has brought control and monitoring functions together into Task X and more or less ignored the switching/isolation function, or rather it has brought part into Task X and ignored the rest - hence no kill switch or other means of reducing engine power independent of the ECU.

You have the independently measured speed, right? So why pretend that the RPM figure is all you have to go by, to compute kinetic energy? All the RPM figure is meant to indicate, I suppose, is what gear the car is in (presumably, that info is not stored separately).

I was trying to point out that the scale of, for example RPM, is so coarse that it is very difficult to deduce anything. But that does not stop people claiming that the EDR results mean much more than they possibly could. It would be much easier to get an accurate picture of what occurred before the accident with finer graduations of the variables recorded and very much faster sampling. Memory these days is very cheap.

My point is, when you're dealing with an attorney who is not well versed in car things, and never mind the jury, these omissions of information seem designed to obfuscate rather than educate.

The problems are threefold (1) the EDR results, or rather the interpretation put upon them, may well not be justified and (2) the EDR results may be corrupted by the death of task X and (3) you have no way of knowing if the results reflect the actual pre fault situation or not. In the light of what Dr Barr has revealed about the EDR results, I would have thought that both parties would want to exclude EDR evidence from the trial and rely on circumstantial evidence. So we will just have to wait and see with the Vance v Toyota case which will be the next to come up I believe in February.

If I were the lawyer, I would have asked up front, "Did the brakes work throughout this event? Yes or no?" Then I would have asked, "Was power cut when the brakes were applied, when task X died? Under what circumstances was power cut or not cut?" Then I would have asked, "Are these four parameters being stored correctly during task X death?"

There are, as they say, many ways of skinning a cat especially when the cat has experienced eight task deaths already and is now come into the orbit of task X for the ninth.

If it took us three or four articles to get to the "whole truth" on these matters, how likely is it that the jury or the judge got a good idea in real time?

It seems to me that both the judge and the jury made a good job of getting to the heart of the matter in real double-quick-time. Placed in the double-quick time lane we might do better or worse than the jury or the judge, but I would not want to hazard a guess as to which might be the more likely.

"For a given gear, the stored kinetic energy of the vehicle at 2800 RPM will be 1.4 times what it would be at 2400 RPM. Then remember that an EDR value of 2800 RPM might indicate an RPM of up to 3199 RPM. so in this case the ratio of stored kinetic energy between 2,400 and 3199 RPM is 1.8 to 1."

The most direct response I should have made was, since the gear selected at any given time is apparently NOT a stored value in the black box, RPM is irrelevant to computing kinetic energy of the car. That computation must be made with the speed sensor value. *If* the selected gear was a stored value, then indeed an accurate respresentation of RPM could be used to confirm the validity of the speed sensor's data. But that's not the case.

So, RPM, combined with the speed reported, is probably good enough to make a reasonable conclusion on the gear selected. It would show whether the car was accelerating or going at a steady speed/coasting, for instance.

"I think we should distinguish between the deficiencies in the Toyota software that Dr Barr has identified, for which Toyota should be held responsible, and the limited data capturing capability of the EDR for which Toyota are not responsible, since the EDR conforms to a standard agreed to by all the automobile manufacturers and NHTSA."

On this, we agree. I was just pointing out how not being clear can lead the non-fanatic to the wrong conclusions.

"They are not independent sources and that is the problem. Monitoring and data recording of these variables has been muddled up with throttle control as part of Task X."

Hold on now. The SENSORS measuring each one of these four parameters are definitely different sensors. If indeed task X is reading all of them and recording them, then that's a different matter. Of course, that would be a bad idea. It doesn't make a lot of sense to have the same app that perates on parameters be the one that stores them in the black box.

"For a given gear, the stored kinetic energy of the vehicle at 2800 RPM will be 1.4 times what it would be at 2400 RPM. Then remember that an EDR value of 2800 RPM might indicate an RPM of up to 3199 RPM. so in this case the ratio of stored kinetic energy between 2,400 and 3199 RPM is 1.8 to 1. Might this difference not mean a significant difference in the scenario that could be reconstructed?"

But that too is overstated. You have the independently measured speed, right? So why pretend that the RPM figure is all you have to go by, to compute kinetic energy? All the RPM figure is meant to indicate, I suppose, is what gear the car is in (presumably, that info is not stored separately).

My point is, when you're dealing with an attorney who is not well versed in car things, and never mind the jury, these omissions of information seem designed to obfuscate rather than educate.

If I were the lawyer, I would have asked up front, "Did the brakes work throughout this event? Yes or no?" Then I would have asked, "Was power cut when the brakes were applied, when task X died? Under what circumstances was power cut or not cut?" Then I would have asked, "Are these four parameters being stored correctly during tsak X death?"

If it took us three or four articles to get to the "whole truth" on these matters, how likely is it that the jury or the judge got a good idea in real time?

"Reading the court transcript in the Oklahoma case, I was really struck how well Michael Barr, the expert witness, broke the complex issue and found a way to explain in such simple language."

Michael Barr made an excellent job of it by finding an appropriate everyday model for Task X. He must have thought long and hard about this - choose the wrong analogy and your testimony will go down like a ton of bricks with the Jury!

Giving expert evidence is absolutely different from giving a talk or a lecture to an audience. You have the task of communicating the essence of what you want to say in few words in the face of every attempt by the other party's attorney to throw you off track and diminish you in the eyes of the jury. Each expert eventually finds their own way of standing up to cross examination and learning to deal with difficulte questions in a calm and steady manner.

The main thing is to develop a rapport with the jury and one important aspect of this is to speak to the jury, rather than the attorney who is questioning you. You have to see them as individual people to whom it is worthwhile explaining what you are trying to get across: after all your role is to explain to the court the technical issues in terms that they will understand and they will appreciate your efforts.

I have found having good explanatory models very helpful with a jury because they have had days and weeks of listening to turgid cross examination and now have something before them that they can relate to, or better still, turn over in their hands and look at. This livens up the proceedings up no end.

In Michael Barr's case, by picking the kitchen sink model, he didn't even need a physical model because everyone in the jury, except those who had never been near a sink, would know exactly what kind of a scene he was trying to conjure up for them. And no attorney in his senses is going to try to sink the kitchen sink model because he is likely to be carried down the imaginary plughole with it.

Toyota (and NHTSA) would no doubt want to project the image of a dishwasher, with all the tasks laid out neatly as if dishes neatly racked, but the kitchen sink image dished the chances of that!

Hi, Sanjib. For those who live outside the US or for those who haven't closely followed the case (or simply forgot!), EE Times decided to put together this timeline, focused on the portion that's relevant to what's going on right now.

Building a case based on software defects is not an easy thing to do, even if lawyers are tech-savvy. For that matter, to find an expert witness who has done the real homework and is able to speak with such clarity on the software matter is also rare, I think.

Reading the court transcript in the Oklahoma case, I was really struck how well Michael Barr, the expert witness, broke the complex issue and found a way to explain in such simple language.

"Yes, but this isn't so bad, is it? Even if task X death means you don't get the brake switch information, there are three other independent sources that can confirm whether the brakes were applied or not - RPM, speed, accelerator pedal position. Applying the brakes would create very rapid changes in all of these. Are measurements of these other parameters also affected by task X?"

They are not independent sources and that is the problem. Monitoring and data recording of these variables has been muddled up with throttle control as part of Task X. (Everything goes into the kitchen sink). What Toyota should have done, in my opinion, was to feed Brake ON/OFF, RPM, vehicle speed and accelerator position directly to the EDR then the values would have been independent and it would have been possible to do the kind of cross checking that you suggest.

It appears that in the event of a sudden acceleration the EDR results may be scrambled - which means that they cannot be relied upon. This finding of Dr Barr, seems to me to be of considerable importance and it would appear, by their decision, that the jury may have thought so too.

"And RPM measurements within 400 might not be very high res, but it's not bad either. For example, whether the reading is 400 or 800, you're basically idling. If the reading is 800 to 1200, you're barely off idle. The higher the RPM, the less important that difference is."

EDR results are being given a great deal of weight in litigation. Particularly the brake ON/OFF values. So it is pretty important that they accurately reflect whether or not the brake was applied. It now appears, as a result of the work of Dr Barr' and his team that the EDR results cannot always be relied upon. This would have enormous implications in a hypothetical criminal case where the driver was being prosecuted for vehicular manslaughter. It could make the difference between being acquitted or given, say, a 15 year prison sentence.

"Does anyone really care whether the engine was revving at 2400 or 2800 RPM, in reconstructing a scenario? Probably not."

For a given gear, the stored kinetic energy of the vehicle at 2800 RPM will be 1.4 times what it would be at 2400 RPM. Then remember that an EDR value of 2800 RPM might indicate an RPM of up to 3199 RPM. so in this case the ratio of stored kinetic energy between 2,400 and 3199 RPM is 1.8 to 1. Might this difference not mean a significant difference in the scenario that could be reconstructed?

Take the hypothetical example of a driver in a suddenly accelerating vehicle on trial for manslaughter. Suppose the reconstruction expert was making the case that the driver had been doing all they could to brake, the prosecution might cast doubt on the evidence, on the basis of claiming that the RPM might have been up as high as 3199 RPM.

It just doesn't seem like any flagrant oversight to me.

I think we should distinguish between the deficiencies in the Toyota software that Dr Barr has identified, for which Toyota should be held responsible, and the limited data capturing capability of the EDR for which Toyota are not responsible, since the EDR conforms to a standard agreed to by all the automobile manufacturers and NHTSA. We may however criticize the EDR standard and suggest how the EDR might be usefully improved.

I was not aware that so many accident cases occurred related to Toyota cars and so many families got affected by these incidents. I feel sorry for them. More numbers of similar incidents indicate a possibility of an inherent issue in Toyota's cars...which could be due to the same "bit flip" issue in the firmware confirmed recently. How Toyota won in most of the previous cases? - "When asked why plaintiffs' lawyers in those cases never used the software defects as their argument" - why? Were those lawyers not knowledgeable on the technology enough not to miss the "firmware/software" as an important component of the modern automotive systems? As the EE technology is expanding everywhere in our lives, be it a smart phone or a car, it is a challenge for the lawyers to catch-up with pace at which the new technology trend is evolving.

The sampling is generally at 1 second intervals before the crash - in this case there are six samples.

Four variables are recorded against time: Speed, Brake Switch ON or OFF, Accelerator rate (a voltage related to the accelerator position) and Engine RPM

Engine RPM are recorded to the nearest 400 RPM, which means that engine RPM of 799 would be recorded as 400, whereas 800 RPM up to 1199 RPM would be recorded as 800 RPM

Whether the brake switch is ON or OFF is recorded, but not the brake pressure

Yes, but this isn't so bad, is it? Even if task X death means you don't get the brake switch information, there are three other independent sources that can confirm whether the brakes were applied or not - RPM, speed, accelerator pedal position. Applying the brakes would create very rapid changes in all of these. Are measurements of these other parameters also affected by task X?

And RPM measurements within 400 might not be very high res, but it's not bad either. For example, whether the reading is 400 or 800, you're basically idling. If the reading is 800 to 1200, you're barely off idle. The higher the RPM, the less important that difference is. Does anyone really care whether the engine was revving at 2400 or 2800 RPM, in reconstructing a scenario? Probably not. It just doesn't seem like any flagrant oversight to me.

Measuring brake fluid pressure would be a good addition, but the negative aspect of that is that you're introducing another device in the brake lines. These brake line pressure sensors aren't fault free. Cars had such pressure switches to operate the brake lights, until ca. 1964. Then they went to electrical switches on the pedal linkage. I'd just as soon not reintroduce those pressure sensors. Pressure sensors can ooze out fluid, introduce air in the lines, etc.

I immediately discount what executives say, since for the most part, they are utterly clueless about the inner workings of their products. Their job is PR.

But for instance, something along those same lines happened to me recently, although not safety critical. I had specified the way a particular function was supposed to be implemented. Later, when the code was being operationally checked out, I discovered that it didn't behave as I had specified (i.e. it was less robust in case of hardware faults). One of those "oh s___" moments, in other words.

So we wrote this up, the implications, the potential fixes, and sent this to the customer. Had it been safety critical, I'm sure we would have insisted on fixing it.

No one will probably ever create perfect code right off the bat, but it just seems odd that no one intimately involved with this software had that awful panicky feeling that too many things were being killed when just one app died?