丰田汽车意外加速事件与那大碗”意大利面”代码
“实际操作中，五到十个尚可接受。但一万个？不行，这已构成安全隐患。我无需逐个审查这万个全局变量，仅凭数量便知问题所在。”
上月，丰田在俄克拉荷马州陪审团裁定该车企存在“鲁莽漠视”行为并判处原告300万美元赔偿后数小时内，仓促达成意外加速诉讼和解——此时陪审团尚未裁定惩罚性赔偿金额。
陪审团究竟听到了哪些构成丰田严重失职的证据？两位原告方软件设计与开发流程专家的证词提供了令人震惊的线索。在审查丰田软件工程流程及2005款凯美瑞源代码后，两人均认定该系统存在缺陷且危险——其故障安全机制布满漏洞与缺陷，正是导致事故的根本原因。
布克特与施瓦茨诉丰田案源于2007年9月一起导致死亡事故的UA事件。当时珍·布克特驾驶2005款凯美瑞载着乘客芭芭拉·施瓦茨驶离俄克拉荷马州69号州际公路，突然失去油门控制。当服务制动无法阻止失控轿车时，她紧急拉起驻车制动，导致右后轮留下150英尺(约45米)的刹痕，左后轮留下25英尺(约7.6米)刹痕。然而凯美瑞仍持续高速冲下匝道，横穿底部的道路后撞上路堤。施瓦茨因伤势过重死亡；布克特则因头部和背部重伤住院治疗五个月。
原告方律师、比斯利·艾伦律师事务所的格雷厄姆·埃斯代尔坦言，布克案判决结果在某种程度上取决于匝道上那两道黑色刹车痕迹。
“丰田根本无法解释这些痕迹，”埃斯代尔指出，“刹车痕迹证明她确实采取了制动措施。”
尽管庭审证词充斥技术性讨论，陪审团始终高度专注。得知案件已达成和解后，陪审员们主动询问帕特里夏·帕里什法官能否留下来讨论审判过程。最终由十二名陪审员、帕里什法官及原告律师展开了讨论。埃斯代尔表示，从对话中不难看出陪审团当时已准备好对丰田的行为及掩盖真相的行为予以惩罚。
尽管存在刹车痕迹，原告方两位软件专家菲利普·库普曼和迈克尔·巴尔仍揭示了丰田软件开发流程及源代码的诸多隐患——潜在的位翻转、可能导致安全装置失效的任务终止、内存损坏、单点故障、栈溢出与缓冲区溢出防护不足、单故障隔离区、数千个全局变量。流程与产品缺陷清单冗长。
迈克尔·巴尔作为备受尊敬的嵌入式软件专家，耗时逾20个月在酒店般宽敞的房间内五个隔间之一审查丰田源代码。期间安保人员全程监督，确保进出人员不得携带纸张，且禁止佩戴腰带或手表。巴尔基于其800页报告，详细阐述了丰田源代码的具体缺陷。卡内基梅隆大学计算机工程教授菲利普·库普曼是安全关键型嵌入式系统专家，著有教材《更优嵌入式系统软件》，并为私营企业(包括汽车行业)提供嵌入式软件设计评审服务。他针对丰田的工程安全流程作证时，与巴尔均使用程序员蔑称术语描述所见代码：意指结构混乱、编写拙劣的“意大利面条式代码”。
巴尔作证称：
大量函数存在过度复杂的问题。按行业标准衡量，其中部分函数根本无法测试——其逻辑配方过于繁琐，导致无法开发出可靠的测试套件或测试方法来验证所有可能发生的状况。部分函数甚至复杂到被称为’不可维护’——这意味着修复漏洞或修改代码时，极可能在过程中引入新缺陷。即便车辆搭载最新固件版本(即嵌入式软件)，也未必比旧版更安全……最终结论是：安全防护措施存在缺陷。现有安全防护机制存在缺陷或漏洞。但整体而言，安全架构如同纸牌屋般脆弱。当油门控制失效时，大量安全防护措施可能同时失效。
就连丰田程序员也在2007年10月的文件中将发动机控制程序描述为“意面般的混乱”，巴尔在证词中援引了这份文件。
库普曼对丰田的计算机工程流程提出了严厉批评。1995年，汽车工业软件可靠性协会(MISRA)首次制定了行业编码标准——尽管是自愿性质的。这些规则配套的行业指标将违规行为与软件缺陷数量挂钩：平均每违反30条规则，就会产生3个次要缺陷和1个重大缺陷。他表示，丰田拒绝遵循这些标准是致命错误。
2010年美国国家公路交通安全管理局委托NASA软件工程师评估丰田部分源代码时，他们对照MISRA-C规则检查了可访问的丰田源代码，发现存在7,134处违规。巴尔参照MISRA 2004版标准复核源代码时，竟发现81,514处违规。
丰田采用的自有流程与行业标准几乎毫无交集。即便如此，其程序员仍频繁违反内部规则，且未能按行业惯例充分记录违规情况及合理依据。库普曼作证称，若安全要素未在产品开发流程中融入核心设计，后期便无法补救。
“开发安全关键型软件必须极其谨慎，绝不能临时抱佛脚。丰田虽有所重视，但其安全系统设计仍未达到行业公认的实践标准。”他强调。
丰田违反的核心安全标准之一是允许系统存在单点故障(即某硬件或软件完全掌控系统安全状态，如单引擎飞机)。库普曼强调：
“根据我所知悉的所有安全标准，单点故障本身就意味着不安全。无论采取多少防护措施或安全装置都无法根治——最多只能降低故障概率。但面对数百万辆在用车辆，系统终将以你未曾预料的方式发生故障。”
系统中全局变量的数量同样严重偏离行业标准。(变量是存储器中存放数值的位置，全局变量指系统任何软件都能读取或写入该数值的存储单元。)学术界标准要求全局变量数量为零，而丰田系统却存在超过10,000个全局变量。
“实际操作中，五到十个尚可接受。但一万个？不行，这已构成安全隐患。我无需逐个审查这万个全局变量，仅凭数量便知问题所在。”库普曼在听证会上如此作证。
巴尔和库普曼还指出其他关键设计流程缺陷：缺乏同行代码审查机制，以及丰田未能核查电装公司提供的第二套CPU源代码——尽管高管们向国会和NHTSA保证UA故障绝不可能源于发动机软件。
巴尔在证词中阐述了CPU内任务终止引发的车辆行为故障，并断言布克特车辆异常行为极可能由某项被隐去名称的任务(庭审中称为任务X)终止所致。巴尔将其称为“万能任务”，因其掌控着车辆多项功能：包括油门控制、巡航控制(启停功能及恒速行驶)以及主CPU上的众多安全保护机制。
他对丰田看门狗程序(用于检测任务终止的软件)的设计提出质疑。他作证称该程序“根本无法检测关键任务终止——这本是其核心职责，却未能履行，设计之初就存在缺陷”。
相反，丰田的设计意图是监控CPU过载，而巴尔指出：“它连这项基本功能都未能正确实现。CPU过载是指在短时间内任务负荷过重，若持续时间过长，车辆将面临安全风险——因未获得CPU资源的任务如同暂时性死亡。”
巴尔还指出，丰田的软件会丢弃操作系统的错误代码，忽略那些标识任务故障的代码。庭审中巴尔表示：
任务终止虽主要集中在任务X(因其承担节气门控制和故障安全等关键功能)，但实际存在[被删节]个任务，它们可能以不同组合形式终止。可能是任务3与任务X，或任务3、任务7与任务X，甚至仅任务9。这些组合都可能引发不可预测的车辆异常行为。事实证明，当车辆故障时，意外加速正是最危险的表现形式。
即便你认为他们的结论不过是收了钱的专家证词，库普曼和巴尔关于软件错误可能是UA根本原因的评估仍能解释诸多现象：为何丰田系统失效却不留痕迹； 为何新款丰田车仍频现UA故障，为何召回脚垫和踏板也未能根治；为何丰田能长期隐瞒部分UA事件的根本原因。
他们对丰田软件惊人复杂性的描述，同样解释了为何美国国家公路交通安全管理局(NHTSA)采取了当前应对措施，以及为何美国国家航空航天局(NASA)始终未能发现可关联丰田发动机突然全油门加速、无视驾驶员制动指令且不触发故障诊断代码的缺陷。巴尔指出，NASA工程师受限于时间，且无法获取全部源代码。他们依赖丰田的陈述——而某些情况下，丰田误导了NASA。例如NASA曾错误认为丰田设计了名为“错误检测与纠错码”(EDAC)的硬件位翻转保护机制。巴尔作证称，2005款凯美瑞并未配备EDAC，但丰田在邮件中向NASA声称其存在。他在庭审中指出：
NASA并不知晓该功能缺失。2005款凯美瑞确实未配备EDAC。因此若发生位翻转，既无硬件机制可检测，若翻转发生在未镜像的关键数值上，软件也无法提供防护。由此可知，存在关键变量可能发生位翻转。
他们的证词解释了为何美国国家公路交通安全管理局(NHTSA)几乎不可能将电子故障归咎于深埋在软件中的问题。在针对丰田车辆异常行为的众多调查中，NHTSA的调查部门(ODI)甚至没有配备任何软件工程师。他们对支撑当今汽车所有安全关键功能的复杂技术缺乏真正的专业知识。这好比ODI工程师用算盘、凿子和石碑进行调查。人们开始理解该机构为何执着地将非预期加速事件归咎于脚垫和老年女性——甚至反复强调这种解释达数倍之多。
即便NHTSA拥有相关专业知识，软件系统的复杂程度也意味着ODI永远没有足够时间和预算评估汽车制造商的源代码。这正是我们不断强调NHTSA必须制定功能安全法规的原因——无论是自主行动还是国会授权。
通常人们认为企业保护商业机密是为了守护珍贵资产，而这种资产往往就是技术本身——企业制造产品的独家配方。但库普曼和巴尔的证词表明，丰田真正想隐藏的并非汽车界的可口可乐配方，而是其灾难制造的秘方。请看2007年9月丰田员工往来的邮件内容：
“巴尔在法庭上宣读道：‘事实上，安全装置这类技术并非丰田工程部门的基因组成部分。’邮件接着写道：’但将其视为丰田及其系统控制行业的主要优势之一，难道不是件好事吗？’我还特别标注了后半段内容：’继续维持现状绝非良策。’”
本文文字及图片出自 TOYOTA UNINTENDED ACCELERATION AND THE BIG BOWL OF “SPAGHETTI” CODE
这简直令人震惊：
以及：
还有：
以及：
数年前该事件初曝光时，鉴于丰田在质量与流程方面的声誉，我曾以为这是美国工业界针对日本竞争对手的猎巫行动。但若证词属实，丰田工程师的行为实属不可饶恕。
> “实际操作中，五次、十次，可以接受。但一万次？不行，必须终止。这不安全，我无需查看全部一万个全局变量就能断定存在问题。”
在旧公司任职时，老板让我审阅一个关键业务应用程序，看看能否改进。它存在严重缺陷，严重阻碍了工作。
我从同事那里拿到源代码(当时从事火箭研发工作，我们都不是专业软件人员，但即便是笨拙的工程师如我，也知道这绝非正确做法)。打开文件夹，映入眼帘的是大量毫无结构可言的文件。啊，有个名为“MAIN”的文件。我点开一看——Visual Basic 6。仅全局变量声明就超过29,000行。程序核心逻辑大量依赖某商业库，该库的设计初衷竟是(令人发指地)让VB6开发像制作电子表格宏一样简单。原始程序员竟在这地狱般的怪物里实现了主程序逻辑，仅逻辑部分就占了约5万行。
我告诉老板：从头编写新程序比理解这个更容易。
有人见过全局变量比这还多的程序吗？
我曾供职于一家市值数十亿美元的零售企业。其核心后台系统(销售追踪、物流调度、订单履约、员工排班等)全用COBOL编写，输入输出均通过临时文件读写——类似管道机制，但为应对任务失败而采用临时文件。真正的问题在于：约3500个COBOL程序和2500个shell脚本竟混杂在同一个目录下。所有可执行文件(无论COBOL还是shell脚本)都采用四位数字命名；除源代码外，没有任何最新文档说明程序功能、运行顺序或依赖关系。更糟的是，每日结算处理耗时12至16小时；一旦出现重大故障，次日结算将立即受影响。办公室里只有一位资深员工(任职15年)能理解整个系统的运作逻辑；当他去世后，情况急转直下(他并非年迈离世，其死因本身就是段传奇故事)。
我在那里仅坚持了6个月便离职加入初创公司，这段经历在许多方面都令人难以承受。我离开后不久，税务部门转向零售业的转型遭遇重大挫折，一场大规模IT系统崩溃导致这家市值数十亿美元的企业最终被拆分出售；数千个岗位受到波及，许多人因此直接或间接失业。
当然这可能属于最极端的案例(仅次于造成人员伤亡)，虽属罕见但确有发生。这家市值数十亿美元的公司，最终因IT系统崩溃而崩溃。技术债务的成本甚至超过了拆分出售的损失…
致祖父母辈：你本不该查看生成的代码，若有修改就该重新生成。某种程度上，这就是问题根源所在。
在Cobol 85中，所有变量均为程序全局变量，并在程序启动时静态分配。Cobol程序导入数十甚至数百个“副本文件”，全局作用域内存在数千变量的情况并不少见。不过这些变量仍通过某种方式实现了命名空间隔离。
我的亲身经历源自某大型主机应用：350万行代码、15,000个程序、数千个作业，运行着企业托管的批处理与交互式绿屏应用，每年创造约5亿美元收入。
致祖父母：你不该查看生成的代码，若有修改应重新生成代码。
生成的代码？你指的是什么？(我对VB6完全不熟悉，主要用C、Python和MATLAB写过不少代码)。况且这些全是手写的(后来在派对上我终于和原作者聊过)。那家伙居然疯狂到手写所有代码，我真心觉得这番折腾让他有点精神失常了。
当然他也可能在撒谎…
“生成的代码？什么意思？(我对VB6完全不熟悉。”
我认为楼主指的是生成的COBOL代码。
听起来你该把这事投稿到DailyWTF了…
虽然数量少得多，但我最近刚处理过类似情况，恰巧看到这篇《华尔街日报》的精彩报道：
https://github.com/ewfelten/Tracking-Report-Card/blob/master…
代码本身就是最好的说明。
这像是自动生成的代码。完全是另一回事。
确实如此。Mozmill是个测试框架。我们看到的文件里装的是自动化测试(我觉得看文件的人应该能看出来吧…)
我当然清楚它的本质。正如我所说，最近刚处理过这类问题——可不是凭空捏造的。
你眼前这段代码堪称难以想象的恐怖。编写自动化测试本有更优雅、更易维护的方式。
看来我们意见相左，尤其关于这部分：
> 难以想象的恐怖
“恐怖”？或许见仁见智(显然如此)。但“难以想象”？绝对不是。即便承认重复代码有碍美观，我也无法想象你遇到的实际问题竟会因这个文件而受阻。任何操作都应能在五分钟内完成——除非使用最简陋的记事本级编辑器(即仅具备文本控件功能)。若你执着于美化代码，重写整个文件也应在五分钟内搞定。
相较于前文提及的那些存在于实际生产环境中的代码类型，这个文件根本不值一提。
若这都算 难以想象的恐怖 ，那你真是天赐的幸运儿。自动生成器甚至还把代码缩进排版得相当漂亮！
这代码完全没问题——虽然冗长，违反DRY原则，且可精简至25行左右(或25行+待检URL数量)，但它清晰可读、逻辑明确、易于理解。
当小型开发者使用干净模块化的可测试代码时，现实企业却在以各种创意方式滥用VB，这种反差令人感慨。这让我深切体会到范式选择的重要性。上份工作中我面对的正是堆积如山的VB(确切说是VBA)代码，同样是一团无结构的混乱。
没错，我接手的几乎所有该死的PHP项目——只要不是框架项目或现有开源项目——都如此。
在日本生活工作过之后，这并不让我意外。那里的软件工程教育相当薄弱，靠资历晋升的管理者往往强行推行过时的决策，拒绝采纳最佳实践。另一个问题是社会地位层面——软件工程师被视为比机械工程师或电气工程师低一等，所以最聪明的孩子都不选计算机专业(不过现在可能有所改变)。
这与他们其他工程部门产出的(我认为质量更高的)成果形成鲜明对比——为何能在汽车制造的其他环节做出合理的工程决策，唯独软件领域失利？
这究竟是日本文化中软件与传统工程的特定差异，还是软件领域固有的问题？既然家长们普遍抱怨职场文化，整辆车的设计难道不该一塌糊涂吗？
我在2000年代中期曾于丰田(日本)从事新车开发工作四年，恰逢此事发生前夕。意外加速问题同样令我困惑，因为根据我的经验，任何安全问题都始终被列为最高优先级。但我确实对软件/固件的了解有限。通常这些被视为部件组成部分，例如装在实体塑料壳体内的发动机控制模块。请记住，量产车上的ECU是由电装(或类似厂商)作为“总成部件”交付给工厂的，成百上千个这样的部件被装配到车上协同工作。在装配线末端，系统和整车会经过各种测试，但这些测试似乎正如有人描述的那样，仅限于“输入/输出”层面。那么，为何软件测试不能做得更好？
我认为问题之一在于：针对软件/固件的测试流程远不如机械部件的测试流程严谨。现有测试主要围绕车辆驾驶及驾驶场景变化展开，且历经数十年演变。而重型软件控制是新兴领域，根据我的经验，其原理常未被充分理解。首席工程师往往来自机械工程背景。加之始终存在数百个待解决问题与有限时间，加之固件的黑箱特性，使得测试开发困难重重。
开发评审会议通常涵盖传动系统、发动机、底盘等多个机械部门，参会者常携带实体原型，问题与解决方案都清晰可辨。整车/零部件的制造测试流程需经受各类机械测试，并实施长期应力测试直至部件断裂。这类测试可通过经验积累逐步掌握。
固件缺陷则截然不同——在我当前创办的消费电子公司经历此事时，我亲身体验了这种黑匣子特性。记得丰田曾分析过一个软件问题：当车辆在50华氏度以下环境静置超过3小时后，若在15度倾斜路段(路边)启动引擎并在15秒内驶入平坦路面，“检查引擎”警示灯就会亮起。尽管我们没有针对此场景的测试，但通过客户投诉得知了这个现象。但解决方式始终是要求供应商(此例中，也可能是丰田工程师)修复该问题，讨论重点多集中在修复时机和可靠性上。我不记得有任何关于全局变量或代码行的讨论。
几年前有朋友收购日本软件初创公司并移居当地协助运营，以下是他们的观察：
晋升完全取决于年龄和工龄，雇佣关系本质上是终身的。员工几乎不可能被解雇，但一旦辞职可能永远找不到新工作(更别提举报违规行为会带来什么好处)。资历至上且不容置疑。企业既强调刻苦工作和长时间加班，也重视忠诚度和面子。
对比你当前的工作环境和方式，想想这种差异会带来怎样的影响。我的朋友们常感挫败——无论如何努力，都无法从下属那里获得反馈或反对意见。部分原因在于他们身为愚昧的外国人，不懂“读懂空气”，但更深层原因是人们极度忌惮触碰任何可能破坏资历序列或被视为不忠的行为。这可是初创公司啊，相比之下那些家伙简直是野蛮人。
据我观察，这种体系在硬件领域漫长而严谨的开发周期中效果尚可。当产品周期长达十年时，由服务十年至二十年的员工主导或许并非坏事。但在软件领域则行不通。
这正是我反复强调此问题的缘由。我常告诫团队“注重细节、品质与方法论， 要向日本人学习 ”，如今却发现连日本人(更何况是他们品质标杆的丰田)都难以将质量哲学应用于软件领域。不知我的建议该作何处。
这并不影响你的建议。丰田在诸多领域享有实至名归的质量声誉：客户服务(他们持续数年为卡车免费更换车架)、建筑工程、可靠性、可维护性。某一领域的缺陷恰恰说明他们需要将这些实践推广至该领域。
几年前有篇文章(好像是《纽约客》刊载的)探讨过日本与软件的奇特关系。
这个国家始终以硬件为先导。文章列举了诸多原因——文化因素、“真正的男人造真正的东西”的观念、对家电的痴迷(家电某种程度上被视为“硬件”)、语言障碍(现有软件工具的菜单和输入界面等均采用英语)。
回望那个在80年代曾令许多人担忧会超越西方、在技术领域将西方世界甩在身后的国家，如今却鲜少见到其产出多少软件产品，这着实耐人寻味。你能想到日本有哪些知名的大型软件吗(主机游戏除外)？比如Vine Linux、SoftEther VPN、趋势科技之类？
不禁让人好奇：他们是否关注西方软件公司？是否存在追赶或保持同步的意愿？
或许日本网友能提供更深入的见解？
我虽非日本人，但在美国为一家大型日企工作。我知道他们在日本设有庞大的软件工程团队，但若涉及非硬件领域，似乎难以产出高质量软件。他们似乎已意识到这个问题，如今专注于硬件生产，并在美国组建了三个不同的软件团队为相关硬件开发软件。
他们偶尔会派遣工程师来我们办公室(通常为期6-12个月)学习我们的文化。但这些人员派驻时存在明显隔阂——他们工作勤奋，加班毫无问题，却难以融入我们团队的协作模式，我认为这不仅是语言障碍的问题。我平时对此习以为常，但这次经历让我意识到：开发者之间耗费大量时间讨论问题、质疑管理层、在白板上奋笔疾书、激烈争论、反复尝试、经历失败、调整方案、审查他人代码、修复缺陷等等。要承受这种批评并参与其中需要厚脸皮，但我认为这对优质软件开发至关重要。那些在会议中沉默寡言、等待任务分配、埋头苦干直至完成的人，其实错过了核心价值——因为有时经理分配的任务根本毫无意义，或无法用现有框架实现，甚至需要动用上百个全局变量才能完成。
我仅是推测：在那些僵化的社会与管理层级中，若解决问题的方式涉及挑战权威，那么“勤奋工作”和“尊重公司职位”反而比“正确解决问题”更重要——这种文化可能损害开发者的创新能力，并影响优质产品的产出。
> 你能想到日本知名的大型软件吗
Ruby。
这显然不是软件质量的典范。我也不认为仅凭一两个例子就对整个国家的软件质量妄下结论是公平的。
我曾为Ruby编写过C语言扩展，其内部API设计相当合理。为何说Ruby是软件质量的反面教材？
主要指早期MRI版本中大量存在的缺陷。
为何排除主机游戏？
我认为游戏领域可能是日本软件最出色的领域，至少在80、90年代如此。但按现代标准看，其代码实践可能相当糟糕(手写汇编代码、所有游戏状态都存放在全局变量中)。当内存/ROM仅有几KB时，出错空间确实很小(尽管我自己也曾在卡带游戏中遇到过bug)。
我认为这属于设备本身的一部分，并非需要下载安装或通过API调用的组件。
主机框架和API都包含在SDK中供开发者使用…因此它同样是日本成功软件产品的典型范例。
> 我认为它属于设备本身，并非需要下载安装或通过API访问的组件。
汽车ECU不也像游戏机那样属于“设备”，同样不提供API访问吗？
若找到那篇《纽约客》文章请告知，我很想读读。
我找到啦http://www.economist.com/node/18958643，好像是《经济学人》而非《纽约客》刊登的
谢啦！
这很有意思，因为在美国情况完全相反(坦白说也不尽如人意)。是否因为美国过去40年自我去工业化了？
三十年前在美国，当我选择电气工程而非计算机科学时，情况恰恰相反——电气工程因其更高的智力要求而备受推崇。这很大程度上源于当时硬件的性能水平与价值定位：IBM以数百万美元出售硬件设备，却将软件免费赠送。硬件才是差异化核心，软件则属通用品。能优化昂贵硬件的电子工程师，远比能改进免费软件的程序员更有价值。事实上，当内存等硬件资源翻倍时，软件能实现的功能提升远超硬件提升的倍数——因此硬件工程师的重要性甚至超越了软件工程师，对软件领域本身亦是如此。
随着硬件限制逐年放宽，即便使用廉价硬件，软件能实现的功能也呈指数级增长，核心价值逐渐转向软件领域。这场计算机行业的剧变几乎摧毁了IBM，却推动微软崛起，也让我最终投身软件行业。
丰田及其他亚洲“硬件”供应商某种程度上正处于IBM当年境地。他们销售获奖硬件，而随附软件本质上是免费的。(苹果公司与此颇为相似，这正是其硬件持续升级而软件——呃，我是否提过硬件更轻薄了？)
丰田的“平台”在软件领域仍显薄弱，但正呈指数级增长。终有一天，汽车中的软件可能比(商品化的？)硬件更重要，但丰田管理层的思维模式尚未形成这种认知。他们痴迷于硬件，而软件只是事后才想到的附庸品——就像那些在1980年代前的美国“计算机产业”里，无法成为“真正工程师”的人所从事的工作。
我曾在日本生活工作。身为战略顾问时，多家知名日企和韩企(皆为家喻户晓的企业)告诫我：若珍视职业声誉，务必突出硬件背景，切忌被软件团队成员频繁往来所累。
苹果完全不同。他们的软件卓越非凡。我推测其用户持续购买硬件的原因，很大程度上源于iOS或OS X系统本身，而非机身更薄。
您是否想表达“去工业化是指因国家或地区工业产能或活动(尤其是重工业或制造业)的削减或消失而引发的社会经济变革”？
这似乎不适用于美国——当前美国商品产量不仅创历史新高，更仅次于中国位居全球第二。
我指的是工业占GDP的比重。查查数据：http://en.wikipedia.org/wiki/Economy_of_the_United_States_by…。制造业占比持续下降。
不过现在生产所需的人力远少于从前。从这个意义上说，确实存在“去工业化”现象。
我亲身经历印证了这点——虽然我在美国工作，那是90年代的汽车行业。我曾任职摩托罗拉汽车与工业部门，我们团队开发的计算机辅助制造系统管理着整条生产线。相比工艺工程，这始终像个二流岗位。
这是个真诚的疑问：为何不能将软件开发外包？
鉴于他们将研究员实际囚禁在酒店房间并实施严密安保，我认为是因企业极度恐惧商业间谍活动之类威胁。
我不愿过早指责工程师。他们可能受制于管理架构，无法获得充分的工作自主权。工程师固然有责任，但在软件领域，冗余代码的实际危害往往难以预判，有时唯一能做的就是辞职。
我认同，但作为工程师，我认为自己有责任拒绝在可能危害他人的条件下开发产品。至少应在继续推进前，以书面形式向管理层传达我的担忧。
有时，辞职确实是合乎道德的选择。
辞职确实是道德的选择。我好奇若身处他们境地是否也会如此。
在这种文化环境下，书面提交担忧实属罕见。我甚至因提出此建议而遭嘲笑。而辞职者往往面临大幅降薪，被迫从事缺乏保障的合同工作，甚至再也无法在软件行业立足——尤其在名古屋这种人脉交织的城市。
当你背负着家庭和房贷(在这里卖房也必然巨亏)，现实选择往往是：要么你和家人流落街头，要么乖乖听命行事。
工程师虽非全无过错，但这里的制度确实已然崩坏。
这是否源于日本的上班族文化？若被迫在这种职场环境下工作，我恐怕会心脏病发作。
心脏病发作我不确定，但日本自杀率确实很高。
但若你还有生活要过，有家人要养，有账单要付呢？
虽然我愿认同你的观点，但人们价值观各异。金钱才是硬道理。因此辞职并非总能成为选项——即便它最符合道德。道德可付不起账单。
> 因此辞职并非总是可行之选，尽管它最符合道德。
若你认为退出危险项目(让大型企业用其他平庸工程师替代——这种企业雇佣数千人)是道德正确的选择，那你的道德指南针已然失灵。
我们讨论的是销量数百万台的设备，它足以对人类及环境造成巨大身体伤害与结构性破坏。
知情者面对此类状况时，揭发(最好在实际危害发生前)才是 唯一 的道德选择。
那么你本就不该接手关乎人命的工作。将个人生计置于他人账单之上是人之常情，但若将个人生计置于他人性命之上——普通人绝不该有这种想法。
这本质是系统性问题，而非工程师的道德缺陷。应归咎于那些助长恶行的制度体系。
除非你过着没有奢侈品的生活，否则你就是在将获取奢侈品的权利置于他人生命之上。这种行为令人发指，即便你将其包装成“账单要付，孩子要养”。
若你身为丰田固件工程师，想必不难找到薪资优厚的工作来养家糊口。
而且日本大企业每两年就会轮换员工。我曾听闻此事却不信，直到亲眼所见——当某位分销商的员工刚熟练掌握业务，就会被新手取代。
若丰田也如此操作，许多现象就说得通了。
举报？联系监管机构？
我就是受害者之一。所幸仅造成轻微损伤。在泰国驾驶丰田厢式车时，遭遇走走停停的拥堵路况，引擎突然开始狂飙转速。我猛踩刹车，引擎竟降档至一档来补偿，结果追尾了前车。碰撞后(完全停住？)引擎似乎恢复了正常，转速随即停止飙升。
质疑者会指出：踩刹车时引擎不该转速飙升。这恰恰是该故障的典型症状。对了，我绝对没误踩油门——否则岂止是“轻碰”前车？
编辑：我把车开到经销商处，他们说是“用户操作失误”……反正泰国也没有消费者保护法，我也就作罢。
我上一家公司基于与丰田的合作关系，将大型固件项目外包给了电装。
结果他们花了18个月写出勉强能用的难以维护的代码，产品2.0版本时整个代码库只能彻底废弃。代码里充斥着复制粘贴、全局变量和临时拼凑的互斥锁——他们甚至没用实时操作系统自带的互斥机制。
或许电装派了二线团队负责这个项目，谁知道呢。
> 几年前新闻刚曝光时，考虑到丰田在质量和流程方面的声誉，我以为这是美国工业界针对日本竞争对手发起的政治迫害。但若证词属实，丰田工程师的行为实属不可饶恕。
这两种可能性并不相互排斥。
抛开软件工程实践不谈，是否曾证明过意外加速现象确实源于该软件的行为？
是的，巴尔证词的另一部分是针对ECU进行的一系列概念验证演示，证明了终止任务的能力——这会导致被控制的硬件处于非预期状态。
>是否曾证实过非预期加速确实可能由该软件行为引发？
这个问题完全问错了。正确的问题应该是“系统设计是否已被证实能彻底杜绝意外加速的发生？”
> 是否曾证明过意外加速确实可能由该软件的行为引发？
没有，但软件工程实践之糟糕，使得这个问题变得毫无意义。
丰田在 机械工程 领域的质量与流程素来享有盛誉，这份声誉至今仍当之无愧。
而软件工程方面显然恰恰相反。
> 几年前新闻刚爆出时，鉴于丰田在质量与流程方面的声誉，我以为这是美国工业界针对日本竞争对手发起的猎巫行动。
你啊。你就是我完全摸不着头脑的众多人之一。最初看到报道时，它们看似可信，丰田似乎在隐瞒什么，但太多人不愿相信，消息就这样悄无声息地沉寂了。
不必情绪化。有人草率得出偏颇结论，有人依据NASA的软件审查报告(现已证实存在缺陷)。详见报告：http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUB…
在C语言中，可能存在作用域局限于局部(模块或函数范围)的静态变量，其生命周期无限。
此设计旨在减少栈空间消耗，并不意味着这10000个变量可在任意位置被访问。
不过我不想破坏这里摇滚明星级全栈网页开发者们热衷的“蠢C程序员”嘲讽派对。显然，他们比从业多年的嵌入式软件开发者更懂行。
关于全局变量数量的批评直接源自Phillip Koopman——“卡内基梅隆大学计算机工程教授、安全关键型嵌入式系统专家，著有教材《更好的嵌入式系统软件》”。
可见批评者并非网页开发者，而是拥有丰富嵌入式软件开发经验的专家。在草率下结论前，或许先阅读原文会更有帮助！
局部作用域(即静态)变量按定义并非全局变量。文章明确指出10,000个数字特指真正的全局变量，我希望最初的专家证人没有通过将静态变量称为“全局变量”来误导我们。(当然，在无法查阅原始资料的情况下，我们无法自行判断。)
遗憾的是，尽管这种做法愚蠢至极，但仍有大量嵌入式系统使用全局变量存储和传递状态，其数量之多令人震惊。
(声明：我并非网页开发者，确实在嵌入式开发领域工作过数年。)
若在HN搜索“Michael Barr”，可找到过往讨论中诸多精辟见解：
“在圈复杂度量表上，10分被视为可用的代码，15分是某些特殊情况的上限。丰田的代码中存在数十个超过50分的函数。值得注意的是，节气门角度传感器的函数得分超过100分，这使得它完全无法测试。” https://news.ycombinator.com/item?id=7711771
"例如，http://www.edn.com/design/automotive/4423428/Toyota-s-killer… 援引巴尔的指控：’丰田电子节气门控制系统(ETCS)的源代码质量存在严重缺陷。’ “丰田的源代码存在缺陷且包含漏洞，其中包括可能导致意外加速(UA)的漏洞。” https://news.ycombinator.com/item?id=8906513(该链接文章附有启发性幻灯片)
https://news.ycombinator.com/item?id=6636811下多条评论指出：“丰田固件：糟糕的设计及其后果”
因此，考虑到这一点，再加上自动驾驶汽车。这些系统涉及的复杂性及其所需的协调性绝非易事，从文章中可以清楚地看出，他们并没有很好地掌控局面。
毕竟多数车辆行驶尚可，我甚至惊讶于其内部竟存在如此可怕的隐患。但我们绝不能在增加复杂系统时懈怠，尤其当社会对它们寄予厚望之时。
这段代码远未达到NASA级标准(甚至相去甚远)，令人毫无安全感。它充斥着不专业、贪婪与懒惰的气息。
需要建立一套理性的软件评估体系。人们依赖的产品源代码量正持续攀升——若能有第三方机构介入，认证某个代码库并非难以维护的混乱泥潭，这将极具意义。这并非意味着代码中不会存在漏洞或问题，而是表明开发者至少在 努力 构建设计良好的系统，而非肆意堆砌荒谬的代码。
当前最积极投入自动驾驶汽车领域(哈)的企业，其实都相当专业。沃尔沃多年来生产的重型卡车具备卓越的安全特性，例如能自动探测前方静止车流，并在看似不可能的短距离内让满载卡车完全停稳(https://www.youtube.com/watch?v=HoCknasKdRU)。
虽然我对谷歌诸多方面颇有微词，但不能说他们在软件开发上不擅长。若真有人能打造出安全的自动驾驶汽车，那必定是他们。
特斯拉同样如此，他们为打造新一代汽车而建立的声誉来之不易，正背负着巨大期望。
作为老派汽车爱好者，自80年代糟糕的尾气控制系统以来，我始终对汽车日益复杂化持保留态度。但即便如此，我也必须承认这些复杂技术挽救的生命远超其代价——防抱死刹车、安全气囊、更优的污染控制、更佳的燃油经济性，以及 大幅 提升的车身结构安全性。
若你曾驾驶过配备气动制动器的车辆，便知其制动力道何其 强劲 。
行业标准并非不存在，丰田只是选择性地全部忽视。诸如MISRA[1]和DO-178C[2]等标准，正是为保障安全关键场景的软件质量而设立。大多数嵌入式软件开发环境甚至配备了工具链，专门用于验证开发者是否触犯了安全底线。问题更在于汽车制造商无需遵循任何此类标准，这与美国联邦航空管理局数十年来强制执行的要求截然不同。
[1] http://en.wikipedia.org/wiki/Motor_Industry_Software_Reliabi… [2] http://en.wikipedia.org/wiki/DO-178C
丰田无法忽视这些(自愿性)标准，毕竟在代码开发时期，MISRA-C及更早的DO-178标准均未存在。
MISRA-C诞生于1998年，而作为DO-178前版的DO-178B则可追溯至1992年。
是的，我打错了(应为“…后来的DO-178…”)。你完全正确，当时确实存在DO-178B标准，但C语言版本尚未出台。
根据证词，丰田的编码标准在1997年就已确立，早于MISRA-C的首版发布。
首先，你忽略了“例如”这个限定词。
其次，DO-178标准最初发布于1992年。
精彩评论！我此前并不知晓相关标准的存在，但很高兴看到它们确实存在。不过丰田本应遵循这些标准。难道他们自以为更懂行？我认为随着自动驾驶汽车的发展，这些标准将逐渐成为强制要求——尽管恐怕要等到软件故障导致连环死亡事故后才会实现。
鉴于计算机视觉工作多基于随机化算法，你认为这些标准是否足够？例如通过神经网络实现可证明100%的MC/DC覆盖率，但权重参数本身可能存在缺陷。
这引出了个关键问题：自动驾驶汽车是否会受对抗性图像攻击？
众所周知神经网络极易被欺骗[1]…不知能否对自动驾驶系统制造类似困境。
[1] http://www.evolvingai.org/fooling
[已删除]
丰田不该比谷歌更接近NASA吗？毕竟我们讨论的是关乎人命的系统。如果我的网站由某个IT部门开发，但日常依赖的控制系统却融入了NASA级别的工程技术，我完全能接受。坦白说，现实情况与之相去甚远着实令我惊讶。
自动驾驶汽车反而让我觉得 更 安全。即使使用不可靠的组件(比如固件糟糕的汽车)，只要顶层软件具备容错能力，就能构建出可靠系统。与人类不同，“自动驾驶系统”在刹车失灵等危急时刻会立即靠边停车。
这个问题每隔几个月就会重新出现在Hacker News和公众视野中，但每次都存在关键缺失：即缺乏直接证据证明该软件的实际故障曾导致任何地点、任何时间发生的意外加速事件。更遑论驾驶员无法通过刹车制止的失控加速案例(需同时伴随刹车失灵)。鉴于近年来丰田车辆的油门踏板已被踩踏至少数十万亿次，这根本算不上可怕的安全记录。事实上，踏板卡滞(无论是润滑不良还是脚垫卷起所致)导致油门失控的概率比软件故障高出数个数量级，而车辆失控(同时伴随刹车失灵)通常源于“踏板误操作”——即踩错油门而非刹车。
软件存在导致恶果的执行路径，并不意味着该路径必然被触发——在封闭的实时系统中，无法接收所有输入组合，这与从文件加载用户数据的系统截然不同。这并非意味着丰田无需清理和验证其代码，但围绕该代码对程序员、人类状况、日本等引发的道德恐慌实属无谓。
引自http://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle_…：
2011年2月8日，美国宇航局与国家公路交通安全管理局公布了历时十个月的调查结果，针对2009年丰田汽车故障原因展开研究。根据调查结论，车辆电子系统不存在可能引发突然加速故障的缺陷。
每当这篇报道出现在黑客新闻上，总会出现几条评论声称无人能 证明 这些漏洞 绝对导致 了事故，因此对丰田的批评实属过度渲染。这让我不禁困惑：这些观点如何与软件工程的普遍理念(本社区的核心议题)相协调？我们日常可见关于并发框架、容错编程、代码正确性形式化验证等技术的文章。既然亚马逊认为使用TLA+证明DynamoDB正确性至关重要，那么丰田汽车对可能加速致命的装置不采取同等措施，难道不该被视为荒谬吗？
Reddit社区整体缺乏软件 工程 经验。似乎只有少数评论者具备相关知识，但他们只是极少数群体。
个人而言，我惊讶于多数HN用户选择忽视NASA和Exponent(丰田外部专家证人)的报告，反而采信俄克拉荷马州原告方证人巴尔的证词。(坦白说，巴尔能获准担任专家证人令我震惊)巴尔确实证明了代码存在“可疑之处”，且可能通过注入特定故障引发非指令性加速，但他既未证明其提出的故障模式实际发生，也未证明该模式具有 发生可能性 。事实上，其故障模式的特征之一就是不会留下故障代码记录。这种故障模式堪称同情原告方对抗财力雄厚傲慢被告的完美武器：既存在发生可能性，又能进行演示验证，陪审团易于理解(谁没见过蓝屏死机？)，且无法被证伪。
你提及软件工程实践，但需将其置于电子节气门系统研发时期的技术背景中审视。当时MISRA规范尚未诞生(HN读者正逐渐了解该标准)，而证明助手工具——即便在今天仍难以使用且难以集成到软件生命周期开发中——当时更是晦涩难懂。事实上，你举的TLA+例子即便在今天也行不通，因为TLA+不支持代码生成，而这正是受监管软件生命周期开发中验证流程的必要环节。我认为TLA+在当时也不存在。时代确实变了！
> 你提及软件工程实践，但需将其置于电子节气门系统开发时期的背景中考量。MISRA(如今HN读者逐渐了解的标准)当时尚未诞生。
DO-178B标准诞生于1989年，Ada语言创立于70年代，任务关键型与安全关键型系统的标准规范自70年代便已确立。我早在80年代童年时期就研读过Ada语言与安全关键编程(我确实是个怪孩子)。
http://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_s… 提供了极佳的综述。
无论你是否认同多位安全关键编程领域的独立专家的观点，但庭审中披露的内容已向我清晰揭示了该软件的严重缺陷。
持怀疑态度者或许会质疑：若丰田竟如此不堪，其他制造商的状况恐怕同样糟糕。
编辑补充：我并非断言此次故障由该软件直接引发——在缺乏源代码及确凿证据的情况下无法定论，但整体环境确实令人不寒而栗。
> DO-178B标准诞生于1989年，Ada语言则起源于70年代，任务关键型与安全关键型系统的标准规范自70年代便已确立。我早在80年代童年时期就研读过Ada与安全关键编程(我确实是个怪孩子)。
我斗胆猜测，HN的读者群里应该有不少曾经的怪孩子呢。:)
当时确实存在DO-178B标准，但我未曾听说任何汽车制造商在当时或现在采用它——毕竟我不在汽车领域，可能有误。我认为IEC 61508本应是最佳参考模型(尤其考虑到IEC 26262正是其衍生标准)，但当时61508恐怕连正式标准都未出台，仅存草案。Ada语言虽已存在，但当时与如今大相径庭，且工具链相当欠缺(个人观点)。除政府强制要求外，我实在想不出多少实际应用Ada的案例。
对于普通消费品(即航空和军事领域之外)，我难以回忆起丰田电子油门系统研发时期存在的、针对任务关键型和安全关键型电子系统的行业标准。或许SAE当时有相关规范？但简单谷歌搜索并未找到任何结果。
> 无论你是否认同多位安全关键编程独立专家的观点，但庭审披露的证据已清晰揭示该软件的缺陷程度。
需澄清的是：我并非否认该软件按现代标准存在缺陷，而是质疑其在开发时期是否确实比业界其他产品更差。话虽如此，丰田当时确实傲慢自大，无视自身流程和要求的行为无疑是错误的。我依然怀疑软件组件是导致意外加速问题的根源。
> 愤世嫉俗者或许会质疑：若丰田如此糟糕，其他制造商又有多糟？
难道零假设不正是“所有制造商同样糟糕”吗？
从安全角度看，我认为应与电子油门系统问世前的机械式节气门连杆进行对比。机械连杆的可靠性明显更差：其长长的控制线缆在发动机舱内蜿蜒穿梭，节气门卡滞曾是常见故障。而电子系统则杜绝了这类问题。当然，关键的备份安全系统在于多通道冗余制动系统。
顺便说一句，我读了巴尔试图重构丰田ECU的报告(评论区有他的幻灯片链接)。这简直令人愤怒。他先是喋喋不休地谴责丰田代码有多糟糕(意大利面式代码云云)，接着开始列举故障模式：假设随机硬件内存错误翻转了CPU任务表中的某些位，那么监控踏板角度的任务就会失效。但要实现描述中实际发生的非预期加速(即驾驶员踩刹车时)，还必须同时假设油门位置变量也遭到破坏。且不论这种组合概率之低，试想：假设丰田代码完全没有“意大利面条式”结构或全局变量。假设它美得足以让天使喜极而泣。当任务表位被翻转时，这他妈的能改变半点局面吗？当然他妈的不能。
他的指控不过是业余的后座工程师思维：既然通过多份副本保护了变量A和B免遭篡改，为何不保护C？既然看门狗程序能在任务X和Y死亡时重启，为何不保护Z？诸如此类。这些建议未来或许可行，但当系统已远比旧版安全，且配备了极其可靠的备份机制时，仅因未让本已极安全的系统变得更安全一点，就要求厂商承担责任，这合理吗？
尤其耐人寻味的是，巴尔竟以工程学专家身份就“工程确定性”作证——据我所知他根本没有注册工程师执照(若有的话，他就是我见过的第一个不刻意炫耀此资质的工程师)。我原以为任何州都不允许这种行为。
编辑：丰田确实犯了不少错误。首要问题在于他们无视了自身记录在案的流程规范。系统利用率超过70%也是问题之一，递归算法的使用同样如此——这些在当时都是绝对禁止的做法。但我认为，许多人主张在新车多年研发周期中实施新兴标准是实用或明智之举，这种观点并不公平。我依然怀疑意外加速事件与软件相关。若要采信庭审中提出的“位翻转”论点，就必须同时假设驾驶员耗尽了服务制动真空，而这种组合在我看来不太可能发生。
当然，他们应该基于普遍原则改进或清理代码。但这里存在两个问题：
许多文章暗示某位专家已证明编码错误会导致意外加速。然而查阅实际来源会发现，所谓的“演示”涉及以各种任意方式改变控制器的内部状态，有时甚至以无效方式重新接线其传感器。换言之，这并非“在N挡切换至D挡时轻踩油门，0.2秒内踩下刹车，油门就会全开”这类可复现的操作流程。尽管投入数百万美元进行专家分析，至今仍未发现此类流程，这表明现实中根本不存在这种情况。暗示该代码正在某处夺人性命实属误导。
是的，此事已被过度渲染。我们知道油门可能卡死，通常是连杆或踏板卡滞所致。这并非重大问题，因为制动系统足以在这种状态下使车辆停稳。我认为与其耗费资源重写软件来防范可能根本不存在的“软件诱发意外加速”，不如开发车道偏离预警/碰撞预警/紧急制动辅助等已知能有效避免事故的安全系统，这才是更具实际意义的投入。
第三个问题在于美国诉讼体系——它能将企业塑造成恶棍，即便其产品问题率与同类产品无异。只需存在非零故障概率(多数产品皆如此)加上媒体与法律的狂热追捧，便足以引发风暴。
> 尽管投入数百万美元进行专家分析，却始终未能找到此类配方，这表明现实中根本不存在这种情况。
我对此持异议。源代码分析——尤其当全局变量削弱了单元分析价值时——无法揭示(可能数百万)用户在实际场景中每日运行代码的真实情况。仅因无法彻底排除源代码责任，就构成品牌方责任缺失。
美国诉讼制度确有缺陷，但我认为集体诉讼并非其弊端。当民众对类似争议存在分歧时，它能通过明确的法律裁决推动社会变革。
普遍解释是：至少在标准汽车中，制动系统能施加远超发动机的扭矩。这恰恰暴露了人们的幼稚——他们认为问题在于“非预期加速”，而机械工程师则认为描述的问题实为“非预期制动失效”。
完全正确。读过无数关于这些“失控死亡机器”的报道后，一个事实变得清晰：汽车唯一可能违背驾驶员意愿全速加速的情况，就是驾驶员误将油门当刹车踩到底。
我们应当为汽车添加更智能的自动辅助系统，而非例如废弃线控驱动装置，转而采用通常更不可靠的机械结构。
现已存在能在碰撞强度触发气囊时紧急制动的车型——这能有效抑制车辆失控甩尾。汽车完全有能力预判碰撞风险，提前半秒启动制动系统以避免或减轻事故。
若制动失效，不妨试试钥匙开关！熄火状态下车辆不会加速。(当然某些特殊按钮点火装置在挂挡时无法关闭，但多数车辆 可以 实现。)
关闭点火开关可能导致安全气囊失效*，反而加剧危险。最佳做法是先将车辆挂入空挡。
*这正是通用点火开关事故致命的关键：熄火导致动力转向和真空助力制动失效，同时安全气囊失能，使后续碰撞的生存几率大幅降低。
你说得对，切换模式确实更好。不过气囊出现这种故障模式实在太糟糕了。在气囊电路里加装一个大容量可靠电容，维持30秒供电需要多少钱？一美元？
得了吧。你的论点和创世论者反对进化论的论调如出一辙——“混沌系统不存在确凿证据”。
软件工程的根本目的在于管理和规避复杂性，而非将软件模糊化/复杂化到失控程度，再以“无法证明软件错误”为由推卸责任。无论正反两面都无法提供证明的事实，是设计流程的失败，而非主张者的过错。
“软件存在导致恶果的执行路径，并不意味着该路径必然被触发”——恰恰相反，这正是“执行路径”一词的本义。
“车辆电子系统不存在可能引发突然加速故障的缺陷”。电子系统无故障？听起来他们只测试了线缆绝缘，却未检测失控代码。
> 软件设计有两种构建方式：其一是设计得极其简单，以至于明显不存在缺陷；其二是设计得极其复杂，以至于不存在明显缺陷。
-托尼·霍尔
> Un bon mot ne prouve rien.(妙语不能证明任何事。)
——伏尔泰
上世纪90年代，某美国汽车制造商的工程师曾告诉我，他们车载代码如同黑匣子。无人知晓其运作原理，只能监控输入输出，通过打补丁来修改输出结果。
或许这位工程师指的是某个特定部件的代码，但丰田的软件或许并非特例。
深有同感。我敢打赌任何公司一旦被放大镜审视，都会暴露出糟糕的实践/反模式。
但这究竟是行业问题吗？我不禁想起《搏击俱乐部》里的“召回”公式…
“1998年该标准曾有第70条规则——具体措辞记不清了。但核心要求是函数应自行调用。现行规则本质相同，只是编号体系变更，因此该规则在新版标准中对应第16.2条。这属于违反MISRA C规则。”
"NASA如何看待这种递归？NASA主要担心栈溢出风险。他们为此专门撰写了约五页说明，我摘录部分内容：递归可能耗尽栈空间导致内存损坏和运行时故障。具体如何？凯美瑞中的递归可能引发栈溢出。导致内存损坏？确实会造成内存损坏，这种情况在测试中难以检测——"
天啊，这根本是基础知识。他们改了规范编号却没更新手册，还忘了递归会消耗大量内存并覆盖栈空间…哎，这些连CS50课程的C语言初学者都知道…
我认为更值得探讨的问题是：
若非丰田，那究竟是谁？哪些车企做对了？是否有公开证据佐证？若无，那么驾驶其他品牌车辆与丰田相比，我的“安全”或“不安全”程度恐怕并无二致。
这纯属猜测，但特斯拉的车载软件至少应该不错——毕竟他们敢把SpaceX龙飞船V2舱的部分技术直接搬过来用。
我认为这个领域亟需开源。任何有能力且有意愿的人都应能审计软件。修改行为应通过签名机制限制，除非用户签署声明承担修改后果的全部法律责任，并重新通过车辆道路适航认证。
从理想主义角度看开源固然美好，但考虑到软件的复杂性(数百万行代码)、所有软件都将应用于商业公司的事实，以及汽车领域本身的特性，你真认为开源社区会接手吗？我对此表示怀疑。况且研究人员确实进行了审计——耗时18-20个月，而这仅是分析阶段，尚未涉及改进或修复。
更何况，没有任何汽车制造商会允许用户自行修改固件。
以下是巴尔演讲使用的幻灯片：http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUB…
请在标题中添加(2013)。
此事已过去数年，人们或许已淡忘。但当年丰田汽车确实因软件漏洞随机发生“意外加速”故障。
许多报告的事故无疑是由于人们在惊慌失措时踩错踏板，且事后记不清自己操作所致。另一些事故则源于脚垫卡住踏板。但部分事故确实是丰田的责任。
这点是否得到证实？丰田是否曾发布过必须安装在所有车辆上的软件补丁？
我记得他们更换过可能卡住的地毯，以及这个http://www.thetruthaboutcars.com/2010/03/ the-best-of-ttac-th…
从未证实过，因为根本不存在这种情况。维基百科条目有更详细的说明：http://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle_…
所有非预期加速事件均发生在自动挡车型中绝非巧合。此外，在美国以外地区尚未发现丰田汽车存在广泛的非预期加速问题。
可悲的是，如此多Reddit用户对丰田的指责如此轻率
> 所有意外加速事件均发生在自动挡车型中绝非巧合。此外，美国以外地区的丰田汽车并未出现大规模意外加速问题。
若我的车突然失控加速，我首先会猛踩离合器并制动(可能还会挂空挡)，但这源于当地多数车辆是手动挡，因此我们习以为常†。沿此思路推演：停车后熄火即可避免灾难。重新启动后系统重置，通常不会有问题。随后可驱车前往最近的丰田经销商投诉，但由于“未造成实质损害”(即无损伤无伤亡)，你只会得到耸肩回应和一次软件更新。
† 在仅教授自动挡驾驶的国家，将挡位切回空挡绝非本能反应 (即便机械上可行)
我也陷入矛盾：刹车理应具备抵消发动机与变速箱任何扭矩输出的能力——除非防抱死制动或牵引力控制系统具备覆盖驾驶员指令、释放或限制制动扭矩的功能。
此外，我查阅过的所有脚垫召回说明都指出，问题在于脚垫可能干扰油门而非刹车。丰田随后又进行了第二次召回，专门修复油门踏板故障。这两点都暗示非预期加速至少是事故的重要诱因——除非丰田和美国国家公路交通安全管理局只是为了做做样子。
关于证据问题，文章已详细阐述：在远未穷尽的系列调查中，已发现软件陷入非预期状态的途径如此之多，以至于在海量潜在成因中仅有极小部分被纳入考量。要求提供错误证据本身就是错误的提问方式：证明责任显然在于制造商，他们必须证明自身系统安全可靠——而丰田无法凭借现有软件做到这一点。
丰田更换脚垫的行为绝非其软件正确的证据，软件补丁的缺席同样不能证明其正确性。文章引述了一位忧心忡忡的丰田工程师的言论，其表态揭示了公司内部存在否认问题的文化。
哎呀，所有Reddit链接都是今日的，没注意到原文是2013年的。标题已更新。
当年导致意外加速的问题全是机械故障时，事情简单多了。比如回位弹簧断裂、连杆卡死之类。我的日常用车采用机械节气门(尽管是电喷系统)，说实话我实在看不出汽车采用“线控节气门”有什么意义。
但另一方面，即便存在诸多 潜在 故障点，据我所知即便经过大量测试，至今仍无人能证实一起非预期加速事件。
电子油门对多种节能技术大有裨益，因其能省去节气门板，从而消除各类节流损失(参见MultiAir、ValveTronic、ValveMatic等技术)。它还能简化巡航控制及牵引力/稳定性控制系统。汽车电子化总体利大于弊(个人观点)，但其隐藏的复杂性至少令人胆寒。
150英尺长的刹车痕迹，堪称非预期加速现象的铁证。
你从未遭遇过此类缺陷吗？当缺陷仅影响极少数用户且仅在特定条件下触发时，其追踪难度之高不难理解。这正是令人闻风丧胆的海森堡缺陷。
电动汽车没有机械节气门。
与航空航天和医疗领域类似，汽车工业在研发流程方面也应制定严格规范。通常医疗产品若审计不合格，生产商将被禁止销售一年。汽车行业或许也能推行类似机制。虽然这可能推高汽车成本，但至少能大幅提升安全性。
这些都是关乎安全的关键系统。代码质量如此糟糕仍令人震惊。此事曝光后，我推测所有现代丰田电喷车型都存在同样的安全隐患。其他汽车制造商恐怕也好不到哪里去。
我开的是丰田车，但它采用机械节气门体。:)
仍有太多疑问未解…
如何判断哪些丰田车型受影响？所有车型都存在这些问题吗？丰田究竟采取了哪些措施改进软件工程流程？
我问这些是因为父母开着2005或2006款丰田Sienna，现在实在不放心他们驾驶这辆车。
若担心安全问题，建议参考事故统计数据。考虑到整体事故发生率，即使存在已知缺陷，风险增幅可能也有限。真正起决定作用的因素可能是：行驶区域(天气等)、特定时段的行驶里程，或是车型差异。
或许我的判断有误，但风险确实可能显著存在——但应对策略应当一致。即便发现并修复了某个问题，数据仍能揭示哪些车型最安全。很可能其他厂商的产品更糟糕，只是尚未被调查而已。
根据安全统计数据，丰田汽车在美国道路上属于最安全的车型之一——即便(这个“即便”很重要)其中部分存在“意外加速”问题。
这说明即便(这个“即便”很重要)该问题真实存在，其实也从未构成重大隐患。有趣的是，该问题在美国以外地区从未出现过。
指的是哪项安全统计？IIHS碰撞测试报告还是实际道路数据？
后者。
有链接吗？我真心感兴趣。
“车辆电子节气门控制系统(ETCS)的缺陷是凯美瑞突然加速及后续事故的直接原因。” [0]
我没找到驾驶员具体如何撞车的描述。当时是使用车载巡航控制还是正常油门操作？千万别用巡航控制。下次保养时必须问清楚我的车是电子节气门还是机械节气门，@bliti
[0] http://www.usatoday.com/story/money/cars/2013/10/25/toyota-s…
该故障既非巡航控制系统异常，也非常规油门操作所致。其表现形式实则令人胆寒：
“Koua坚称他的1996款丰田凯美瑞在重踩刹车后仍加速至70至90英里/小时。”
http://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle_…
上下文虽不完整，但“我们遇险了，刹车失灵”
https://www.youtube.com/watch?v=03m7fmnhO0I
感谢@catshirt，我注意到关于我的凯美瑞的说明： “丰田澳大利亚宣布其油门踏板由不同供应商生产，因此无需召回澳大利亚制造的车辆” 。
阅读说明时发现，行驶中尝试熄火会影响多个电气子系统。我个人会尝试将车辆挂入空挡(自动挡)。
几年前我的车发电机烧毁。当地RAC救援后，电瓶残余电量勉强支撑我开了30多公里回家。当我驶向三公里外的修理厂时，电量开始骤降，电池故障灯(即发电机故障指示灯)亮起。
随后车辆系统陆续失效：安全带、超速档、ABS…等功能逐一瘫痪。直到我蹦跳着将车开进车库时，所有功能彻底停摆。毫无疑问，在繁忙车流中遭遇油门卡滞比车辆突然顿挫更令人惊恐——我坚持开到了最后一刻。最后失效的是助力转向系统，紧接着引擎本身也熄火了。
谷歌(或特斯拉、优步)的自动驾驶项目是否采用Ada语言？恐怕答案仍是C++。
注意到本文提及MISRA-C却未提及Ada。我记得曾读到丰田使用SPARK Ada。迈克尔·巴尔的幻灯片中有更多关于丰田C代码的技术细节：
http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUB…
能够修改车辆操控任何方面的软件，其测试和审查标准应高于安全气囊和安全带等部件。故障的定速巡航组件显然比故障的安全带更危险。
请将标题中的“Toyotas”修改为“Toyota’s”。
10,000个该死的全局变量。面对如此庞杂的竞争条件，想进行单元测试简直难如登天。天啊。
真不明白为何有人坚信5个或10个就能接受。
发动机故障灯？乘客未系安全带？
毕竟是嵌入式系统，资源本就稀缺。当然存在更优雅的解决方案。但通过多个传感器触发错误状态，再由多个位置进行检测的模式，至少算不上荒谬。
他并非认可5-10个全局变量，只是表示自己能处理这个数量而不至于崩溃。这点毋庸置疑。
对于具有全局影响的简单配置，全局变量可能比其他设置追踪方式更便捷。不过这种做法在嵌入式软件中确实比其他软件更常见。
其他日本车企的软件是否也存在同样问题？
计算全局变量数量纯属无稽之谈。我认为无论多少个全局变量都无可厚非。
你用一次性账号发表明显挑衅的言论。对于新手程序员，我们不随意使用全局变量的原因在于：极易遗漏所有可能访问该变量的位置，导致代码变得极其脆弱。
大量反对票，无人反驳。
这无异于宣称狗屎是绝佳早餐。根本不值得反驳。
这恰恰说明全局变量已被公认为反模式多年，人们选择对显而易见的观点投反对票而非撰写反驳。
或许你该引用些资料来支撑你之前的主张。