Design Con 2015
Breaking News
News & Analysis

Timeline: Toyota Faces More Battles in Liability War

11/4/2013 08:50 PM EST
22 comments
NO RATINGS
2 saves
< Previous Page 2 / 3 Next >
More Related Links
View Comments: Newest First | Oldest First | Threaded View
Page 1 / 3   >   >>
Antony Anderson
User Rank
Rookie
Re: Next steps
Antony Anderson   11/6/2013 7:30:56 PM
NO RATINGS

"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.


Bert22306
User Rank
CEO
Re: Next steps
Bert22306   11/6/2013 5:05:08 PM
NO RATINGS
I should probably have responded in more detail on this matter:

"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.

Bert22306
User Rank
CEO
Re: Next steps
Bert22306   11/6/2013 3:42:29 PM
NO RATINGS
"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?

Antony Anderson
User Rank
Rookie
Re: Important for Lawers to have Tech Knowledge!!
Antony Anderson   11/6/2013 2:51:01 PM
NO RATINGS
Hi Junko

I entirely agree with your comment in reply to Sanjib

"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!

 

 

 

Sanjib.A
User Rank
CEO
Re: Important for Lawers to have Tech Knowledge!!
Sanjib.A   11/6/2013 11:17:45 AM
NO RATINGS
Hi Junko, I completely agree with you.

junko.yoshida
User Rank
Blogger
Re: Important for Lawers to have Tech Knowledge!!
junko.yoshida   11/6/2013 9:08:24 AM
NO RATINGS
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.

 

 

Antony Anderson
User Rank
Rookie
Re: Next steps
Antony Anderson   11/6/2013 8:58:45 AM
NO RATINGS

"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.

 

 

 

 

 

Sanjib.A
User Rank
CEO
Important for Lawers to have Tech Knowledge!!
Sanjib.A   11/5/2013 11:04:57 PM
NO RATINGS
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. 

Bert22306
User Rank
CEO
Re: Next steps
Bert22306   11/5/2013 4:14:23 PM
NO RATINGS
  • 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.

Bert22306
User Rank
CEO
Re: People died -- It is tragic
Bert22306   11/5/2013 3:46:59 PM
NO RATINGS
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?

Page 1 / 3   >   >>
Flash Poll
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed
Top Comments of the Week