搜索
bottom↓
回复: 269

丰田栽了的原因,嵌入式软件工程师都该看看

  [复制链接]

出0入0汤圆

发表于 2013-11-3 21:04:39 | 显示全部楼层 |阅读模式
【第一部分】背景简介



前几年闹得沸沸扬扬的丰田刹不住事件最近又有新进展。十月底俄克拉荷马的一次庭审,2007年一辆2005年凯美瑞暴冲(Unintended Acceleration,UA)致一死一伤事件中丰田被判有责。引起广泛关注的是庭审中主要证人Michael Barr的证词让陪审团同意丰田的动力系统软件存在巨大漏洞可能导致此类事件。这是丰田在同类事件中第一次被判有责。庭审过后丰田马上同意支付300万美元进入调解程序。

出于好奇,我漫不经心地下载了Barr的286页证词,却一下子被吸引住了。几天内读完,算是对这次事件进行了一次深入了解。下面就从外行角度总结一下这份证词并尝试以更简单的语言解释里面提到的暴冲原因以及丰田犯下的错误。

Barr的证词下载自他的个人博客Barr Code,但现在该文已经被删除。稍后找地方上传。

Michael Barr是谁?他是一位拥有20年以上行业经验的嵌入式系统工程师。在十八个月中,有12位嵌入式系统专家,包Barr,受原告诉讼团所托,被关在马里兰州一间高度保安的房间内对丰田动力控制系统软件(主要是2005年的凯美瑞)源代码进行深度审查。这房间没有英特网,没有手机信号,他们进出不能携带任何纸张、记录甚至皮带。最后的调查结果被写入一份800页,13章的详细报告。而鉴于保密协议,调查内容一直没有公布,直至俄克拉荷马这次庭审才首度部分公开(报告本身似乎还没公开)。

回到正题。丰田的软件有没有缺陷?根据Barr的调查,答案是有。这其实是废话,任何软件都会有缺陷,关键在于是什么样的缺陷。丰田的软件缺陷分为三类:

非常业余的结构设计。
软件设计的基本要求是模块尽量简单化,因为这样可以一来更易于阅读二来更易于维护。但丰田的工程师显然没有遵循这原则。Barr使用一种工具自动根据代码的可能分支数量评估函数的复杂度,结果是丰田的软件中至少有67条函数复杂度超过50,意味着运行这个函数可能出现超过50种不同的执行结果,属于“非可测”级别。因为为了测试这50个不同的结果,必须准备至少50条不同的测试用例以及相应的文档,在生产环境中一般是不现实的。作为比较,Barr表示他自己的公司严格执行的其中一条规定就是任何代码复杂度不能超过30,否则不合格。而在这67条函数中还有12条复杂度超过100,达到“非可维护”级别,意味着一旦发现缺陷(Bug)也无法修复,因为实在太复杂,修复缺陷的过程中会产生新的缺陷。其中最复杂的一条函数有超过1300行代码,146个可能执行路径——正好用于根据各传感器数值计算节气门开关角度。
如果你不知道什么是节气门,那么这里我稍微解释一下。为了让内燃机运行,有三大要素:燃油、空气和点火时机。空气和燃油的混合物进入气缸,被火花塞在正确的时间点燃推动活塞并最终推动曲轴和车轮前进。在电喷技术发明以后直到2002年以前,三大要素的燃油和点火时间是由电子设备控制,节气门机械连接加速踏板,由司机直接控制。节气门大致是一个连接加速踏板的“空气龙头”——踩下去越多,“龙头”打开得越大,允许越多的空气进入发动机输出更大的动力。2002年以后,丰田引入的“电子油门”让电子系统掌管了最后一个要素:空气。加速踏板不再机械连接节气门,而是连接一些传感器,由行车电脑将这些传感器数值计算成节气门开启角度再由马达控制节气门。我们稍后会再讨论节气门开合。
极复杂的代码带来的是极复杂的功能。下面说一下被称为“厨房洗涤盆”的Task X。这里先解释一下,丰田的软件系统和很多别的软件系统一样,都是由一个统领程序(称之为“操作系统”)和若干小程序(称之为Task)组成。就好比电脑上跑的Windows是统领全局的操作系统,网络浏览器和记事本是跑在操作系统上的小程序。丰田的系统里每个Task都有自己的名字,但这些名字非常敏感,敏感到每次被提及的时候律师都要求法庭内的没有阅读代码权限的人全部清场。为了减少清场次数,Barr将这个最重要的小程序称为Task X。这个Task X有多重要呢?跟厨房里的洗涤盆一样重要。它负责非常多的事情,包括计算节气门开启角度、速度监测和保持、定速巡航监测等等。Task X的不正常运行被认为是暴冲事件的元凶。稍后会再继续讨论Task X。
还有一些别的匪夷所思的发现。比如丰田的软件包含了超过一万一千个全局变量。如果你不知道什么是全局变量,那么只需要知道软件设计的一般原则是要尽量少使用全局变量,因为有可能带来无法预测的结果。这里的“少”的意思是“尽量接近零”,绝对不会是一万一千个。
不符合软件开发规范。
如同很多行业一样,汽车行业也有自己的规范。更具体一点,由于汽车的危险性质,汽车控制系统被划分为“安全关键性系统(Safety Critical System)”——说白了就是安全性非常重要,弄不好会死人的。为了达到这一特殊要求,汽车相关软件开发人员定期举行会议讨论并发布编程规范,称为MISRA C。该规范的2004年版的感谢列表里还能看到丰田员工的名字,至少让外界认为丰田确实也在遵循这些规范。
真的吗?根据源代码来看,答案是否定的。对此之前的NASA报告也有所提及,丰田辩称他们遵循的不是行业规范,而是丰田内部编程规范。这一规范与行业规范的吻合程度达到50%。但是Barr认为根据他的调查,两个规范之间吻合度小于10%,甚至有若干规范条目相互冲突。后来发现丰田的代码甚至没有遵循丰田内部规范,当然比起别的问题这个已经无关紧要了。
MISRA C拥有超过100条规范,NASA的调查只使用了到其中35条进行校对,发现超过7000处违规代码。Barr使用全部条目,对照结果是丰田的程序拥有超过80000处违规代码。
这些数字说明了什么?根据统计,违规数量可以用于预测代码中暗藏的缺陷(Bug)数量。在之前提到的汽车相关软件开发人员会议中,有人就这一主题发表过专题演讲,提出每30处违规代码可能包含一个重大缺陷和十个轻微缺陷。讽刺的是这人是丰田员工。
特别需要指出MISRA C其中一个规则的内容是不得使用递归。
如果你不知道什么是递归,那么这里我稍微解释一下。递归是一种计算方法。但一般计算方法要么是自己算,要么询问别的计算模块索要结果。而递归则是通过问一层层问自己的方法完成计算。好处是代码简单,坏处是计算层数不固定。可能会2层就出结果了,也可能会是10000层,在设计程序的时候无从得知。
软件计算需要消耗存储器。越繁琐、越长的计算自然需要占用越多的存储器。递归的问题在于其嵌套层数无法预测,从而导致可能消耗的存储器容量无法控制。稍后会再讨论存储器。
对关键变量缺乏保护。
什么是变量?变量就是存在一段存储器的0和1的集合。这些变量既可以是一些函数的处理结果,也可以是另一些函数的处理原材料。比方说前面提到有一条程序专门计算节气门开合角度,比如说是20度,这个20就是一个变量,存在存储器的一个指定位置。另一个程序专门负责开合节气门,它知道去那个指定位置读取这个20,然后把节气门开启20度。
什么是保护?嵌入式系统,或者任何系统,都会在一定条件下发生硬件或者软件错误。客观上这是无法避免的。而且汽车作为一个时常在震动、发热、位移的系统,它的内部环境不能说不恶劣,发生硬件错误的可能性甚至更高。什么样的硬件错误呢?别忘了变量都是0和1的组合,这些0和1由存储器上的高低电平代表。由于某些不可抗原因,一个电平从高变成低,或者反过来,那么这个变量就被更改了。这被称为“位反转(Bit Flip)”。为了对抗这样的事情发生,需要对变量进行保护。保护的方法一般是镜像法。简单来说就是在两个不同的地方写入同一个变量,读取的时候两边都读,比较是不是一致。如果不一致,那么可以得知这个变量已经不可靠,需要进行容错处理。
丰田的程序总体上对其上万个变量进行了有效保护,但问题出在操作系统上。前面提到丰田的软件本质上分为操作系统和Task。Task是由丰田自己开发,但是操作系统则是由芯片供应商提供,固化在芯片里的。丰田在这里的过失是没有对供应商提供的代码进行深度审核,拿到什么用什么。
另一个保护措施是错误校验码(Error Detective and Correction Codes,EDAC)。这是一个硬件层面的数据保护措施。简而言之就是给内存中每一个字节(8比特)后面物理地增加几比特校验码。这样万一变量出错了,可以通过校验码得知,甚至可以通过校验码修复一些轻微错误。这个措施十分简单有效,但是在2005年款凯美瑞的系统中完全没有使用,丰田却告诉NASA他们用了。而在2008年款凯美瑞中使用了3比特长的EDAC。Barr认为是为了节省成本,否则应该使用5比特长。
还有值得一提的是,汽车相关的软件行业有那么几家操作系统供应商,早已形成了一套成熟标准称为OSEK。各供应商开发的符合OSEK认证的操作系统至少都能达到一定的质量。但丰田选用的操作系统却没有通过认证,让人不解。


