Board logo

标题: [杂谈] 【年度巨献】从外行的视角尝试讲解为什么这回丰田栽了【全文完】【v1.01】 [打印本页]

作者: Kuzuryuusen    时间: 2013-11-1 11:05     标题: 【年度巨献】从外行的视角尝试讲解为什么这回丰田栽了【全文完】【v1.01】

【第一部分】背景简介



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

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

Barr的证词下载自他的个人博客Barr Code,但现在该文已经被删除。见2楼。

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

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



现在我们知道丰田在编写软件的时候至少有三种缺陷。那么重点问题:丰田的这些软件缺陷是否会导致车辆暴冲?根据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的理论,却并不是全无破绽。丰田辩护律师就两点提出质疑:

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


【第三部分】后记


写到这里,谈谈人们比较关心的几点。当然还是外行眼光。



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


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


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


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


【全文完】


【更改历史】
v1.01(2013-11-06):后记部分增加为何没找到直接证据的技术原因。


【版权没有,转贴注明出处】

[ 本帖最后由 Kuzuryuusen 于 2013-11-6 11:52 编辑 ]
作者: Kuzuryuusen    时间: 2013-11-1 11:14

posted by wap

测试上传。
作者: colappc    时间: 2013-11-1 11:19

丰田必须死!麻痹赶紧退车退钱!!
作者: oando    时间: 2013-11-1 11:19

posted by wap, platform: iOS

不觉明历
作者: kagez    时间: 2013-11-1 12:16

posted by wap, platform: Firefox

极其专业,不懂拜服!
作者: 狂奔的牛牛    时间: 2013-11-1 12:18

有理有据,等看第二部分
作者: microxx    时间: 2013-11-1 12:28

全文看完,受益匪浅。
结合坛友的回帖,很好奇。这类关系到行车安全的基础程序,能多展开就好了。
很有可能现在日系特别是丰田已经大幅调整了程序,现阶段,日系、美系、德系、欧系的编程水平又是什么样的?非常好奇。

[ 本帖最后由 microxx 于 2013-11-4 11:07 编辑 ]
作者: ashbringer_k    时间: 2013-11-1 13:09

我猜猜 第二章的内容是不是:  ECU如上文出现问题导致节气门不受控制,汽车停不下来的话,在编写ECU时 如果有底层语句“刹车优先”这条命令来兜底

那么爆冲的情况就不会出现,而丰田的ECU里没有刹车优先.......所以汽车刹不住了。
作者: hailfruhner    时间: 2013-11-1 13:16

posted by wap, platform: iPhone

极其牛屄
作者: Kuzuryuusen    时间: 2013-11-1 13:18

posted by wap
引用:
原帖由 @ashbringer_k  于 2013-11-1 13:09 发表
我猜猜 第二章的内容是不是:  ECU如上文出现问题导致节气门不受控制,汽车停不下来的话,在编写ECU时 如果有底层语句“刹车优先”这条命令来兜底

那么爆冲的情况就不会出现,而丰田的ECU里没有刹车优先.......所以汽车刹不住了。
猜错了……远比这精彩。不是卖关子,我的第一感觉是:我和小伙伴们都惊呆了
作者: DDP    时间: 2013-11-1 13:24

我靠太专业了
作者: allspace    时间: 2013-11-1 13:27

坐等雾桑来说我的卡罗拉,一点儿毛病都没有~

:D :D :D :D :D :D

































开玩笑哈:D
作者: 不知所谓无所谓    时间: 2013-11-1 13:28

posted by wap, platform: Chrome

接着贴啊,快!
作者: Tusk    时间: 2013-11-1 13:55

等第二部分。。。
作者: Kuzuryuusen    时间: 2013-11-1 14:20

posted by wap

更新了一点点第二部分。还在继续写。估计明天或者后天再更新了
作者: hpkiller    时间: 2013-11-1 14:26

太好看了。
作者: 睡睡平安    时间: 2013-11-1 14:36

posted by wap, platform: Chrome

这么说还是德国人严谨了?
作者: 雾桑    时间: 2013-11-1 14:41

引用:
原帖由 allspace 于 2013-11-1 13:27 发表
坐等雾桑来说我的卡罗拉,一点儿毛病都没有~

:D :D :D :D :D :D
开玩笑哈:D
只能说,不明觉厉!
作者: Seiker    时间: 2013-11-1 14:41

