Wow! That is some crazy driving.

 

That's scary!!
Were any tests done on the driver (drunk, medicated, mental health, etc)?
Assuming the vehicle was at fault, I don't understand how a faulty brake switch could not register "OFF" in the EDR (or some other related electrical connection). Did Toyota test the functionality of the gear selector (is this a physical connection or electrical)?
After hitting the house the first time, I think anyone would try to back up or at least park, but if I ended up in the street again, I don't think I would try to go forward again...
After the second hit, I found it very suprising the vehicle was still trying to go forward...
Was the floor mat jammed on the accelerator and blocking the brake simultaneously??

 

Staged. Poor attempt to extort money and fame from a corporation.

 

some of the comments are interesting. Several people who claim to be engineers think that the data doesn't match the timing in the video, i.e. the car doesn't appear to be travelling anywhere near the 14 mph or whatever Toyota says the data shows...

I'm not an engineering type person and don't understand much of this.

I am an electrical engineering consultant living in the UK who specializes in electrical machine and electronic failure investigations. From time to time I get involved in problems relating to electrical intermittency in safety critical electrical and electronic systems. I have recently published an article in the Institute of Electrical Engineers (IEEE) open access journal IEEE ACCESS on the subject of electrical intermittency as a causative factor in sudden acceleration incidents. In that article I reported on a detailed timeline analysis that I carried out on this particular video. Anyone interested can download the PDF from:

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6777269

Alternatively, if you e-mail me at : I will send you a copy of my original working memorandum which shows my calculations in full detail.

I would appreciate it if Jeffrey Ross could be kind enough to pass on the IEEE ACCESS article reference to his contacts in Toyota for their comment.

The video captures the period of 8 seconds before the start of the incident as well as two alternating Sudden Accelerations in forward and reverse directions during the subsequent 22.9 seconds before the vehicle finally comes to a halt. When I compared the vehicle’s speed calculated from the video with the claimed spot speeds downloaded from the Electronic Data Recorder (EDR), I found significant mismatches that could not be explained by measurement error or wheel slip:

• The EDR record claims to show that at 4.6 seconds before the initial impact in the first SA incident the vehicle was moving forwards at 12.4 mph. The video recording shows that at this time the vehicle was moving very slowly and in an apparently controlled manner and was just beginning to turn into the parking area. The video shows that the first SA incident began less than 2 seconds before the first impact and not at least 4.6 seconds before impact as the EDR record claims.
• The EDR record claims an impact speed of 14.9 mph for the first forward SA incident. I have estimated from the video that the impact speed was between 7.4 and 9.3 mph (i.e. between 50% and 62% of what the EDR record claims).
• In the second SA incident the EDR claims an impact speed of 22.4. I have estimated from the video that the impact speed was approximately 12.7 mph. (i.e. approximately 57% of what the EDR record claims).

My analysis shows that in this instance there appears to be no correlation between EDR results and the video record whatsoever.

 

Never bothered to read too much into this when this happened last hear. I just passed off as some dumb ass who can't drive or trying to get some attention in mist of unintended acceleration scandal.

Are you suggesting Toyota some how faked the EDR?

So if this was some kind of mechanical failure, is it even remotely possible mechanically to have the car suddenly accelerate forward hit the house, magically self changes gear to reverse and backs up, magically changes gear to drive hits the house again, and magically change to reverse and backs up?

Oh wait! Maybe this was a Toyota autonomous test car and this was a leak video! :rofl:

 

What the heck. Reading through the comments it was determined she was a teenager...with passengers no less....Why didn't the air bags deploy?

 

If you can try and justify the actions, I think the they were totally panic reactions by the driver. If it is still accelerating forward, driver put in ..hmmm, reverse instead of park....then didn't want to run into someone on the street, and put back into drive and then reverse again...while I too did not see any indication of brakes being applied

 

some of the comments said there were no taillights seen. I saw them at different times. Look for the white lights to turn on in the rear, not the red part. It was the white part that was visible in the video.

 

Watch closely and they look like reverse lights

 

ONE incident like this means NOTHING...ABSOLUTELY NOTHING. Way too many factors to consider.....from driver error (which is most likely) to car mats...and everything in between.