现在我们知道丰田在编写软件的时候至少有三种缺陷。那么重点问题:丰田的这些软件缺陷是否会导致车辆暴冲?根据Barr的调查,答案是有可能。暴冲的起因需要结合上述三种缺陷来说明。

汽车正常运行需要倚靠若干程序(这里叫Task)的同时运作。Task有很多,CPU只有一块,在任何时刻只能处理一个Task,怎么办呢?这需要操作系统的统筹规划,合理分配CPU的任务,让每个Task都能按时执行。如果出现某种意外,让某个Task突然不执行了,那么就称为这个Task“死亡”。Task死了,自然不能执行它的任务。根据Barr的测试,在某些特定情况下,Task X的死亡可以导致节气门敞开——因为Task X的其中一个任务就是根据司机的操作计算节气门开合角度,它死了也就没法重新计算这个角度,即使司机把脚挪开加速踏板,节气门也无法关闭。此为暴冲的直接原因。更糟糕的是,节气门的开合角度这个数值,被Task X算出来以后保存在一个变量中。这个特定的变量正好没有被保护(缺陷3)。意味着万一Task X死亡并且停止计算,这个数值有可能因为不可抗原因被改变,而程序无从得知。

那么Task X为何会死亡呢?一般是因为内存出错。这个出错可能是一个小小的位反转,也可能是内存里的数值被别的程序错误覆盖。同一系统内同时运行了若干程序,这些程序需要共享一块内存,内存内部必然要被划分成若干块。比如第一块给程序1,第二块给程序2,等等。如果程序1因为某些原因(比如Bug)写到第二块内存上去,就会导致程序2读取了错误的信息。这就是所谓的内存出错。丰田的系统里,正好有这么两块相邻的内存块。第一块被称为“堆栈(Stack)”,这是所有Task存储它们运行状态的地方,大小为4KB。与之相邻的地方储存了操作系统进行任务分配的记录。那么可以想象,如果很多Task给堆栈里写入太多东西,超过4KB,那么就会错误地写入与之相邻的任务分配表。这种错误被称为“堆栈溢出”。操作系统拿到了错误的任务分配表,就会错误地分配任务,造成某些Task多执行几次,某些Task少执行几次,某些Task甚至就再也不执行——死了!必须指出的是,程序死亡并不罕见,甚至可以认为是正常现象。稍后解释处理方法。

那么堆栈为什么会溢出呢?显然是因为要写入的数据超过了堆栈的容量。在设计程序的时候要计算最坏的情况并且允许冗余。即使作出了正确的设计,这种错误也相对常见,所以NASA在他们的调查中重点排查堆栈溢出的可能性。于是NASA问丰田,丰田的回复是最坏的情况下4KB堆栈只写入了41%的数据,换句话说发生溢出的可能性非常低。NASA直接取信了这个数字并没有再深入调查。但Barr他们发现丰田的回答有严重低估,实际上最坏的情况会达到94%,而且还不算递归。丰田在代码中使用了递归(缺陷2)。因而实际数字有可能超过94%而且无法预计上限,因为递归计算的嵌套层数是无法预测的。所以实际情况下堆栈溢出的可能性相当可观。一旦溢出,相邻的任务分配表不可避免就会遭到破坏。此为暴冲的根本原因其中之一。之所以说“其中之一”,是因为堆栈溢出仅仅是损坏任务分配表的其中一个原因,别的还有许多可能性并没有被Barr在法庭上深入解释。而且任务分配表的损坏也仅仅是导致Task死亡的原因之一。
顺便提一句,2005年的凯美瑞的这部分供应商是电装,没有搭载堆栈实时监测功能——溢出了也不知道。同年的卡罗拉却搭载了,因为供应商是通用。


到这里我小结一下,串链子。左边是原因,右边是后果。
堆栈溢出→(可能导致)→任务分配表被改写→(可能导致)→Task X死亡→(可能导致)→节气门敞开→(导致)→汽车暴冲

必须指出的是,这条链子从最左边一直到Task X死亡,都还算是嵌入式系统的常见故障。虽然程序代码写得不好也许导致更容易出错,客观上丰田并没有特别大的过错。只要处理得当,这些故障都不会导致暴冲。

