jun917 wrote:
簡X綿 MAZAD MPV 暴衝 台北 90.7.10 90.7.19 車商應負責 已達共識,退車還錢
騙人啦....
簡X綿她家應該不會開Mazda的車...
firmware 寫得有問題
也可以解釋為什麼合泰的人要用踏墊蓋住油門 因為它們早就知道電腦有問題
http://www.edn.com/blog/1690000169/post/630052463.html?nid=3351&rid=8740470
Toyota Prius and Camry, drive-by-wire, and our failure to learn from experience
Feb 4 2010 10:06AM | Permalink |Comments (45) |
I see from the morning news that Toyota's adventure into the world of embedded software is going badly. The company's second attempt to find a quick fix for unintended acceleration in its conventionally-powered vehicles is barely underway, and already evidence is emerging that the underlying problem is likely in the engine controller, not in the pedal mechanical assembly. And now we hear from Japan that the Prius, Toyota's golden child, has a problem with its brake-by-wire control system.
One has to recall Audi, which decades ago accidentally introduced drive-by-wire with its advanced cruise control on the Audi 5000. The cars were allegedly subject to spontaneous acceleration. The company blamed the problem on operator error. At the time, I was told that researchers at another European high-end auto company had uncovered a problem in Audi's engine-control firmware and reproduced the acceleration without requiring a driver to mistake the gas pedal for the brake. But in the ensuing liability litigation, all hope was lost of diagnosing the actual problem and documenting it so that the rest of the real-time software community could avoid it.
The reason all this came to mind this morning was actually not the newspapers, but a panel I attended yesterday at DesignCon. The subject was achieving quality closure. But the issue of software sat like an elephant in the corner of the room, awaiting notice. One of the panelists¡XI believe it was Design Rivers president Camille Kokozaki¡Xpointed out that perhaps the most serious quality problem in IC designs now is not quality closure on the hardware, but the integrity of the firmware and software that will run on the chip. There simply is no systematic approach to ensuring the quality of an integrated hardware/software system.
And this is a tragedy. Thirty years ago, work was well under way on the problem of formally proving software correctness. One company had designed a completely deterministic microprocessor¡Xno interrupts, no indirect addressing¡Xthat made it possible to mathematically prove all of the possible trajectories of a code set. And computer scientists such as Edsger Dijkstra were making strides in methodology to create formally proven software. But along came C, UNIX, and the cult of the bemused hobby programmer, and the entire notion of formal correctness vanished under a smokescreen of hacking.
So now, after decades invested in metrics-driven verification, formal verification, and methodology management, we find that our chips don't work as expected because the software is still being "verified" by feeding it test cases until the schedule expires. And we find that our cars run into things for the same reason, and the press of course will blame the problem on "electronics."
And once again, as in Audi's day, it is safe to conclude that whatever accurate diagnostic work actually gets done on the Toyota problems will be wrapped up in a gag order as part of a class-action settlement, so that no one in the industry can benefit from what Toyota engineers did or did not learn from the problem. That way we can repeat the situation with the next generation of software-governed systems, a new set of executives can avoid blame for the tragedies, and a new set of lawyers can make their fortunes off the resulting litigation.
The only parties in this little comedy that have an interest in actually improving the state of the art are the engineers, who won't be consulted, and the victims, who will be silenced by the lawyers. How much better for everyone if it were a principle of civil law that when it is found that damage has been inflicted by a failure, all of the diagnostic information determined by the vendor and by independent parties must be placed in the public domain, and may not be used to assess or assign damages. Such a notion might somewhat restrict the income opportunities of litigators, but it would unquestionably assist the engineering community in learning from our mistakes
只是................................
產品有問題，公司內部不是應該做一反應嗎?
至少如果不是車子本身問題
也該給社會大眾一個安心的答案嗎
( 小弟是做 Q 的，有職業病 )
小弟是開小佛的，當初有比較過阿提司，可是太貴了，價錢又太硬了
再怎麼騙消費者也騙不到最後
真相總會大白
各位開TOYOTA或其他牌車的大大們
要是真的碰到爆衝
這個影片有教自救方法
http://www.youtube.com/watch?v=FT07_JbnKWQ
真的要好好學起來啊
shanaivan wrote:
這就是為什麼打到空檔還會衝的原因
firmware 寫得有問題
也可以解釋為什麼合泰的人要用踏墊蓋住油門 因為它們早就知道電腦有問題
我還是想問一個問題，如果打空檔這個動作是機械式的，firmware還能干擾嗎?接下來這個問題就是有個暴衝的camry車主宣稱他有打空檔，那Camry是機械式的變速箱還是電子式的?
要驗證這個問題，要請Camry車主回去試一下，當你在停車熄火狀態的時候，是否可以打到空檔?不用在行進當中實驗，只要在你家車庫，把車停好，打到D檔直接熄火，然後打N檔，看你的變速箱是否可以進到N檔的位置，因為如果是電子式的，在完全沒電力的情形下，我相信變速箱應該是不會理你的。
內文搜尋
從 APP 打開
X