记得刚毕业的时候接触过一段时间的对日软件外包 不算很深入
但当时的印象是架构烂 技术老 也不给创意的余地 反正大部分规格书上都帮你定好了
作者: Kuzuryuusen    时间: 2013-11-1 14:44

posted by wap, platform: Nexus S
引用:
原帖由 @睡睡平安  于 2013-11-1 14:36 发表
posted by wap, platform: Chrome

这么说还是德国人严谨了?
这个问题我没有办法准确回答。但是预告一下,第三部分会有部分涉及。只是部分而已,不要抱太大希望。但是保证独家猛料,别无分号 二楼的文件里也照不到:D

是的,这篇文章我会分成三部分。

本帖最后由 Kuzuryuusen 于 2013-11-1 14:52 通过手机版编辑
作者: sensui    时间: 2013-11-1 14:54

引用:
原帖由 Seiker 于 2013-11-1 14:41 发表
记得刚毕业的时候接触过一段时间的对日软件外包 不算很深入
但当时的印象是架构烂 技术老 也不给创意的余地 反正大部分规格书上都帮你定好了
这对可靠性来说又不是缺点。
作者: 大尾巴兔    时间: 2013-11-1 14:57

posted by wap, platform: iPad

楼主相当牛逼。

日本人的软件开发确实比较烂,架构技术都很落后。游戏行业也是一个样。
作者: ccccpppp    时间: 2013-11-1 14:59

我想知道 有没有比较 对于其他厂商
作者: wanghe2kk4    时间: 2013-11-1 15:19

坐等更新
作者: 朱爷吉祥    时间: 2013-11-1 15:22

真棒!一流的内容!必须加祭扫!任天堂必须死!
作者: 朱爷吉祥    时间: 2013-11-1 15:26

早些年,还听过不少论坛上在为日游戏企业写代码的朋友说起,日本人的代码可读性极差,也大多不和规范,一团棉絮似的就编译了,程序员还很牛逼。

欧美甚至印度的代码都很规范,所以老美有各种“引擎”,日本则完全没有。。。。

总之本文揭示了任天堂必须死的深层次原因!
作者: survivorcn    时间: 2013-11-1 16:08

马克等续集
作者: makero    时间: 2013-11-1 16:10

mark等更新
作者: 北    时间: 2013-11-1 17:02

如果是原创,lz这文就发到了tg车区? 赶快去 xcar 车托之家转发

另外好奇lz本职是搞什么的,这么有时间有闲有兴趣挖掘很久之前发生的事



刚才下了2楼的文档,还以为是一大堆技术性文章,居然是庭审记录,不错,准备周末有时间看看

[ 本帖最后由 北 于 2013-11-1 19:15 编辑 ]
作者: 北    时间: 2013-11-1 17:16

另外LZ有没有Hi-PDA账号,能不能转发到D版,那里电工居多,很有兴趣讨论这类事情
作者: 朱爷吉祥    时间: 2013-11-1 17:23

赶紧啊lz,等着看呢
作者: Seiker    时间: 2013-11-1 17:28

引用:
原帖由 sensui 于 2013-11-1 14:54 发表


这对可靠性来说又不是缺点。
结果就是出现主楼说的那种几十上百个if 代码
可能最早的pm清楚每个分支是干嘛的 但时间一长加人员更迭 出错的可能性不断加大 而且到后来就基本不可维护了
作者: miku    时间: 2013-11-1 17:28

posted by wap, platform: iOS

不得不服,对软件皮毛认识,基本意思明白。但是没有接触过日本的代码。。不评价
作者: ashbringer_k    时间: 2013-11-1 17:50

楼主赶紧更新啊!!

翻了翻纪录发现是集体诉讼,300万美元好像不算多。但是有了判例,丰田可能又要大出血了
作者: marsghost    时间: 2013-11-1 18:08

posted by wap, platform: iPhone

日本搞电子还行 软件么…
作者: 鬼舞者4    时间: 2013-11-1 18:18

我想问,这回丰田载了?载了吗?
作者: toshiya115    时间: 2013-11-1 18:53

围观强帖

作者: zo    时间: 2013-11-1 19:13

年度精华!!!
作者: ashbringer_k    时间: 2013-11-1 20:07

楼主这个太吊胃口  14号的事情  按道理在美国应该炸了锅啊
作者: 小黑狗    时间: 2013-11-1 20:33

