孟姜女 发表于 2013-10-28 12:05

TOYOTA估计没清完配套厂的油门线库存，就不管throttle control鸟。

开始用汇编是开发初期硬件的资源问题。

FS这种底线，我的理解，工业级产品必须由独立的硬件来判断和执行。

BYY 发表于 2013-10-28 12:02

你信不信，把各家的ECU的源码都拿出来，还真不一定就比TOYOTA强到哪里去。

兔子特饱 发表于 2013-10-28 11:13

那个法院记录非常好看，跟大一时老师说的如何不这么写程序很象。。。

没想到一个这么大的公司写的程序非常的业余，整个project都是在打补丁，最开始是用汇编写的，后来改成C，开始没有throttle control的要求，后来要求加上去了。。。犯的错误也非常的原始，最主要是没有好的概念，估计整个project没有自己的软件测试，很多函数写的巨大，最后已经没法测试了。又用了11000全局变量，这个不敢想象，能有10个全局变量估计都算是太多了，它居然有11000个。。。怎么读/写的协调，function call的顺序等等，能写出来这么大一个程序，居然大部分情况下能工作，这程序员能回家安稳睡觉，我觉得这心理承受能力真的很强。。。

BYY 发表于 2013-10-28 11:53

按TOYOTA的产量，这么烂的程序居然出问题的车的车辆比例这么低，不能不说TOYOTA还真有两把刷子
另外别以为大公司的的程序就好，多少大公司的程序年复一年的运行，补丁摞补丁， 外人看起来烂的一塌糊涂可它就是工作。我们公司自己的烂程序海了去了， 我见得太多了。

兔子特饱 发表于 2013-10-28 11:13

那个法院记录非常好看，跟大一时老师说的如何不这么写程序很象。。。

没想到一个这么大的公司写的程序非常的业余，整个project都是在打补丁，最开始是用汇编写的，后来改成C，开始没有throttle control的要求，后来要求加上去了。。。犯的错误也非常的原始，最主要是没有好的概念，估计整个project没有自己的软件测试，很多函数写的巨大，最后已经没法测试了。又用了11000全局变量，这个不敢想象，能有10个全局变量估计都算是太多了，它居然有11000个。。。怎么读/写的协调，function call的顺序等等，能写出来这么大一个程序，居然大部分情况下能工作，这程序员能回家安稳睡觉，我觉得这心理承受能力真的很强。。。

一九七八 发表于 2013-10-27 19:06

代码能杀人吗？能，并且显然已经杀过人了。

兔子特饱 发表于 2013-10-28 11:13

那个法院记录非常好看，跟大一时老师说的如何不这么写程序很象。。。

没想到一个这么大的公司写的程序非常的业余，整个project都是在打补丁，最开始是用汇编写的，后来改成C，开始没有throttle control的要求，后来要求加上去了。。。犯的错误也非常的原始，最主要是没有好的概念，估计整个project没有自己的软件测试，很多函数写的巨大，最后已经没法测试了。又用了11000全局变量，这个不敢想象，能有10个全局变量估计都算是太多了，它居然有11000个。。。怎么读/写的协调，function call的顺序等等，能写出来这么大一个程序，居然大部分情况下能工作，这程序员能回家安稳睡觉，我觉得这心理承受能力真的很强。。。

cong1517 发表于 2013-10-28 11:30

个人理解，全车的电子系统都由ECU控制

会跳的蛋 发表于 2013-10-28 11:24

ECU管不到空调吧，什么都管累死ECU。。。。

cong1517 发表于 2013-10-28 11:20

丰田的ECU就一个笑话，我们公司一台凯美瑞电瓶挂了之后，空调系统居然乱了，无法正确显示温度也无法调节温度，只能调风扇出风量。

mcv 发表于 2013-10-28 11:08

这样的话硬件可靠性应该可以了吧。

会不会两套ECU跑的一样的软件（好像低级了点），或者有一样的软件bug？那样的话两个ECU就可能一起挂掉。

兔子特饱 发表于 2013-10-28 11:02

按这个Barr的说法，按理偷油2002年就应该按工业界的标准，用另外一套硬件来做fail-safe，但偷油用的一套硬件，用软件的方法来实现的。在特定的情况下（比如软件的虫子写错内存了等等），task-x死掉后，就不被OS重新执行，如果没有task-x那fail-safe的程序也不被重启。

这task-x和其他几个task里的几十个程序属于巨大无鹏的，无法测试的，有个程序有～150多个conditions/if-else,偷油自己则没有测试程序，没法unit-test. 如果能把一个虫子捉出来，捉的过程会产生更多的新虫子，属于没法下手的。。。

全局变量有1万1千多个，难道偷油不知倒用参数，struct... ?

这些软件是从2000年到2010年的，包括camry/ES/tacoma，如果偷油其他车的软件也是类似的设计环境/概念/水平的化，那真不太看好。。。

会跳的蛋 发表于 2013-10-28 10:58

有两套ECU，两套ECU的必须同时给出相同的指令系统才会执行，不一致不执行。两套ECU同时出错的概率应该很低。Barr Group的报告好像没涉及到这个问题，给我的感觉是摘掉电热水器的漏电保护谈电热水器电死人的概率<img src=\"https://forum.xitek.com/static/image/smiley/xitek/expr020.gif\" border=0>

五道口往事 发表于 2013-10-28 11:02

同为屌丝码农，做过不少Windows驱动程序开发。但是没做过这种ECU类的嵌入式开发，所以不知道硬件因素造成的memory corruption有多严重。
从原文这句话看“Stack overflow and software bugs led to memory corruption”，似乎根据他们的分析问题主要还是软件造成的。
C语言很容易出这种问题，比如局部变量数组访问越界了，刚好把旁边的指针破坏了，然后再用这个坏指针去访问另外一个变量，很可能是全局的，比如MAP图之类的，不知道MAP是不是每次都去ROM里读，还是初始化的时候先读到RAM里。当然，也可能是其它的数据了，按理这种栈溢出造成的内存破坏位置应当是随机的，但是某些情况下可能局限在一定的范围内。总之这种coding的错误确实很低级。

一般一款车的ECU代码量大概有多少？20-30万行？

孟姜女 发表于 2013-10-28 09:54

想知道丰田的fail-safe，程序不关心。