The unintended acceleration problems of earlier Toyota's and Lexus's had..a good portion of them were blamed for the floor mats. The hooks on those vehicles to secure the mats on are a bit of a pain to use. So a lot of people just don't use them...and this causes the drivers mat to creep up and can effect the gas pedal. The 14 hl floor-mats have hooks to keep it in place that are very user friendly. If the early Lexus and toyota's had this system I'll bet there'd be very very few unintended acceleration problems...if any.

 

Toyota did have faulty gas pedals and poor software as well.

There was a reason toyota was fined over a billion dollars.....

 

I didn't say there wasn't a problem with the gas pedals...but there weren't that many. The reason Toyota was fined was because they knew about possible problems and didn't disclose the problem.

The recall my wifes Lexus and my 4runner had was to just cut the gas pedal so the floor mats won't be able to interfere with the pedal if they do creep up.

 

Cut the gas pedal instead of anchoring the mat..hmm, i guess that may have worked as a workaround. But all German cars I have encountered have the mats secured in place. Even on the passenger side.

I just got my new aftermarket mats and they are better than the OEM and feel like real carpet now. They too have lock tabs to keep in place.

The video is weird as there are 2 HL's and they look like they are related as the other pulls up along the house.

The other thing is that it doesn't look like any brakes were applied.

Another not so weird but considerable part is as the car pulls in, it is going super slow. Can anyone pop it in a editing program to check if the timing is all consistent and there is no image tear from recording speed, or variations of pixels in segments? has the video been inspected? By who, and where is the findings?

I'm not suggesting that its been altered, just want to rule it out, since I hear folks saying it is staged. Although the capture looks clean, why not rule it out?

 

Cut the gas pedal instead of anchoring the mat..hmm

The mats were anchored. But people bypassed the anchoring because it was too cumbersome for them. So the mats would creep up. All the anchoring in the world won't work if they don't use it.

 

To me, the driver is at fault.
When the HL crashed the first time it looks like the engine stopped accelerating.

Don't these vehicles have neutral selection?

Looks like brakes were't applied either.

 

To me, the driver is at fault.
When the HL crashed the first time it looks like the engine stopped accelerating.

Don't these vehicles have neutral selection?

Looks like brakes weren't applied either.

For what ever reason it went forward like that, if the driver wasn't intentionally doing it, you are hard pressed to think to put it in Neutral...But NOT to brake?!!! Thats a weird one.
Also, if accelerating, I think I would attempt to put it in Park, but Im sure it would not allow the engine to stop like that. it may have locked it out?
Neutral can slip the mind for some drivers.....At least on the first incident.

BTW...
Could an external device be used to jam up or scramble the ECU, or what ever is controlling the car accelerator?

 

Idiot driver...can't blame the car for anything. end thread.

 

I have to admit I thought about this video pulling into my driveway today.

 

How do you explain remote vehicle immobilisers?

They only work with another device that's installed in your car. If you don't have one of these devices, then there's no way to effect the ECU.

 

MISRA-C coding rules

NOT following coding standards doesn't necessarily the code is faulty or buggy. It just means it might be. Coding standards help eliminate potential problems and helps to keep the code consistent.

 

It means the code is highly likely to be buggy.


Because of the complexity of the code it was essentially untestable. What that means is there is no way to prove that the code does what it is supposed to do 100% of the time.

The Camry ETCS code was found to have 11,000 global variables. Barr described the code as “spaghetti.” Using the Cyclomatic Complexity metric, 67 functions were rated untestable (meaning they scored more than 50). The throttle angle function scored more than 100 (unmaintainable).

You can build a bridge and completely ignore engineering practices and the bridge may not fall down, but I would rather follow the standards and be sure it will not fall down.

 

This is really old, over one year. It was all over multiple news outlets in April / May 2013. The driver involved originally claimed SUA, but when the video surfaced and she was pressed for more information by major news companies, she refused to give comments and lawyer-ed up. The conclusion was that this was a staged attempt to extort money. She had issues.

 

Sometimes these standards have great weight and meaning. Sometimes they are just a way to control extort influence and limit. Code can vary greatly, and there is always more than one way to do things. both could be right, until you can prove one to be wrong.

 

You are correct.

These standards are there to limit. Because programming languages like c and c++ allow programmers to do stupid things standards have to exist to keep programmers from shooting themselves in the foot.


The toyota ecu controller uses recursion for crying out loud. Any programmer who has taken more than 1 semester should have been taught to avoid recursion.

