X is the 24th alphabet. There are 24 cases. What a coincidence!
When NASA found a bug in toyota electronic throttle system (ETS), did the team take consideration of the complete system? For example, if the driver is slamming the brake, will the ETS be triggered to stop?
This case is definitely interesting given Toyota has been slamming multiple times in the last few years.
I could also see this as a preventative damage control technique. When I was doing Computer repair and customer service ages ago, we would ALWAYS get a long line of customers that were sure they were infected with whatever virus was on the news latest.
If you give it a name, people will come to you claiming they've got it.
Junko - I drive a prius. I bought this car not too long after all the news about sudden unintended acceleration 4 years ago. There was a lot of talk about manual error. I can tell you that, after driving the car for 3+ years, there has been about 15 or so instances when the car accelerates wihout my assistance - not too much but nonetheless an acceleration. I have learned to manage that. I still like my prius.
Legal documents are usually dull as ditchwater, but not this one. According to Judge Selna in his Order of 7th October 2013 Granting in part and denying in part motions to exclude expert testimony and Toyota's Motion for Summary Judgment in the case of Ida Starr St John v. Toyota on page 71:
"Task X calculates target throttle angles, monitors for system failures and enters fail safe modes. The death of Task X freezes the target throttle angle. When task X dies, the fail safe mode is not triggered unless the driver removes her foot from the brake pedal for a minimum of 208 ms."
It sounds to me as if Task X is the torque controller and is accepting all the torque input requests, including that from the driver via the accelerator pedal, and presumably a brake on off signal and is then computing what it considers to be the desired throttle angle, comparing that with measured throttle angle and then using the error signal to drive the throttle to the minimise the error.
The point I was trying to make was that this particular legal document, a ruling by Judge Selna, had some interesting technical clues in it as to the nature of Task X. Anyone interested can contact me for further details.
Junko, if you read Anthony Andersen's quotes in the parallel thread, it seems easy to understand why throttle commands would be less than steady. Between using unregulated DC voltage as the (analog) position signal, and the hysteresis in the electric motor, hmmm.
This court case has me wondering just how many other automakers are re-visiting their throttle designs. I can say that in my GM car, all seems very functional in this regard. It's probably similar to what might make reporters pucker up, when they write a story and perhaps haven't exercised obsessively complete due diligence in doubly-checking their sources, getting other opinions, that sort of thing.
I don't mean to sound dismissive, but this does not sound like the issue from the court case. The priuses can feel strange. They have two drive systems and lots of active switching between them.
I even had a car that felt like it would speed up when you let off the gas (it was just the clutch engaging as your foot would rest on the brake, it gave a peculiar sensation that could be construed as accelleration)
@Junko: my guess is that the Oklahoma case will probably lead to a class action where the most that consumers owning the affected Toyota vehicles will get is a recall and replacement of parts. The league of lawyers will of course get much of the monetary settlement!
That's a good question. I don't know. In this particular case, the expert witness was only allowed to see the source code under confidentiality agreement -- so that the exeprt's findings are made public in the court transcripts but not the source code itself.
Automation will be having its own artifacts, some comments says here that the increase in acceleration is a manageable event, what I have noticed in most of the recent auto throttle control is some-kind of increase in the rpm and ultimately this will lead to increase in the acceleration in the car in transmission-ed. But the case has reached up to legal investigations beyond the engineers hand.
I recently took out a new Toyota Sienna van for a test drive at my local Toyota dealer.
I was taken aback by my inability to maintain a steady speed. It seemed the throttle control was noisy, in that the vehicle would either surge ahead or hold back. When I turned on the cruise control the vehicle maintained a smooth steady speed. The salesperson with me simply denied there was a problem.
It appears that Toyota still has an accelerator sensor problem - perhaps whiskers caused by lead free solder or noisy pots.
It's unbelievable that after all this time and publicity, Toyota seems unable to solve the problem.
I'm not any kind of an automotive expert, so I can't speculate on what X might be. I am glad that many of the details are public information. In so many product liability cases, the details remain confidential due to out of court settlements.
I've read material from Michael Barr for many years now. Based on that, I would consider him to be a very credible expert.
There is an underlying failasy to the whole Barr analysis. Basically, since there is no legal claim to enforce that software actually works when purchased, why would this be different. For example, forget actual physical products, when you purchase any piece of software, there is no claims made about its ability to perform the advertised function (correctly or at all). Otherwise, nobody would have to contend with patches (for functionality, or even perhaps for security) since the sellar of the code would be held responsible for the fact the code did not behave correctly.
And even if one is to muddy up the waters with actual products...we all know numerous patches goes out on them routinely for functionalty let alone the daily security patch.
If somebody tries to use the old porn argument (its bad but only know it when I see it kind of thing) then the laws of statistics comes into play. If 100 vehicles out of 10M sold have the problem, then that is "degrees of badness". Unfortunate as it is, no claim on functionality of software was made.
Bottom line, if indeed the code is bad/buggy and the car is otherwise mechanically sound, shouldnt this be litigated in the context of software? not under the context of a physical product.
When we buy software for our computer, the publishers often (or always) have a "we don't promise it will actually work" disclaimer. Howver, I beleive that with physical products, espcially something with safety issues like an automobile, I don't think that same discaimer is or can be made. Safety criticle embedded systems are quite different than are desktop applications.
Lawsuits like this are supposed to make sure that the manufacturer does its best to deliver a safe product and keep improving on the safety. Hopefully, that's just what will happen as a result of this.
so somebody who buys an EN switch for say a Hospital, you believe, is exempt?
Hmm....its a physical product, it involves safety, its not purposed strictly for safety environments (aka IV processor), etc....As far as I know, nobody makes a medical/safety certified servers or network products ( I do know many hospitals used standard products from the big players....maybe they put up some sort of bond or whatever....but that seems hollow....how do you measure the value of safety).
I guess somebody could claim a car is intended for its purpose and that purpose has a safety aspect so it comes under Ts and Cs for say medical equipment. What about busses (safety risk is higher...50 people could die....or airplanes).
Anybody know what Airbus did when they found the bug in the autopilot firmware that cased a crash in late 90s? Sounds similar to me (FW bug cause loss of life in a transportation product).
Hardware (mechanical, electrical, and electronic) and software for aerospace/aviation/medical devices are a whole different ballgame than that for general industry and business much less personal use. The FAA and FDA have reams of criteria that must be met regarding possible failure modes and required results. As pointed out in the Airbus example and more recently Boeing's battery problems major items can still slip through but all in all, as should be that is very very rare..
What does bother me is that it sounds like there are NO gov standards for all the drive by wire systems showing up. Throttle/transmission/ignition 'key' being computer driven is bad enough but now several high-end vechicles also sport full drive-by-wire steering as well. Scary....
As a side note, those reqs are why personal electronics were so restricted on flights until recently - it was (and still is) impossible to test the possible interactions between avionics and all the different makes & models of toys people bring on board. So, just easier to ban them until sufficient body of anicdodal evidence could be gathered saying '99.999999999% sure should be no problem'.
f@Plurph - You would be surprized at how many items come up during flight testing on an Aircraft -- or even on one system on an aircraft -- System level simulation still has a long way to go -- then there are items like SEU in CPU's MCU's and FPGA's that often are left for the FAA to analyze after certification!
I know that every life is worth but all the electronic/mechanical devices have risk and are sometime fatal. I donot think companies like to be in a negative PR situation due to faulty product. My point is disclaimer or not, people should not fully trust machines and should always keep their eyes, ears and mind open while using one.
My ABS in my GM has a bug in it -- it does not function correctly going around a sharp corner -- and the ABS failed in my Honda going down hill in an ice storm -- Fortunately I was able to minimize the impact with the cars stopped at a red light at the bottom by downshifting. Go to a performance driving school and learn the limits of your car before you hit the road with it if possible -- Even these mass produced items are only engineered to do well on a specific set of Federal/SAE tests and testing on a lower quantity vehicle may not be complete -- And yes in splite of the failures, once you learn the limitations, the electronics generally helps and makes things a bit better. Also had the misfortune of sliding down an anti-freeze soaked hill in the rain into the back of a truck with an older honda
You're right. Bugs in a car bought for a lot of money are frustrating and annoying! Why can't they make massive production goods without failing? Car parts are easy to buy, but human parts are something totally different! travel insurance
Yesterday there were articles on a large recall of 2007-2008 Honda Odysseys due to a defect in the active stability control, which would cause the system to slam on the brakes as the car was driving along, without activating the brake lights! The underlying problem is supposedly in a yaw sensor, but obviously the software cannot deal with a faulty sensor. This is the second such recall. Honda claims there have been no injuries, so we don't have the expert analysis to determine what is wrong with their software that it cannot handle sensor problems.
As I talk to more people, it's clear that it's not just Toyota who is having problems with software. One industry expert told me last week in Japan, "Every carmarker is sharing the similar pain and is of as quilty."
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.