作为在安全相关行业混饭吃的程序员,实在是对丰田这种敢在safety critical的代码中使用递归算法,不对变量进行保护的行为无比敬仰…… :D
作者: 锁心    时间: 2013-11-1 21:14

牛逼极了,今天没祭扫了,一定回来补。
作者: pspgo    时间: 2013-11-1 21:39

不会吧,实在没想到这软件当初怎么写的啊,现在能怎么办?全部推倒重写?
作者: wanghujin    时间: 2013-11-1 21:48

posted by wap, platform: iPhone

马克
作者: shixn    时间: 2013-11-1 22:42

posted by wap, platform: iPhone

说明软件评测行业前景大好,相关业务合作请pm...
作者: 朱爷吉祥    时间: 2013-11-1 22:43

我一晚上刷好几遍了,期盼后续啊
作者: woodd    时间: 2013-11-1 22:45

楼主发错地方了
作者: maghana    时间: 2013-11-1 22:49

不明觉厉
作者: 性博士    时间: 2013-11-1 23:07

posted by wap, platform: SonyEricsson (Xperia Play)

function翻译成方程了?为什么那么多方程?
作者: carmark    时间: 2013-11-1 23:18

引用:
原帖由 性博士 于 2013-11-1 23:07 发表
posted by wap, platform: SonyEricsson (Xperia Play)

function翻译成方程了?为什么那么多方程?
是啊,楼主要是能一些术语用原文或者改成大陆同行叫法就好了
作者: 四轮驱动    时间: 2013-11-2 07:05

posted by wap, platform: GALAXY NOTE II

看完此贴,我突然对路虎有了好感。
作者: godmaycry    时间: 2013-11-2 08:58

posted by wap, platform: iOS

靠,我的车就是丰田,我可以去告它了吗?
作者: Kuzuryuusen    时间: 2013-11-2 09:32

posted by wap
引用:
原帖由 @carmark  于 2013-11-1 23:18 发表
是啊,楼主要是能一些术语用原文或者改成大陆同行叫法就好了
好的。。。
又更新了一点,并且对之前的内容作出了一些修改。以后还会继续修改,所以等完全更新完了值得从头到尾再读一遍。
作者: zo    时间: 2013-11-2 09:46

大片,能拍电影吗?
作者: 大尾巴兔    时间: 2013-11-2 10:10

posted by wap, platform: iPad

电子化设备越来越多,要可靠软件还是得买美系,德系!
作者: 朱爷吉祥    时间: 2013-11-2 10:45

posted by wap, platform: iOS

真精彩!
作者: ddaaii    时间: 2013-11-2 11:05

posted by wap, platform: iPhone

牛逼文!收藏了!
作者: 武松    时间: 2013-11-2 11:19

等待lz更新。
作者: Kuzuryuusen    时间: 2013-11-2 12:43

posted by wap

第二部分完。各位慢慢剔牙,我去准备甜点,预计周一前能上。麻痹周末忙晕了还码字
作者: ashbringer_k    时间: 2013-11-2 12:54

楼主抓紧啊  到目前为止 还没有上大菜啊!都是网上能找到的,第一手消息呢  敲碗等更新啊!!
作者: Kuzuryuusen    时间: 2013-11-2 12:59

posted by wap
引用:
原帖由 @ashbringer_k  于 2013-11-2 12:54 发表
楼主抓紧啊  到目前为止 还没有上大菜啊!都是网上能找到的,第一手消息呢  敲碗等更新啊!!
表这样,我已经尽力了。后面真的只是甜点而已了
作者: GavinLuo    时间: 2013-11-2 13:07

看完这个觉得上次浙江杰路驰飞奔两小时的事情,有部分能解释了
作者: ashbringer_k    时间: 2013-11-2 13:13

引用:
原帖由 Kuzuryuusen 于 2013-11-2 12:59 发表
posted by wap

表这样,我已经尽力了。后面真的只是甜点而已了
楼主能挖到判决书么?想看看州法庭到底怎么判的
作者: ashbringer_k    时间: 2013-11-2 13:16

引用:
原帖由 GavinLuo 于 2013-11-2 13:07 发表
看完这个觉得上次浙江杰路驰飞奔两小时的事情,有部分能解释了
还不太一样
作者: 性博士    时间: 2013-11-2 13:32

posted by wap, platform: SonyEricsson (Xperia Play)