Hopefully toyota fixes their controller software and adds it to the list of recalls they have to perform.

 

Because of the complexity of the code it was essentially untestable.

Oh sure it's testable. Software testing is testing the requirements of the software.

Example: I write a piece of code that takes two numbers as input and adds them together. Testing this - just means inputting two numbers (many different times) and see what the results would be. How the code is written to accomplish this is meaningless to the test.

Testing software means testing the functionality of the software..NOT how the software was written.

What you will find is that code that follows a good coding standard has less bugs and makes the testing job a lot easier (they aren't finding a lot of bugs).

And that is just touching the surface of why to use good coding standards.

You work on DOD systems or the FCC...and you're code (and coding procedures) are audited before it ever goes into production.

 

This is why we there is so much crappy code out there. This kind of coding and testing works fine if you are working on a web browser or a video game.

Testing finished software is only 1 piece of the puzzle. The problem is testing finished software is only as good as the tests used.


When you have critical code, stuff that peoples lives depend on, things should be held to a higher standard.

If you write code to a standard you can mathematically prove whether the code will work or not before you ever compile the software.


Software used in aircraft has been held to this standard for years since peoples lives are on the line. It is about time that auto manufacturers are held to the same standard.

 

This is why we there is so much crappy code out there. This kind of coding and testing works fine if you are working on a web browser or a video game.

NO....it works quite well in almost every industry. I've been doing this..probably before you were born. Currently Director of software development for a small Telecom company. We design software and hardware solutions for telecom companies (AT&T and Verizon) are just a couple of our clients. My first few years out of college was working in the Defense industry mainly on Radar and Sonar systems for Air-Force and Navy.

The biggest part of testing the CODE is unit testing. But that's NOT done by testers. Each section of code is tested with unit tests. NUnit is real good. Although most IDE's have unit testing built in now. The unit tests are written by the engineers to test specific parts of their code. In fact every time a piece of code is checked into source control the complete set of unit tests are run to ensure the new code didn't cause problems in other parts of the code.

If you write code to a standard you can mathematically prove whether the code will work or not before you ever compile the software.

That approach is good for design digital circuits. But it's not practical or applicable in application development....or in Toyota's embedded software. It's pretty much IMPOSSIBLE to prove the logic of a program. It is good for checking some certain types of run-time errors..but NOT all...and not even most. Just SOME. There are some companies like Math Works that is working on some software testing models...but they are not even close yet. Maybe in a decade or so....long after I retire.

Strictly adhered to standards make for better software....PERIOD. That is the whole idea behind the original Design Pattern and Test driven software development from the mid-80's. When I worked at Digital Equipment we were one of the first companies to adopt this concept. And I've been practicing this approach for years.

 

NO....it works quite well in almost every industry. I've been doing this..probably before you were born. Currently Director of software development for a small Telecom company. We design software and hardware solutions for telecom companies (AT&T and Verizon) are just a couple of our clients. My first few years out of college was working in the Defense industry mainly on Radar and Sonar systems for Air-Force and Navy.

The biggest part of testing the CODE is unit testing. But that's NOT done by testers. Each section of code is tested with unit tests. NUnit is real good. Although most IDE's have unit testing built in now. The unit tests are written by the engineers to test specific parts of their code. In fact every time a piece of code is checked into source control the complete set of unit tests are run to ensure the new code didn't cause problems in other parts of the code.



That approach is good for design digital circuits. But it's not practical or applicable in application development....or in Toyota's embedded software. It's pretty much IMPOSSIBLE to prove the logic of a program. It is good for checking some certain types of run-time errors..but NOT all...and not even most. Just SOME. There are some companies like Math Works that is working on some software testing models...but they are not even close yet. Maybe in a decade or so....long after I retire.

Strictly adhered to standards make for better software....PERIOD. That is the whole idea behind the original Design Pattern and Test driven software development from the mid-80's. When I worked at Digital Equipment we were one of the first companies to adopt this concept. And I've been practicing this approach for years.

I'm not sure why we are arguing, I agree that standards make for better code which means better software.

The main reason it is impossible to prove the logic in toyotas code is because it was such poorly written code. Read up on the analysis of the source code done by NASA or Michael Barr.

http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--Bad-design-and-its-consequences

 

Since I have some coders on this thread, and since the topic has taken a turn....

Does anyone know how to convert or "emulate" a Flash site to a non-Flash/HTML version? I know this has a few different approaches, and I have seen it done. Feel free to PM me in case this thread goes back on track

Thanks

 

Does anyone know how to convert or "emulate" a Flash site to a non-Flash/HTML version?

Simple. Dump the Flash version completely and then you don't have to worry about hacking things up to work in non-Flash enabled devices.

On topic, I find it hilarious that some of you apparently know better than Toyota how to write code for their systems. Toyota has been doing it for decades, if you know so much better how to code for vehicle systems you better get a job at Toyota Motors ASAP.

 

The main reason it is impossible to prove the logic in toyotas code is because it was such poorly written code. Read up on the analysis of the source code done by NASA or Michael Barr.

And that is NOTHING different then what I said. They can find SOME types of errors that MAY cause a crash. And MOST modern compilers find the same type of errors. But all the tools in the world won't solve simple logic problems..

 

That is not true. You said that you can use unit testing or other software tests to validate the function.

I don't think that is enough.

If toyota had followed misra guidelines they could use formal verification to prove the correctness of the function mathematically. Or better yet, they could have defined the algorithm, verified it and then implemented it in code following misra guidelines.

However, because of the complexity of the code it is impossible to perform any formal verification. Worse, it is very difficult for humans to look at the code and figure out what it is doing. So difficult in fact it was determined that the code couldn't be adequately tested.


Again, using software tools to test code after it has been written is great, and very useful. However, it is not sufficient for critical software where lives are on the line.


The big issue is that for years programmers have resisted applying engineering practices/principles to software development because lives were not on the line. Now that lives to depend on code I think that programmers need to be held to a higher standard just like engineers(at least some programmers).

If programmers were liable for accidents/deaths caused by their code(like engineers) I think you would find that coding standards would go up quite a bit.......

 

That is not true. You said that you can use unit testing or other software tests to validate the function.

I don't think that is enough.

You've taken a huge turn..and now arguing against something I NEVER said. Go back and re-read the posts.

I NEVER EVER said that unit tests and software tests was good enough to for good programming...please show me where I said that.

I specifically said you MUST follow good coding standards (which I said many many times). One of the things pointed out wrong with the Toyota software was the 11,000 global variables. That's just sloppy programming. C and C++ have very poor memory management which most modern languages have built in...so you better have good standards around that or expect memory leaks. There are many many other things I never mentioned...I was just addressing your statement that a mathematical model can ensure the program will work....and then is just plain WRONG. It does help..but it is NOT the do-all-end-all. We didn't even get into the discussion of Design Patterns or code reuse.

 

I posted that the toyota code was garbage and couldn't be tested. You posted that it was not untestable.

I mistakenly assumed you thought toyota had good code. Personally I thought their use of recursion in the throttle position code troubling. Recursion is something that should be avoided at all costs.....


Using mathematical methods to verify an algorithm can prevent logic errors within the algorithm. There is a reason that NASA uses formal verification for code.......

 

Group hug!!! ...now that I have you two on the same page....about that Flash conversion..... jk

 

Using mathematical methods to verify an algorithm can prevent logic errors within the algorithm. There is a reason that NASA uses formal verification for code

For CERTAIN types of programs. NOT all. I suspect that a lot of code used in NASA does a lot of calculations...so guess what...a mathematical model would be PERFECT for that.

Have you ever done any programming before? If so what languages? And I'm not talking about a class you might have taken in high-school or college.

 

Certain programs like the ones that determine throttle pedal position???? Or ones that calculate A/F ratio based on sensor input?????? Sounds a lot like the type of programming that would work great for an ECU :lol:

I don't know why you keep arguing. I am not saying that Toyota needs to follow rigorous standards for their infotainment system, only for critical systems where failure could result in death.


Toyota and all auto manufacturers should use all available tools to make their code robust and reliable.

 

Good safety point, yet he did ask a question....

Well...So Flash to HTML...How can I go about this without a complete rebuild?

 

You can look at this to convert to html5. https://www.google.com/doubleclick/studio/swiffy/



As far as my experience, my professional coding experience revolves around web applications (php, asp, java, cold fusion). Not really what I would consider programming.

However, I do have degrees in Math and Computer Science so I do understand the foundation of good programming.