到此为止还只是前奏而已,接下来我们来看看丰田到底做错了什么。

【第二部分】丰田之罪

上面反复提到,嵌入式系统中内存出错或者程序死亡其实是一种正常现象——至少从Barr的证词可以得出这个结论——现在连我们都知道了,嵌入式工程师肯定比我们更清楚才对。确实,为了使系统正常运行不被错误干扰,一般的做法是设置若干层防护措施(Failsafe),让运行中出现的错误无法轻易突破,得到妥善处理。丰田的工程师自然也懂得这一点。很可惜,他们搞砸了。

上面那条链子应该修改成这样:
(防护措施0)→堆栈溢出→(防护措施1)→(可能导致)→任务分配表被改写→(防护措施2)→(可能导致)→Task X死亡→(防护措施3)→(可能导致)→节气门敞开→(防护措施4)→(导致)→汽车暴冲

可以看到,防护措施不可谓不多。只要处理得当,这链条应该是走不通的。现在让我们从左到右看一个小小的内存错误是如何一层层突破防护最终导致汽车暴冲的。

首先防护措施0。这个其实上面提到了,因为设计缺陷低估了最大占用的存储容量,并且不符合规范地使用了递归,最终可能导致堆栈溢出。

然后到防护措施1。上面也提到了,任务分配表紧邻堆栈。作为外行我都觉得这是个十分危险的设计——既然堆栈这么容易溢出,好歹应该将任务分配表放远一点啊。当然我是外行,可能实际上比想象中复杂很多。这段Barr的证词中并未特别提到,属于我的个人理解。

防护措施2。从这里开始丰田的错误越发严重。任务表被改写导致某些Task运行异常,在软件层应该有若干检测措施,比方说用特殊的监视Task来监视别的Task是否正常。但丰田是怎么做的呢?还记得上面的“厨房洗涤盆”Task X吗?它是如此复杂(缺陷1),除了控制汽车运行的任务之外竟然还兼任大部分的监视任务,比如生成DTC。
DTC(diagnostic trouble codes),是汽车电脑系统会根据情况生成的错误代码。有的车主可能会遇到汽车某报警灯常亮,修车师傅拿个仪器插在行车电脑上得出一个代码,再查表就知道哪个元件坏了——这就是DTC。除了用于修车,DTC还被用于检测行车电脑和各传感器的异常状态。
可以想象,这个既是运动员又是裁判的Task X一旦死亡,软件层的检测措施大部分就失效了。

防护措施3。在这里丰田的错误开始到达顶峰。即使设置正确无误,上面提到的监视Task也只不过是另一个Task而已,与它的监视对象算是平级——监视Task自己同样有可能出现故障。嵌入式系统的一般做法是在所有程序之上再设置一道屏障,被称为“看门狗(Watchdog)”。所谓看门狗,是一个优先级很高的倒计时程序。别的程序需要在运行的时候特意去重置一下这个计时器让它重新开始倒计时,这个动作被称为“喂狗”。如果因为程序出问题太长时间不喂狗,倒计时完成,看门狗知道什么地方卡住了,马上采取措施,比如重启整个系统。重启系统听起来似乎很严重,实际上却是一件相当普通的事情。嵌入式系统的重启非常快,时速100公里的汽车中动力系统可以在半米之内完成重启——车上的人根本觉察不到。
通过阅读代码和拟真实验,Barr惊讶地发现上述嵌入式系统的常识性做法竟然在丰田软件系统内不存在!丰田的软件确实有一只看门狗,但它竟然不是用于监视Task异常,而是用于防止CPU过载。首先这个做法不能说后无来者至少算是前无古人。还记得上面提到的800页13章的报告吗?目瞪口呆的Barr将丰田看门狗的分析结果写入了报告的第一章,因为他实在太震惊。其次,丰田看门狗的防止CPU过载功能也相当蹩脚,在拟真测试发现即使它正常工作,还是会允许CPU过载时间长达1.5秒——时速100公里的车能跑40米以上。CPU一旦过载,就会导致所有的Task进入一种“假死”状态,无法处理信息,这时司机无法控制汽车动力,十分危险
另外,丰田的工程师还犯了一个嵌入式课堂上被反复提到的经典错误:使用硬件时钟中断喂狗。硬件中断拥有非常高的优先级,即使Task卡住(比如出现死循环)也不能阻止硬件中断——可想而知这样一来看门狗就等于完全白瞎了。
这里也提一句,同年的普锐斯却令人意外地搭载了一只运作正常的看门狗,反而让人摸不着头脑。
还没完。这一层防护是嵌入式系统的关键阵地。前面都是电子系统,后面马上进入机械运作,足以造成灾难了。所以仅仅拥有软件级别的防护还不足够,丰田的做法是在主CPU之外单独设置了一块监视芯片,从硬件级别对系统的运作进行监视。监视芯片有两个任务。第一,它运行一种叫做系统卫士(System Guard)的程序,原理上来说是专门用于防止暴冲。主CPU和监视芯片上都会运行系统卫士,可是研究发现Task X一旦死亡,这些系统卫士统统都不起作用了。第二,它运行一个被称为“刹车回声检查(Brake Echo Check)”的程序。这个程序从代码上来看似乎可以检测出Task X的死亡,并且采取相应措施:关闭节气门。听起来像是好消息,但是同样有问题:首先这个程序不太可靠,即使正常运行,理论上也有失效的可能。最关键的是该程序不会自动运行,需要司机先对刹车踏板有“动作”才会触发。注意这里我特意没用“踩刹车”这个词,因为根据分析“触发动作”十分令人困惑。它分两种情况:如果Task X死亡的那一刻司机的脚不在刹车踏板上,那么触发动作是踩刹车。还算可以理解。另一种情况,如果Task X死亡那一刻司机的脚踩在刹车踏板上,那么触发动作是完全释放刹车踏板。没错,察觉车子在不正常加速的司机需要停止踩刹车才能让控制系统关闭节气门!这种违背人类认知的行为应该不是丰田工程师特意设计的。如果是,他们到底在想什么啊?
到此为止,上面提到的都算是“战术层面”的错误,都是“小错”。在讲解这块监视芯片的时候,可以发现丰田犯下最严重的“战略层面”错误——基础设计。Barr认为,如果基础设计正确,上述那些小错都完全不会导致汽车暴冲——不管代码写得多业余,不管内存错误多严重,不管Task死得多频繁,统统不会致命。让我们回到2002年以前,没有电子油门的时候。那时候的拉线油门是由油门踏板机械连接的。当驾驶员的右脚踩下刹车,他的右脚必然不在油门踏板上,节气门自然而然地被关闭。这个动作如此自然,甚至算不上安全措施,仅仅因为每人只有一只右脚,不可能同时踩油门和刹车。当丰田设计电子油门的时候,只要稍微有点常识,都应该从设计阶段就将这一“自然而然”发生的动作考虑进去。但是很显然,他们没这么做。监视芯片上运行的代码是用汇编语言(一种更加接近机器执行代码,远离人类语言,更加难懂的编程语言)编写的,运行层次比主CPU的C语言更低。Barr认为如果设计得当,现有的监视芯片完全有能力胜任上述功能,需要的仅仅是几百行代码,别的什么都不用更改——不会提高任何生产成本。很遗憾,他们没有做到。