可算软件安全领域的经典案例了,精彩程度和那个x光透视仪杀人的案例差不多。看完全文感觉丰田的嵌软水平相当于大学毕业2年的毕业生
作者: zhuliang    时间: 2013-11-2 15:10

日本人的代码水平,真实体现了日企的现状,各种保守迂腐派当道,只要是前辈的东西都是用来膜拜的,容不得任何置疑.
作者: zhuliang    时间: 2013-11-2 15:14

真心觉得日本人只适合做那种技术发展到头只需要少量完善的东西,只要是做这种技术频繁更新的东西迟早要玩脱.
作者: goddest    时间: 2013-11-2 19:55

posted by wap, platform: 海信 (EG950)

静待更新
作者: 性博士    时间: 2013-11-2 20:13

posted by wap, platform: Windows

估计佳美的代码沿用了很多年了,构架大改是不可能了,只要架构还是那么烂,基本上新佳美的稳定性还是一个鸟样。不过架构重写的话,开发成本应该会很高。
作者: miku    时间: 2013-11-2 20:50

posted by wap, platform: iOS

求问下,丰田帕拉达是不是也有这个问题?
作者: mting    时间: 2013-11-2 21:10

机械方面不懂
但是os芯片选择了一个没通过行业安全标准的供应商
这个真的很不可思议
作者: deadpuppet    时间: 2013-11-2 21:21

posted by wap, platform: iPhone

汽车行业码畜表示楼主说都软件编程相关全都看懂了,但整篇文章仍然没懂
对于一个函数好几千行以及使用了递归等等,笑而不语,不一定是外包干的,日本本土也有渣程序员
现在做德国项目,其实质量真心不如日本的好…
作者: Kuzuryuusen    时间: 2013-11-2 21:27

posted by wap, platform: Firefox
引用:
原帖由 @deadpuppet  于 2013-11-2 21:21 发表
posted by wap, platform: iPhone

汽车行业码畜表示楼主说都软件编程相关全都看懂了,但整篇文章仍然没懂
对于一个函数好几千行以及使用了递归等等,笑而不语,不一定是外包干的,日本本土也有渣程序员
现在做德国项目,其实质量真心不如日本的好…
纯属外行,哪儿写得不对望业内斧正啊
作者: ashbringer_k    时间: 2013-11-2 21:29

我放狗水平差  谁能搜搜到底这300万刀是怎么判的  丰田这回彻底栽了 还是挨一棒子 真要看这判决内容
作者: Kuzuryuusen    时间: 2013-11-2 21:37

posted by wap, platform: Firefox
引用:
原帖由 @ashbringer_k  于 2013-11-2 21:29 发表
我放狗水平差  谁能搜搜到底这300万刀是怎么判的  丰田这回彻底栽了 还是挨一棒子 真要看这判决内容
就是法庭判丰田承担责任(Liable),丰田马上同意给钱息事宁人。
300万不能说多,意义在于开先例。可以想象那些职业状棍们一定觉得捞到金猪了,都摩拳擦掌等着捞一笔呢。预计丰田要倒霉……
作者: 性博士    时间: 2013-11-2 22:07

posted by wap, platform: Windows

据说是ECM的图片,大家欣赏一下

调查发现这套系统没有采用具备侦错修正功能(EDAC)的主内存(丰田之前宣称采用了这类硬件),这点丰田必须死了

本帖最后由 性博士 于 2013-11-2 22:10 通过手机版编辑
作者: deadpuppet    时间: 2013-11-2 22:43

引用:
原帖由 Kuzuryuusen 于 2013-11-2 21:27 发表
posted by wap, platform: Firefox

纯属外行,哪儿写得不对望业内斧正啊
我就是觉得Barr的调查思路很奇葩啊:
1、设计业余。一个函数超过1300行代码怎么了,超过7k行的函数我都见过。这就一定出现Bug么?全局变量多也一定会产生Bug么?当然我也很讨厌这种设计,但不能说明他有Bug,如果想证明的话,需要找出实质证据。
2、代码不符合编码规范。我又惊了,这在业内太正常了吧?估计是使用了PC-LINT或是什么工具检查了一下编码规范就蹦上来,说这会产生Bug。
递归就一定产生Bug么(递归我还真就用过一回,在后续的派生项目里还真就出现内存分配不足死机的bug)
有的程序员会这么写
malloc();
while(1){
//bulabula
break;
}
free();
如果想证明不符合编码规范,请找出证据
3、变量保护其实也是编码规范的一种,同上。

