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
Page 1 / 3 Next >
More Related Links
View Comments: Oldest First | Newest First | Threaded View
<<   <   Page 2 / 3   >   >>
Antony Anderson
User Rank
Rookie
Re: Next steps
Antony Anderson   11/5/2013 12:42:51 PM
NO RATINGS
@Junko Yoshida

Pre-impact EDR download data is very limited in extent. A typical data download matrix in Bosch EDR format for the time before the crash might look like this:


  • 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
  • Time is recorded with reference to impact, but absolute date and time of impact are not recorded.

This is a very sparse data matrix and only of limited use in determining what was going on before impact.

In an ideal world an automobile black box would record a number of other variables to allow cross checking. The sampling rate would be increased probably by a factor of about a thousand. The time scale would be extended back to perhaps half an hour before the crash and the record would be date and time stamped in some way. There would also be video recording. Amongst the most important variables recorded would be the system voltage and current, throttle PWM duty cycle and throttle angle. One might then get some idea as to whether Task X had been having a hissy fit at the kitchen sink.

The data recorder would have to be entirely independent of the Electronic throttle control and the CAN bus.

Toyota and other automobile manufacturers have been able to claim that a record such as the one above "proves" that the driver did not have their foot on the brake - ergo they must have had their foot on the accelerator pedal when they meant to put it on the brake.  In other words, they use the EDR record to insinuate that the driver has been "startled" into making a pedal error. [ This process of condemnation, it seems to me,  is roughly equivalent to the medaeval process of testing for witches with a ducking stool: if the wretched woman sank in the pond she was proven innocent but drowned anyway, and if she rose to the surface she was proven a witch and was burnt at the stake. Rather unfair, but guaranteed to get rid of witches.]

I have examined a number of EDR records and have written two reports that are in the public domain. In one particular case I have been able to compare EDR and video records and I could find no correlation whatsoever between the two. I would be very pleased to make these two reports available - they are not subject to any gagging order.


I was very interested to hear that:

"He (Michael Barr) also told EE Times that the expert group found thatToyota's black box can malfunction during unintended acceleration specifically, and this will cause the black box to falsely report no braking."

It explains my own findings! It would be interesting to know if anyone else has had a similar experience.

 

antony.anderson@onyxnet.co.uk

 www.antony-anderson@onyxnet.co.uk

 

 

Navelpluis
User Rank
CEO
And how about software?
Navelpluis   11/5/2013 1:24:38 PM
NO RATINGS
Legal people can easely jump on this issue since they understand what harm such an error can issue. But how about software? Fact is that they let us sign their 'terms of use' and then we finally meet how "well" the product will serve us as a user. What a shame. It is full of backdoors, often not working properly, does things we don't want and often has very bad value for money too.

As a hardware guy this development really really aways has worried me. I can't do that. My boards (Electronics) always have to work. 

I do wonder for years why this has gone wrong. The toyota example is due to bad thought firmware design, so basically software. Bad software on lethal moving vehicles, something to worry about.

Maybe in 10 years we have to agree with 'terms of agreement' if we want to buy our cars...? Let me suggest not to go this way: It is better to get all legal to bad software design. This is where they should put their attention to, to give my 5 cents...

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?

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.

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. 

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.

 

 

 

 

 

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.

 

 

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.

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!

 

 

 

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?

<<   <   Page 2 / 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