防护措施4。现在已经脱离电子系统,节气门已经敞开,发动机全速运转,需要使用机械运作来组织机械运作了。如何让向前冲的车子停下来?不开车的人都知道,刹车!现代汽车都装备了刹车助力,助力来自于发动机运转的时候产生的负压。我们知道发动机需要吸入空气,吸入体积等于排气量乘以转速。节气门又是用来阻挡空气的,那么节气门关闭而发动机转速相对高的时候(比如高速丢油门),发动机的实际空气吸入量比它能吸入的体积要少,那么从节气门到气缸进气口之间会形成明显低气压(所谓负压,比大气压力小)。刹车助力就是利用了这个负压推动气鼓产生更大的推力带动刹车片抓紧刹车盘。但是如果节气门敞开让空气随便进来,低气压就不存在了,这时刹车助力大大减弱,刹车效率也大大降低。这就是为什么暴冲事件当事人都说全油门的时候根本刹不住的重要原因。这个现象称为“真空损失(Vacuum Loss)”,存在于所有自然吸气的汽油发动机汽车(柴油和增压发动机没影响),不算丰田的错。但丰田迟迟不搭载刹车优先系统(Brake Override System)允许刹车的同时敞开节气门,毫无疑问是这个现象的帮凶。
所谓刹车优先系统,指的是保证同时踩下刹车油门两个踏板的时候无条件关闭节气门的功能。这么做很显然主要是为了降低发动机输出,同时也保证刹车助力。丰田在2010年的凯美瑞上终于搭载了刹车优先系统,但是别高兴得太早。根据Barr的调查,丰田竟然将如此重要的修改“理所当然”地写入了他们的“厨房洗涤盆”——Task X。我只能“哑然失笑,扼腕叹息”。


好了,到此为止都还是Barr的一面之词,而且大部分都是在那间守卫森严的房间内进行拟真测试得出的“理论结果”。那么实车测试情况如何呢?丰田对Barr的证词如何反驳呢?


先说说实车测试。为了证明理论,他们把2008年和2005年的凯美瑞放在马力机上,固定车身架起前轮模拟车辆运行情况。他们的做法是首先让车子运行在时速68英里(110公里),启动巡航,脚离开油门踏板。然后暂停巡航,速度开始下降。下降到一定程度恢复巡航,速度开始上升。在到达68英里的设定时速以前,他们用一台连接行车电脑的笔记本“注入”错误。所谓注入错误,就是人为地翻转一个特定字节——将0改成1,或者反过来——模拟内存损坏。结果完全符合理论,时速超过68英里也不停止加速,直至时速90英里(145公里),测试人员踩下刹车。大约1秒以后节气门被关闭,Barr认为这是上述“刹车回声检查”的功劳。


实车测试证明了Barr的理论,却并不是全无破绽。丰田辩护律师就两点提出质疑:
实车测试使用人工注入错误的方法,并不能证明现实中这种错误就一定会发生。
对此Barr的回答是测试的局限性。因为测试时间、样本有限,而待测试的样本空间无穷大。如果要等待那个特定的错误自然出现,可能需要成百万上亿小时的不间断测试,显然是不现实的。更何况从科学上而言,没有办法对这个错误证伪——就好比无法证明宇宙里没有外星人,最多只能证明火星上找不到而已。但是这个测试足以证明一个小小的位翻转确实可以突破重重障碍最终导致暴冲,足以证明丰田的软件存在不能容忍的隐患。
Bookout女士(本案原告)声称,在她驾驶汽车离开高速的时候发现不受控加速,她拼命反复踩下刹车并且拉起手刹,现场留下了刹车痕迹。但并没有迹象表明发动机动力中断——换言之“刹车回声检测”没起作用。暗指Barr的理论站不住。
对此Barr的回答是首先尽管在实车测试中每次都生效,但代码分析表明“刹车回声检查”这一功能在理论上靠不住。其次这一功能的另外一个触发动作是要让脚完完全全离开刹车踏板。试想车子正在不受控地往前冲,任何人都会不由自主地踩刹车,让人完全不踩刹车踏板根本就是违背认知的。Bookout女士即使如同她所称反复踩刹车,很可能只是一直将脚放在踏板上往复运动,从未完全挪开。Barr还引用一位丰田自己的软件专家的证词。该专家承认,如果发生暴冲的时刻脚正好接触到刹车踏板,并且之后一直没挪开,那么汽车的暴冲距离“取决于还剩多少汽油”。

最后顺带说一下那份800页,13章的详细报告完成后,Barr将其提交给了丰田的软件部门,等待他们的反驳。最终结果是“非常少(Very little)”,13章中的11章,包括堆栈溢出的部分、代码混乱的部分、违反开发规范的部分、Task X过于臃肿甚至兼任节气门控制和防护措施的部分、看门狗形同虚设的部分、无EDAC的部分、重要变量缺乏保护的部分、使用了非标准化操作系统的部分,全部没受到任何形式的反驳。


【第三部分】后记


写到这里,谈谈人们比较关心的几点。当然还是外行眼光。
NASA / NHTSA怎么没发现这些问题?
NHTSA本身不具备检验电子系统的能力,于是委托NASA。NASA检验的是整个电控系统,包括电控传动部分,范围比较宽,只有很少一部分资源被用于检验软件系统,也没有投入足够的人力进行逐行代码审阅。更何况在很多关键问题,比如之前提到的EDAC的使用、堆栈的设计,NASA都直接采信丰田的回复,最终被证明不正确。甚至NASA从来都没拿到过监视芯片的源代码,丰田的说法是“他们没说要啊”。NASA报告虽然没能找到软件系统导致暴冲的确切原因,但没有否定其可能性。与之相比Barr的团队全部都是嵌入式系统专家,投入上千小时,深入程度甚至超过丰田自身对这个系统的理解(比如丰田没看过供应商的OS代码,Barr看了)。
能否100%确定本案就是由软件错误造成的?
不能。并没有直接证据。诉讼团认为,软件错误造成该事故的可能性比软件错误没造成该事故的可能性大(原文:more likely than not)。
这里再提一句,2005年款的凯美瑞没有搭载行车数据记录器(俗称“黑盒子”),后来的车款渐渐开始搭载。但是Barr发现这个记录功能并不可靠,完全有可能记录错误信息。比如司机踩刹车了可能会被记录成没踩。
本案的意义
之前虽然丰田赔了不少钱,但是从未在涉及人身伤害的案件上承责。所以本案意义在于开先例。美国的法律又特别注重先例,今后丰田的法务部门要头疼了。
本案提到的有缺陷软件涉及了哪些车型?
全部是美国的车型。Barr的调查重点是2005年款凯美瑞,另外审阅过的包括雷克萨斯ES、Tacoma、卡罗拉和普锐斯等等,生产年份大致在2002年(电子油门元年)与2010年之间。其中凯美瑞、雷克萨斯ES和Tacoma使用的软件系统大致接近(原文:Substantially similar)。另外根据统计,汽车暴冲投诉中与2004年款以后的凯美瑞有关的案件数量激增400%。