然后Barr为了证明这些代码的确有问题,使用了单元测试的方法
人为地改变了内存中的一个地址的值,于是出Bug了
那么,这个Case在实际情况中真的会发生么?

正常的路子应该是先根据用户提供的现象以及操作步骤去尝试再现这处Bug,(或者还有Log等),再结合代码,逆向分析出这个Bug的原因。
或者我就单纯分析代码,分析出至少一条能够导致出现这个Bug现象的Case,然后去再现它。
还人为地翻转一个特定字节,你怎么不去把用于通信的线缆都剪折了然后再测测?也能出Bug,出不了Bug你再把刹车拆了
难道陪审团里没有懂编程的?

最后照例乱喷一通:MBD现在经常新员工直接上(包括日本人与德国人),各种奇葩代码层出不穷,我艹。
至于前面有人提到的德国人的严谨,我更是懒得喷,能有多严谨,stop的时候不释放内存,原来是架构里根本就不支持(贼tm长见识)
PS:另外DTC模块的代码我也写过一小部分,头回知道DTC全称,寒自己一个
作者: deadpuppet    时间: 2013-11-2 22:45

引用:
原帖由 Kuzuryuusen 于 2013-11-2 21:37 发表
posted by wap, platform: Firefox

就是法庭判丰田承担责任(Liable),丰田马上同意给钱息事宁人。
300万不能说多,意义在于开先例。可以想象那些职业状棍们一定觉得捞到金猪了,都摩拳擦掌等着捞一笔呢。预计丰田 ...
的确啊
以后随便找辆车,不停地改写系统里内存的值,直至出错
然后又能拿到300W了
作者: ashbringer_k    时间: 2013-11-2 23:14

很多人可能不太明白这个判例有多重要的意义  我帮楼主说说吧  顺便结合目前知道的情况 随便聊聊

       多年前的丰田刹车门,可能大家都知道或者有所耳闻。由内部爆料开始,指出丰田可能蓄意隐瞒了自身车辆的缺陷,造成一定数量的交通事故

和大量的人员财产损失。事故一般为刹车失灵,驾驶员踩下刹车无法减速车辆。受到调查的事故上千起。

       当时的情况实际上很戏剧性:由美国土运输部牵头的一堆部门联手开始对丰田进行调查,丰田章男自己都懵了,因为丰田可能根本就不清楚这些车为什么刹不住,

当时花了很长的时间去找原因,但是依然没有合理的解释,最后只能以刹车踏板不合理,脚垫卡阻等原因来告知消费者,并实施召回,并交纳6000万的罚款。同时承诺

安装“刹车优先”。等于是在最终调查结果还没出来的时候,先低头认错。国内当时说的凯美瑞刹不住实际上还不是这一码事儿,是另外的事情。

没想到的是,丰田认错了,赔钱又召回的情况下,调查委员会发现,上千起事件基本上都是人为的错误。包括那几起著名的,甚至调查方都发现了与证言不符的情况,

例如宣称刹车失灵的汽车,结果发现撞击时根本没有踩刹车。或者现场找到了明显的刹车痕迹。同时认为丰田的电控油门系统和刹车系统是相互独立的,即使没有“刹车是爷”系统,

汽车也能刹住。
   
    好了,既然刹车系统没问题,那人们的注意力就转到了所谓的电控油门系统上了,实际上就是ECU。因为如果ECU没有问题,不会犯错误,那么丰田就没有任何问题了。当时

]委托了NASA对ECU以及车辆本身进行了10个月的调查,通过各种手段试图重现刹车失灵的问题,但最终的结果是没有问题。紧接着调查委员会就给丰田翻案了,认为丰田没有过错。

同时阴谋论又开始了,认为是奥黑政府为了解救通用和福特出此手段。但我认为此为瞎扯,奥黑巴不得通用、福特破产重组,然后告诉公会,要福利还是要工作,自己选吧。

虽然翻案了,但是丰田还是答应赔偿11亿美元,同时对外宣称,虽然调查结果表示我们的系统没有问题,但我们认为还是给消费者带来了困扰。而这11亿主要是支付官司钱,安装刹车是爷

车辆残值损失,消费者服务 公益事业之类。说白了就是丰田再掏11亿跪舔北美消费者。翻案这事儿,国内知道的好像并不太多。

     那么回到这个案子,说实话我在EE上翻到一篇文章,说的这事儿,口气倒像是个科普文章,作者还是个叫吉田润子的日本人。另外在CNN的财经频道也翻到这个内容,但好像

