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
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.
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).
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.
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.
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)
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, 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.
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.