最后的最后,放上本案关键证人Michael Barr的独家访谈:


我:这么看来似乎手动档汽车更安全,你怎么认为?
Barr:很多专家都这么认为,离合器至少可以物理断开动力系统。但是我翻阅卷宗,发现其中有个案例是受害者开手动档凯美瑞载着家人,突然巡航系统失灵,无法取消。他踩下离合,同时试图躲避前方慢速车辆结果失控冲出路面造成单车事故。幸运的是没死人。


我:现在我们都知道丰田的软件很糟糕。可是你对整个汽车行业的软件水平有什么看法?丰田的软件在同行内属于什么水平?
Barr:我没有接触过丰田以外的软件代码。但是请注意,这次发现的最严重问题是丰田在设计源头上没有考虑安全,软件质量反倒没有那么重要。只要一个安全为先的设计,比如刹车和关闭节气门的可靠互动、防止节气门开启降低刹车效率的机制等等,不管软件有多差劲也不会造成致命结果。只是我真不知道软件还能怎么差。


我:终极问题,你开什么车?
Barr:我不开丰田。接触该案以来我没买过新车。老实说我现在非常害怕买新车。我倒是问过一个与车企斗争了三十多年的职业状棍同样的问题,他开宝马。


【全文完】

阿莫论坛20周年了!感谢大家的支持与爱护!!

如果想吃一顿饺子,就得从冰箱里取出肉,剁馅儿,倒面粉、揉面、醒面,擀成皮儿,下锅……
一整个繁琐流程,就是为了出锅时那一嘴滚烫流油的热饺子。

如果这个过程,禁不住饿,零食下肚了,饺子出锅时也就不香了……《非诚勿扰3》

出0入0汤圆

发表于 2013-11-3 21:10:25 | 显示全部楼层
果断复制下来,很有启发。最重要的是最好别开太智能的车,甚至不要过度依赖智能。顺便说一下,现在无线上网的频率是对人体有害的,会不育

出0入0汤圆

发表于 2013-11-3 21:27:41 | 显示全部楼层
  大长经

出0入17汤圆

发表于 2013-11-3 21:29:30 | 显示全部楼层
这样的软件连消费品都不能用~~~~~~

出1000入0汤圆

发表于 2013-11-3 22:00:30 | 显示全部楼层
国内也发生几起事件了,该品牌我觉得不可靠,顶楼主

出10入113汤圆

发表于 2013-11-3 22:00:39 | 显示全部楼层
好像很鄙视汇编?

出0入0汤圆

发表于 2013-11-3 22:04:52 | 显示全部楼层
有意思的是就在昨天举办的智能车未来挑战赛中,中国某高校在后方手动制动的前提下仍然撞到观众,可悲啊,从863开始研究的项目搞到现在还跟坨shit一样

出5入4汤圆

发表于 2013-11-3 22:06:29 | 显示全部楼层
很值得看的文章,不错。。丰田的工程师也太没水平了吧~~~。

出0入0汤圆

发表于 2013-11-3 22:09:18 | 显示全部楼层
越复杂的东西越不稳定
之前测试过一个安卓的车载咨询仪 用及其快的速度点触摸屏会导致系统无响应 弹出服务错误 然后重启

出0入0汤圆

发表于 2013-11-3 22:36:45 | 显示全部楼层
这文章给我们的提示是:
无论你的程序编的有多烂,只要营销做得好,都能赚到钱!

出0入0汤圆

发表于 2013-11-3 22:38:21 | 显示全部楼层
饭桶 发表于 2013-11-3 22:00
好像很鄙视汇编?

楼主,你头像哪里来的?

出0入0汤圆

发表于 2013-11-3 22:40:08 | 显示全部楼层
顺便传上来吧

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?注册

x

出0入0汤圆

发表于 2013-11-3 22:40:56 | 显示全部楼层
EDAC什么的,不知道什么芯片可以实现?还有那个数据容错处理,是不是程序上面也需要加一下试试。。。

出0入0汤圆

发表于 2013-11-3 22:43:00 | 显示全部楼层
讲了好长,和心中日本一向的严谨靠不上边,这真是的丰田吗

出0入442汤圆

发表于 2013-11-3 22:43:03 | 显示全部楼层
gongxd 发表于 2013-11-3 22:09
越复杂的东西越不稳定
之前测试过一个安卓的车载咨询仪 用及其快的速度点触摸屏会导致系统无响应 弹出服务 ...

呵呵,ACDSEE你知道吧,这软件飞速转滚轮时必然崩溃,我用的最早的6.0,到14.0,都没有被修复。

出0入0汤圆

发表于 2013-11-3 22:45:18 | 显示全部楼层
如果是日本本土的那就是截然不同

出0入0汤圆

 楼主| 发表于 2013-11-3 22:56:53 | 显示全部楼层
Nexus 发表于 2013-11-3 22:40
EDAC什么的,不知道什么芯片可以实现?还有那个数据容错处理,是不是程序上面也需要加一下试试。。。 ...

infineon和freescale的汽车芯片都有吧,cortex-r4f应该也有,具体多少位没研究过

出0入0汤圆

发表于 2013-11-3 23:02:09 | 显示全部楼层
schwarz 发表于 2013-11-3 22:56
infineon和freescale的汽车芯片都有吧,cortex-r4f应该也有,具体多少位没研究过 ...

看上去很多地方都很有必要使用此类芯片貌似~~~

出0入0汤圆

 楼主| 发表于 2013-11-3 23:07:50 | 显示全部楼层
Nexus 发表于 2013-11-3 23:02
看上去很多地方都很有必要使用此类芯片貌似~~~

200人刀你用不起……
infineon和freescale在汽车电子上面的垄断地位不是吹出来的。

出0入0汤圆

发表于 2013-11-3 23:09:35 | 显示全部楼层
schwarz 发表于 2013-11-3 23:07
200人刀你用不起……
infineon和freescale在汽车电子上面的垄断地位不是吹出来的。 ...

。。。看到价格,明白了~~~~但说实话,我觉得如果价格稍微低一点,还是有必要的,比方说电力行业~

出0入0汤圆