关注度不太高。我觉得与这个案子的意义太不相符了,因为如果这个案子判实了,那会是爆炸性的消息。而看丰田的股价基本没有什么波动.......所以本案的判决太重要了,到底判的是什么?

如果此案认定ECU确实是车辆刹车失控的罪魁祸首,那么意味着推翻了之前的调查,在以判例为准的美国,丰田很可能就要完蛋艹了,只能靠在本土卖卖AQUA苟活了。

    简单分析一下:1)凯美瑞的 ECU十有八九应该是denso的东西,实际上丰田不会对ECU再进行大量的编译,也就是说,本案里说的事情,很大程度上也应该是电装的问题,那可就不是

丰田一家的事情了。2) 这是个集体诉讼,从下载的文件上看,有不少人,但最终从现在能查到的情况下看,庭外调解的300万实际上也只是给两个人各150万,其中一个应该是造成1死1伤的那个事故,

150万作为赔偿是否有些低? 3)NASA这10个月干什么去了?没有理由看不出来ECU的编译根本没有遵守MISRA C以及ISO8系的规范。

    先说这么多,坐等楼主的甜点了。



[ 本帖最后由 ashbringer_k 于 2013-11-2 23:22 编辑 ]
作者: 性博士    时间: 2013-11-3 00:11

posted by wap, platform: Android
引用:
原帖由 @deadpuppet  于 2013-11-2 22:43 发表
我就是觉得Barr的调查思路很奇葩啊:
1、设计业余。一个函数超过1300行代码怎么了,超过7k行的函数我都见过。这就一定出现Bug么?全局变量多也一定会产生Bug么?当然我也很讨厌这种设计,但不能说明他有Bug,如果想证明的话,需要找出实质证据。
2、代码不符合编码规范。我又惊了,这在业内太正常了吧?估计是使用了PCLINT或是什么工具检查了一下编码规范就蹦上来,说这会产生Bug。
递归就一定产生Bug么(递归我还真就用过一回,在后续的派生项目里还真就出现内存分配不足死机的bug)
有的程序员会这么写
malloc();
while(1){
//bulabula
break;
}
free();
如果想证明不符合编码规范,请找出证据
3、变量保护其实也是编码规范的一种,同上。

然后Barr为了证明这些代码的确有问题,使用了单元测试的方法
人为地改变了内存中的一个地址的值,于是出Bug了
那么,这个Case在实际情况中真的会发生么?

正常的路子应该是先根据用户提供的现象以及操作步骤去尝试再现这处Bug,(或者还有Log等),再结合代码,逆向分析出这个Bug的原因。
或者我就单纯分析代码,分析出至少一条能够导致出现这个Bug现象的Case,然后去再现它。
还人为地翻转一个特定字节,你怎么不去把用于通信的线缆都剪折了然后再测测?也能出Bug,出不了Bug你再把刹车拆了
难道陪审团里没有懂编程的?

最后照例乱喷一通:MBD现在经常新员工直接上(包括日本人与德国人),各种奇葩代码层出不穷,我艹。
至于前面有人提到的德国人的严谨,我更是懒得喷,能有多严谨,stop的时候不释放内存,原来是架构里根本就不支持(贼tm长见识)
PS:另外DTC模块的代码我也写过一小部分,头回知道DTC全称,寒自己一个
一个函数1300多行不能说明一定有bug,但哪个奇葩公司会在自己的编程规范里规定一个函数最大可以写1400行?要么是电装根本没编程规范,要么是码农没遵循规范。两种都是不靠谱行为。

misra c检查不过同理。就是tg数码区看不起的中兴,cdma基站的代码都是要求跑pclint全过,而且是check in时强制检查。给我们公司培训的前zte工程师亲口说的。

barr检查了代码发现位翻转会导致任务挂掉,注入一个位翻转错误结果验证了想法,这个不该喷吧。第一证明了出现问题的可能性,位翻转可能会导致任务挂掉。再说位翻转本来就是容易出现的现象,如果很少见ecc内存卖谁去?况且ecu工作环境本来就脏乱差。第二说明电装的测试范例覆盖不全,根本没考虑到位翻转的情况。假设电装的测试工程师做黑盒,模拟一个位翻转结果挂了,这就是一个必须修复的严重等级的bug。事实是这个bug根本没被测出来过。

