从程序员角度看丰田刹不住要点.doc

【第1部分】背景简介  前几年闹得沸沸扬扬的丰田刹不住事件最近又有新进展。十月底俄克拉荷马的一次庭审，2007年一辆2005年凯美瑞暴冲（Unintended Acceleration，UA）致一死一伤事件中丰田被判有责。引起广泛关注的是庭审中主要证人Michael Barr的证词让陪审团同意丰田的动力系统软件存在巨大漏洞可能导致此类事件。这是丰田在同类事件中第一次被判有责。庭审过后丰田马上同意支付300万美元进入调解程序。 /wiki/Sudden_unintended_acceleration 出于好奇，我漫不经心地下载了Barr的286页证词，却一下子被吸引住了。几天内读完，算是对这次事件进行了一次深入了解。下面就从外行角度总结一下这份证词并尝试以更简单的语言解释里面提到的暴冲原因以及丰田犯下的错误。 Barr的证词下载自他的个人博客Barr Code，但现在该文已经被删除。见2楼。 Michael Barr是谁？他是一位拥有20年以上行业经验的嵌入式系统工程师。在十八个月中，有12位嵌入式系统专家，包Barr，受原告诉讼团所托，被关在马里兰州一间高度保安的房间内对丰田动力控制系统软件（主要是2005年的凯美瑞）源代码进行深度审查。这房间没有英特网，没有手机信号，他们进出不能携带任何纸张、记录甚至皮带。最后的调查结果被写入一份800页，13章的详细报告。而鉴于保密协议，调查内容一直没有公布，直至俄克拉荷马这次庭审才首度部分公开（报告本身似乎还没公开）。 回到正题。丰田的软件有没有缺陷？根据Barr的调查，答案是有。这其实是废话，任何软件都会有缺陷，关键在于是什么样的缺陷。丰田的软件缺陷分为三类： 1、非常业余的结构设计。 软件设计的基本要求是模块尽量简单化，因为这样可以一来更易于阅读二来更易于维护。但丰田的工程师显然没有遵循这原则（模块尽量简单化）。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。 还有一些别的匪夷所思的发现。比如丰田的软件包含了超过一万一千个全局变量。如果你不知道什么是全局变量，那么只需要知道软件设计的一般原则是要尽量少使用全局变量，因为有可能带来无法预测的结果。这里的“少”的意思是“尽量接近零”，绝对不会是一万一千个。 不符合软件开发规范。 如同很多行业一样，汽车行业也有自己的规范。更具体一点，由于汽车的危险性质，汽车控制系统被划分为“安全关键性系统