发表于 2013-11-3 23:38:45 来自手机 | 显示全部楼层
有意义,Mark!
来自:amoBBS 阿莫电子论坛 Windows Phone 7 客户端

出0入134汤圆

发表于 2013-11-4 00:15:08 | 显示全部楼层
有点意思,看丰田的软件工程师很是不靠谱啊

出0入0汤圆

发表于 2013-11-4 00:17:29 | 显示全部楼层
好长,有时间慢慢看吧

出0入4汤圆

发表于 2013-11-4 00:43:39 | 显示全部楼层
MARK.............

出0入0汤圆

发表于 2013-11-4 00:44:10 | 显示全部楼层
真的犯这样的软件错误,绝对是NC了

出0入0汤圆

发表于 2013-11-4 00:56:49 | 显示全部楼层
码农们都洗洗睡了吧,根据文中的观点,这事跟咱们其实没多大关系。

问题出在系统分析师/软件架构师这个层面。

出0入0汤圆

发表于 2013-11-4 00:59:32 | 显示全部楼层
看完,增长了知识,扩展了视野。。。

出0入0汤圆

发表于 2013-11-4 01:02:05 | 显示全部楼层
longfeix86 发表于 2013-11-3 22:40
顺便传上来吧

其它领域有类似的规范吗?譬如电力测量那边的,医疗电子那边的?

出0入0汤圆

发表于 2013-11-4 01:22:53 | 显示全部楼层
结论:还是买手动档的

出0入0汤圆

发表于 2013-11-4 01:26:00 | 显示全部楼层
看完了。附件下不了。

出0入0汤圆

发表于 2013-11-4 07:58:24 | 显示全部楼层
居然这么悲剧  哎

记下了

出50入0汤圆

发表于 2013-11-4 08:15:21 | 显示全部楼层
"一万一千个全局变量"估计包含大数组

出0入0汤圆

发表于 2013-11-4 08:20:59 | 显示全部楼层
gongxd 发表于 2013-11-3 22:09
越复杂的东西越不稳定
之前测试过一个安卓的车载咨询仪 用及其快的速度点触摸屏会导致系统无响应 弹出服务 ...

难度是用的中断方式读取触摸屏,哈哈哈
中断太频繁了。。。。。。

出0入0汤圆

发表于 2013-11-4 08:21:57 | 显示全部楼层
这个车的源代码是哪里来的?不会是丰田提供的吧?

出0入0汤圆

发表于 2013-11-4 08:24:13 | 显示全部楼层
wychao 发表于 2013-11-4 08:21
这个车的源代码是哪里来的?不会是丰田提供的吧?

肯定啊   法官要求了必须提供 不过是在安全环境下的哦

出0入0汤圆

发表于 2013-11-4 08:31:54 来自手机 | 显示全部楼层
本帖最后由 daicp 于 2013-11-4 08:35 编辑

丰田不是80年代的丰田了

出0入147汤圆

发表于 2013-11-4 08:36:33 | 显示全部楼层
看完了,所以现在国外的车厂现在都在推功能安全标准ISO26262,丰田这个如果前期做好风险识别和功能安全目标,应该就不会出现这种情况了。

出0入42汤圆

发表于 2013-11-4 08:36:49 | 显示全部楼层
看完了,有启发

出10入113汤圆

发表于 2013-11-4 08:50:27 | 显示全部楼层
longfeix86 发表于 2013-11-3 22:38
楼主,你头像哪里来的?

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?注册

x

出0入0汤圆

发表于 2013-11-4 08:54:58 | 显示全部楼层
一个认真做事的被另一个认真做事的较了真。
不管当年米国干嘛要较真,经历风雨的丰田,去年还是全球汽车市场的第一名。

出10入10汤圆

发表于 2013-11-4 08:55:50 | 显示全部楼层
写的很好,学习了

出0入0汤圆

发表于 2013-11-4 09:24:49 | 显示全部楼层
实在是精彩无比!受教了

出0入4汤圆

发表于 2013-11-4 09:42:53 | 显示全部楼层
非常好的文章~~

出0入0汤圆

发表于 2013-11-4 09:47:06 | 显示全部楼层
比如丰田的软件包含了超过一万一千个全局变量。如果你不知道什么是全局变量,那么只需要知道软件设计的一般原则是要尽量少使用全局变量,因为有可能带来无法预测的结果。这里的“少”的意思是“尽量接近零”,绝对不会是一万一千个。

这个要怎么做,才能最少??
虽然我用得不是很多,但是我自己也觉得经常很难控制这些变量!!比如中断里面,数据就被改掉了,容易跑乱!!

出0入0汤圆

发表于 2013-11-4 09:54:52 | 显示全部楼层
饭桶 发表于 2013-11-4 08:50

得,咱再换一张

出0入0汤圆

发表于 2013-11-4 10:00:52 | 显示全部楼层
系统设计是关键

出0入0汤圆

发表于 2013-11-4 10:16:15 | 显示全部楼层
记得几年前程序员杂志专门有一篇文章介绍MISRA C,当时看了感觉很有用。现在写C的时候尽量按照这个标准进行,确实有好处。特别是对经常升级或者更换编译环境的有用。

程序复杂到一定程度,故障的出现已经不是人控的了。所以国外的都是强调标准编程。我们国内还经常是个人单干,时候更在意效率和算法,而不注意标准和规范。比如你写一个程序,几年后你再看这个程序,好多地方就有点看不明白当时的意思了,所以标准和注释是非常重要的。另外大公司多人协作和程序员的变动,也需要大家按一个标准进行。

维护一个前人写的程序,就好比老房子装修。在后来的人不能全部推倒重建的情况下。只能在原有基础上调整、修补、增加。有些代码和变量的含义只有前人才知道,为了不引起太大的麻烦和问题,一般人就会重新增设变量或代码,这又增加了代码的复杂度和维护的难度。同时又因为技术发展太快,这种重要企业(多学科关联、交叉),更改某些东西可能需要更大的成本。这往往导致在管理上一级压一级,下级也是向上一级骗一级。上级说,你们要重新写,下级说,重写完了,很稳定。实验室测试不出来的东西不代表用户不产生问题。这种问题因为技术性太强,不是专家又发现不了,所以又不易被发现。最终导致这个结果。

以上是瞎写的,不知道大公司是不是这样,我估计或多或少都会出现这类问题。有时发展太快比一定是什么好事。

其实我们大家写的程序都这样,毕竟大公司还是有规范的。向我们个人写的程序,随意性不是更强。如果不是这样,微软也不至于经常更新程序了。他怎么也算最大的软件公司了。

随意瞎说的。有感而发。希望我们写程序的都能养成好的编程规范。至于多人协作,人员流动、时间流逝等原因带来的问题,就让那些公司去考虑吧。

出0入0汤圆