一些罕见的错误确实会导致严重后果,还是上面说的那位培训师,他说光通信出现误码的概率很低,10的负好多次方。由于通信量很大,短期内就发生一些奇怪的问题。后来他们注入错误,生成各种错帧,把解帧引擎的错误排查干净了,就很少出问题了。
作者: Kuzuryuusen    时间: 2013-11-3 05:39

posted by wap
引用:
原帖由 @deadpuppet  于 2013-11-2 22:43 发表
我就是觉得Barr的调查思路很奇葩啊:
1、设计业余。一个函数超过1300行代码怎么了,超过7k行的函数我都见过。这就一定出现Bug么?全局变量多也一定会产生Bug么?当然我也很讨厌这种设计,但不能说明他有Bug,如果想证明的话,需要找出实质证据。
2、代码不符合编码规范。我又惊了,这在业内太正常了吧?估计是使用了PCLINT或是什么工具检查了一下编码规范就蹦上来,说这会产生Bug。
递归就一定产生Bug么(递归我还真就用过一回,在后续的派生项目里还真就出现内存分配不足死机的bug)
有的程序员会这么写
malloc();
while(1){
//bulabula
break;
}
free();
如果想证明不符合编码规范,请找出证据
3、变量保护其实也是编码规范的一种,同上。

然后Barr为了证明这些代码的确有问题,使用了单元测试的方法
人为地改变了内存中的一个地址的值,于是出Bug了
那么,这个Case在实际情况中真的会发生么?

正常的路子应该是先根据用户提供的现象以及操作步骤去尝试再现这处Bug,(或者还有Log等),再结合代码,逆向分析出这个Bug的原因。
或者我就单纯分析代码,分析出至少一条能够导致出现这个Bug现象的Case,然后去再现它。
还人为地翻转一个特定字节,你怎么不去把用于通信的线缆都剪折了然后再测测?也能出Bug,出不了Bug你再把刹车拆了
难道陪审团里没有懂编程的?

最后照例乱喷一通:MBD现在经常新员工直接上(包括日本人与德国人),各种奇葩代码层出不穷,我艹。
至于前面有人提到的德国人的严谨,我更是懒得喷,能有多严谨,stop的时候不释放内存,原来是架构里根本就不支持(贼tm长见识)
PS:另外DTC模块的代码我也写过一小部分,头回知道DTC全称,寒自己一个
呃,解释一下,关于那条链子,我从左往右写是为了文章逻辑结构的需要,并且更易理解。但Barr在调查的时候却是从右往左的。证词提到他们确实从最终结果开始反溯:暴冲>节气门不正常打开>节气门变量停止更新>Task X死亡>操作系统任务调配异常...>找到那个特定的比特。测试的时候再验证这链条从左往右走得通。证词本身的倒是乱序排列。
我觉得最触目惊心的是那一层层防护竟然都形同虚设,真是故意这么设计都难做到啊……
作者: ChuPaChuPs    时间: 2013-11-3 06:39

300万的settlement对toyota来说是很小的case了,赶紧settle down完事
越调查下去越麻烦,没有一个大的程序是经得起这种分析的
作者: Kuzuryuusen    时间: 2013-11-3 07:03

posted by wap

第三部分更新完毕,全文完,纠察错别字锐意禁区中
作者: Kuzuryuusen    时间: 2013-11-3 07:07

posted by wap
引用:
原帖由 @北  于 2013-11-1 17:02 发表
如果是原创,lz这文就发到了tg车区? 赶快去 xcar 车托之家转发

另外好奇lz本职是搞什么的,这么有时间有闲有兴趣挖掘很久之前发生的事



刚才下了2楼的文档,还以为是一大堆技术性文章,居然是庭审记录,不错,准备周末有时间看看

我没帐号(或者都是死帐号),随便转载,注明出处就行(球巫毒发工资)。
转载了记得过来贴一下链接,我好围观:D
作者: himura    时间: 2013-11-3 07:24

真的假的???

例如这个


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

posted by wap, platform: iPad

长文贡献
作者: kdscw    时间: 2013-11-3 08:11

引用:
原帖由 himura 于 2013-11-3 07:24 发表
真的假的???

例如这个