发表于 2013-11-4 10:35:32 | 显示全部楼层
这么好的帖子,这么高的技术含量,可是没几个人顶。

无语!!!!!!!!!!!!!!!!!!!!!!!

出0入0汤圆

发表于 2013-11-4 10:55:24 | 显示全部楼层
好贴,很受启发

出0入0汤圆

发表于 2013-11-4 10:56:09 | 显示全部楼层
太深奥了,如果在中国,中国有“专家”能让丰田这样的世界500强败诉??

出10入113汤圆

发表于 2013-11-4 11:06:32 | 显示全部楼层
longfeix86 发表于 2013-11-4 09:54
得,咱再换一张

这个头像的出处是哪?

出0入0汤圆

发表于 2013-11-4 11:12:38 | 显示全部楼层
好长啊,终于看完了,最后一段是亮点.

出0入54汤圆

发表于 2013-11-4 11:23:38 | 显示全部楼层
DiaoMao_Huang 发表于 2013-11-4 09:47
比如丰田的软件包含了超过一万一千个全局变量。如果你不知道什么是全局变量,那么只需要知道软件设计的一般 ...

使用write  read接口
各个模块管理自己的全局变量,模块内全部变量不对外开放。

出0入0汤圆

发表于 2013-11-4 11:25:56 | 显示全部楼层
longfeix86 发表于 2013-11-4 09:54
得,咱再换一张

上一张来自草……榴,这一张来自facebook

出0入0汤圆

发表于 2013-11-4 11:49:44 | 显示全部楼层
DiaoMao_Huang 发表于 2013-11-4 09:47
比如丰田的软件包含了超过一万一千个全局变量。如果你不知道什么是全局变量,那么只需要知道软件设计的一般 ...

我抛砖引玉,希望有大牛可以介绍一下:只有一个模块用到但多次用到的,用静态变量.多个模块用到的,放在main,再以参数形式传给模块.只有中断用到的就无解了,只能用全局.

出0入0汤圆

发表于 2013-11-4 12:34:56 | 显示全部楼层
读完,学习了!

出0入0汤圆

发表于 2013-11-4 12:40:41 | 显示全部楼层
有点怕了,不知国内2013款的修正错误没有

出0入0汤圆

发表于 2013-11-4 12:49:40 | 显示全部楼层
全文看完。。。。昨晚

出0入0汤圆

发表于 2013-11-4 13:22:32 | 显示全部楼层
lusson 发表于 2013-11-4 11:23
使用write  read接口
各个模块管理自己的全局变量,模块内全部变量不对外开放。

呵呵……变成私有变量了!!C++的,我是中断的情况,如果你的write  read接口在中断使用到,那还是会有这种情况的,在main主函数中运行的时候别修改掉了,目前我解决的办法是开一个缓存对列,获取数据就往队列的后面塞,main函数就从队列的头开始处理,暂时我还没想到其他更好的办法
头像被屏蔽

出0入0汤圆

发表于 2013-11-4 13:41:03 | 显示全部楼层
提示: 作者被禁止或删除 内容自动屏蔽

出0入0汤圆

发表于 2013-11-4 13:58:46 | 显示全部楼层
做了两年的软件系统测试,看到这篇文章,确实很不错~~   不得不顶啊

出0入0汤圆

发表于 2013-11-4 17:23:17 | 显示全部楼层
看今天南方都市报说美国“消费者报告”,2013汽车可靠性前十名有七名是日本品牌。雷克萨斯和丰田列第一和第二名。不知为什么这么差的车能列可靠性前两名?

出0入0汤圆

发表于 2013-11-4 17:53:04 | 显示全部楼层
又是大长经

出0入0汤圆

发表于 2013-11-4 18:35:24 | 显示全部楼层
DiaoMao_Huang 发表于 2013-11-4 13:22
呵呵……变成私有变量了!!C++的,我是中断的情况,如果你的write  read接口在中断使用到,那还是会有这 ...

你的思路不错。但是缓冲也需要做保护,建议看看操作系统中的生产者-消费者概念。

出0入0汤圆

发表于 2013-11-4 18:46:00 | 显示全部楼层
看完了,不知真假,这也太离谱了。

出0入0汤圆

发表于 2013-11-4 18:57:25 | 显示全部楼层
听某人说的,做铁路安全相关的软件,不允许用中断。。。全部在主循环内处理

出0入0汤圆

发表于 2013-11-4 20:02:14 来自手机 | 显示全部楼层
我想知道在没有芯片支持下,如何防止位反转……存到两个地方?那变量不是翻倍了?

出5入8汤圆

发表于 2013-11-4 20:30:55 来自手机 | 显示全部楼层
barr还真是个嵌入式方面的大牛啊,这种事情都要找他鉴定

出0入0汤圆

发表于 2013-11-4 20:31:40 | 显示全部楼层
这文章是翻译过来的吗?
后面的独家专访又是怎么回事?

出100入0汤圆

发表于 2013-11-4 20:33:44 来自手机 | 显示全部楼层
太长了,手机看的费劲,记号

出0入0汤圆

发表于 2013-11-4 22:11:56 | 显示全部楼层
什么车子最安全?!!!!

出0入0汤圆

 楼主| 发表于 2013-11-4 22:16:20 | 显示全部楼层
NewKing 发表于 2013-11-4 22:11
什么车子最安全?!!!!

很不幸,美欧权威机构测试的结果还是日本车最安全。
其实Barr最后说的很对,软件写的垃圾不重要,重要的是一开始的架构就错了,油门优先级高于刹车。油门踩到底卡住以后踩刹车不起作用才是导致死亡事故的罪魁祸首。油门卡住本身就是极小概率事件对安全性总体影响不大。

出0入0汤圆

发表于 2013-11-4 22:56:51 | 显示全部楼层
schwarz 发表于 2013-11-4 22:16
很不幸,美欧权威机构测试的结果还是日本车最安全。
其实Barr最后说的很对,软件写的垃圾不重要,重要的 ...

这让我们如何是好!

出0入0汤圆

发表于 2013-11-5 00:23:12 | 显示全部楼层
好文,顶。。。

出0入0汤圆

发表于 2013-11-5 00:57:29 | 显示全部楼层
Barr是神级专家啊。有这样的专家和这样的态度的国家,怎么能不强大。

出0入0汤圆

发表于 2013-11-5 08:50:50 | 显示全部楼层
没看完,太长了

出0入0汤圆

发表于 2013-11-5 09:27:04 | 显示全部楼层
好长啊,我看完了
Barr大牛

出0入0汤圆

发表于 2013-11-5 09:39:16 | 显示全部楼层
zbf 发表于 2013-11-4 20:02
我想知道在没有芯片支持下,如何防止位反转……存到两个地方?那变量不是翻倍了? ...

飞机上的电脑系统都是3套呢,3 中取2.。。
可以每更改一次变量就调用校验程序,校验不通过就重启。。