我:这么看来似乎手动档汽车更安全,你怎么认为?
Barr:很多专家都这么认为,离合器至少可以物理断开动力系统。但是我翻阅卷宗,发现其中有个案例是受害者开手动档凯美瑞载着家人,突 ...
只要是丰田,一切皆有可能。:D
作者: 我爱一条柴啊    时间: 2013-11-3 10:31

posted by wap, platform: Nexus 7

马克斯密达
作者: joinway    时间: 2013-11-3 10:48

引用:
原帖由 himura 于 2013-11-3 07:24 发表
真的假的???

例如这个


我:这么看来似乎手动档汽车更安全,你怎么认为?
Barr:很多专家都这么认为,离合器至少可以物理断开动力系统。但是我翻阅卷宗,发现其中有个案例是受害者开手动档凯美瑞载着家人,突 ...
这个只能说断开引擎牵引后,车辆操控失常导致,是人的问题,但只要操控没问题,还是安全过自动挡,手动唯一的问题就是累了一天,上路堵车还得来回换挡。
作者: Kuzuryuusen    时间: 2013-11-3 10:58

posted by wap, platform: Nexus S

陆续补充一些好玩的东西,不适合放在正文里,就回帖吧。想到什么写什么。
Barr举例说明什么叫代码。他的例子是一个比较函数,比较两个参数数值大小,返回大的参数。比如输入11和10输出11。
辩护律师:如果给这个函数输入两个10,返回什么?
Barr:10
辩护律师:10是不是比10大?
Barr:不是
辩护律师:那么这是不是bug?
Bar:不是Bug。(blablabla五分钟)……总之这不是Bug。
辩护律师:不是Bug。不是Bug。(他说了两遍……)下一页……


作者: xmm    时间: 2013-11-3 11:19

我倒是问过一个与车企斗争了三十多年的职业状棍同样的问题,他开宝马。
作者: rrrocq    时间: 2013-11-3 11:26

就是说没有任何电子辅助设备的纯机械手动挡的车才是最安全的
我的理解有没有错误?   :D
作者: pspgo    时间: 2013-11-3 11:41

posted by wap, platform: GALAXY NOTE II

看完了。结论是最后一句:宝马,大师的选择,讼棍的选择!
作者: zhuliang    时间: 2013-11-3 12:13

引用:
原帖由 rrrocq 于 2013-11-3 11:26 发表
就是说没有任何电子辅助设备的纯机械手动挡的车才是最安全的
我的理解有没有错误?   :D
纯机械?停路边分分钟被人搭线开走的节奏.
作者: ashbringer_k    时间: 2013-11-3 12:23

1) 这事儿电装的码农肯定跑不了了  

2) 丰田的原本装作慈善的11亿估计要掏的心甘情愿了

3) 最后法院看来也不是判的ECU的问题,因为有刹车痕迹,就说明那次一死一伤实际上和这位大学老师说的事儿没关系。
作者: Kuzuryuusen    时间: 2013-11-3 13:26

posted by wap

继续好玩的东西。

辩护律师:你昨儿说在这个项目上投入了“无数”小时?
Barr:是的。
辩护律师:有没有估算过大致多少小时?
Barr:没有。
辩护律师:几百小时?
Barr:大概有上千小时。
辩护律师:两三千小时?
Barr:我不确定。
辩护律师:我知道你的收费是每小时400美元,对不对?(你丫到底收了多少钱?)
Barr:我认为不对。
辩护律师:什么才是对的?
Barr:我现在的收费标准是每小时525美元。
辩护律师:……对不起我并不是要低估你……
作者: 已婚群众    时间: 2013-11-3 13:35

对不起我并不是要低估你
喷了
作者: Kuzuryuusen    时间: 2013-11-3 14:00

posted by wap

继续。

诉讼律师:我听说你上面的证词里面有几个词儿被丰田定义为机密,禁止让公众听到?
Barr:是的。你也可以看看我的报告。每次我说██████的时候就被涂黑了,说███的时候也是,还有██████████████████████████████也要涂黑。

囧。
作者: toshiya115    时间: 2013-11-3 14:02

posted by wap, platform: GALAXY NOTE II (CDMA)

楼上喷了
作者: 李鬼    时间: 2013-11-3 15:03

1w多全局变量有点匪夷所思, 一共才多少行代码啊
作者: stevecai    时间: 2013-11-4 09:30

这么说,大家赶紧退车!!!!




欢迎光临 TGFC Lifestyle (http://club.tgfcer.com/) Powered by Discuz! 6.0.0