出0入0汤圆

发表于 2013-11-5 09:50:33 | 显示全部楼层
fsclub 发表于 2013-11-5 09:39
飞机上的电脑系统都是3套呢,3 中取2.。。
可以每更改一次变量就调用校验程序,校验不通过就重启。。 ...

假如校验程序所使用的变量,发生了“位翻转”,导致校验结果计算错误。此时怎么办?

出0入0汤圆

发表于 2013-11-5 09:57:26 | 显示全部楼层
PSP2000 发表于 2013-11-5 09:50
假如校验程序所使用的变量,发生了“位翻转”,导致校验结果计算错误。此时怎么办? ...

校验错误而使本来错的结果变成对的了?下次清空变量重来啊,一次出错应该不会有多少影响,毕竟刚刚说的每次更改变量都校验,因为汽车变量每次采样都会改变,所以一个校验失败应该不影响吧?

出0入0汤圆

发表于 2013-11-5 10:14:24 | 显示全部楼层
好东西,我将LZ提到内容重点部分用红色字标识出,便于人们设计时注意,并生成PDF版,希望便于阅读!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?注册

x

出0入0汤圆

发表于 2013-11-5 10:32:14 | 显示全部楼层
你们谁有MISRA-C-2012,MISRA-C++-2008, DO-254,DO-178C这些东东?能否分享一下?

出0入0汤圆

发表于 2013-11-5 11:03:42 | 显示全部楼层
the transcript is here:

http://cybergibbons.com/wp-conte ... a_Barr_REDACTED.pdf

出0入0汤圆

发表于 2013-11-5 11:58:53 | 显示全部楼层
多谢分享,关系人安全的软件设计和硬件设计都需要百倍的小心。

出0入0汤圆

发表于 2013-11-5 18:07:37 | 显示全部楼层
我在一家汽车公司干过,是很小的那种,就像作坊一样,压榨员工,所以我对汽车行业,有点害怕,

出0入0汤圆

 楼主| 发表于 2013-11-5 20:21:17 | 显示全部楼层
fsclub 发表于 2013-11-5 09:39
飞机上的电脑系统都是3套呢,3 中取2.。。
可以每更改一次变量就调用校验程序,校验不通过就重启。。 ...

民航飞机没你说的那么神奇,翼面作动筒、起落架这些跟安全直接相关才会有3套控制通道相互备份。至于其他的“电脑系统”一般是两套相互备份,而且除了专机所有的两套系统都是好用的以外,屁民做的飞机往往坏了一套一样可以放飞。

出0入0汤圆

发表于 2013-11-5 20:54:49 | 显示全部楼层
科技不是万能的!

出0入0汤圆

发表于 2013-11-6 00:08:54 | 显示全部楼层
好好记住,好的教训

出0入0汤圆

发表于 2013-11-6 09:28:19 | 显示全部楼层
我自己给日本做软件近20年,感觉日本的软件生产问题很多。
首先是日本的软件架构能力很差,做出来的东西我这种二把刀都看不上,更别说那些专家大牛了。
其次,日本人不太注重有限目标,设计开发过程中的需求变更基本上都是无条件接受,而不是放在下个版本中再做,即使有些变更与现有设计存在很大冲突。
第三,日本人过度强调人的因素,认为只要工作认真努力,就能做出高质量的产品,不太注重设计中的容错等方法性的因素。
最后就是日本人的锲而不舍的工作精神了。由于上述的很多根本性的问题,接近交付的时候产品基本上是千疮百孔,但是日本人很少愿意推倒重来,而是彻夜加班打补丁,最后一定要把它啃下来。(我真的很佩服他们基本上都能啃下来)
这样子做出来的东西,做软件的都知道,代码必定是一塌糊涂,出现11000个全局变量也就可以理解了。

出0入0汤圆

发表于 2013-11-6 09:33:37 | 显示全部楼层
elecfun 发表于 2013-11-4 00:15
有点意思,看丰田的软件工程师很是不靠谱啊

农民工所为,无证上岗

出0入0汤圆

发表于 2013-11-20 16:21:26 | 显示全部楼层
果断收藏!!

出0入0汤圆

发表于 2013-11-20 17:15:32 | 显示全部楼层
好长啊,看一部分,赶紧mark

出0入0汤圆

发表于 2013-11-20 17:57:17 | 显示全部楼层
millwood0 发表于 2013-11-5 11:03
the transcript is here:

http://cybergibbons.com/wp-content/uploads/2013/10/Bookout_v_Toyota_Barr_RE ...

哥们怎么还光着

出0入0汤圆

发表于 2013-11-21 09:35:11 | 显示全部楼层
这么恐怖啊

出0入0汤圆

发表于 2013-11-21 10:03:06 | 显示全部楼层
昨天看见有人黑大众,今天看到有人黑丰田。我还想买雷克萨斯来着
头像被屏蔽

出0入0汤圆

发表于 2013-11-21 10:26:45 | 显示全部楼层
提示: 作者被禁止或删除 内容自动屏蔽

出0入0汤圆

发表于 2013-11-21 11:02:56 | 显示全部楼层
绝对的发人深思啊,软件不会搞坏硬件,却可以搞坏使用硬件的人啊。

出0入0汤圆

发表于 2013-11-21 12:06:55 来自手机 | 显示全部楼层
饭桶 发表于 2013-11-4 08:50

深受启发也验证了我一向的谨慎观点,操作系统在带来的代码高速运行的同时其消息传递失效,堆栈溢出,内存管理混乱的弊端正在显现。

出0入0汤圆

发表于 2013-11-21 12:38:33 | 显示全部楼层
Mark 一下,读了很受益

出0入0汤圆

发表于 2013-11-21 12:44:27 | 显示全部楼层
灰常不错的帖子,看了开头,果断收藏 以后研究
回帖提示: 反政府言论将被立即封锁ID 在按“提交”前,请自问一下:我这样表达会给举报吗,会给自己惹麻烦吗? 另外:尽量不要使用Mark、顶等没有意义的回复。不得大量使用大字体和彩色字。【本论坛不允许直接上传手机拍摄图片,浪费大家下载带宽和论坛服务器空间,请压缩后(图片小于1兆)才上传。压缩方法可以在微信里面发给自己(不要勾选“原图),然后下载,就能得到压缩后的图片】。另外,手机版只能上传图片,要上传附件需要切换到电脑版(不需要使用电脑,手机上切换到电脑版就行,页面底部)。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

手机版|Archiver|amobbs.com 阿莫电子技术论坛 ( 粤ICP备2022115958号, 版权所有:东莞阿莫电子贸易商行 创办于2004年 (公安交互式论坛备案:44190002001997 ) )

GMT+8, 2024-3-28 23:37

© Since 2004 www.amobbs.com, 原www.ourdev.cn, 原www.ouravr.com

快速回复 返回顶部 返回列表