追求“万无一失”的汽车产业，正面临数字化变革带来的质量挑战。如何造一辆不会“死机”的汽车，将成为智能汽车普及道路上的重要一关。
　　汽车“死机”
　　在1998年的计算机博览会（COMDEX）上，微软创始人比尔·盖茨曾表示：“如果通用汽车像计算机行业一样紧跟技术更新节奏，那我们都将驾驶25美元的汽车，而且每1000英里只需一加仑汽油。”之后，通用汽车给出了一篇回复表示，这辆25美元且超节油的汽车，将每天无理由失控两次，“操控车辆转向或倒车时，可能导致熄火并拒绝再度发动……毫无理由将你锁在车外……必须使用通用汽车牌导航地图，否则车辆失控次数会增加……每次通用汽车推出新车型时，车主必须重新学习驾驶方式。”
　　如今，“老笑话”正成为新现实。汽车“死机”正越来越多的见诸于媒体。2019年，一辆蔚来ES8在行驶过程中OTA升级时当场黑屏“死机”，不仅无法启动，且连车窗也无法升降，影响北京长安街交通一个小时;今年1月，美国NHTSA国家公路交通安全管理局致信特斯拉，由于中控屏MCU故障，要求其召回15.8万辆Model S和Model X。
　　“智能”导致的缺陷问题并不仅局限于新造车势力。市监总局缺陷产品管理中心汽车召回管理部主任肖凌云提供的数据显示，2013-2018年的汽车召回案例中，与汽车智能系统和功能相关的召回共有20次，涉及20.69万辆;涉及软件的召回次数109次，召回车辆191万辆，呈明显上升趋势。
　　显然在机械功能日趋完善的同时，软件系统的功能安全作为汽车质量的另一大门槛，其重要程度正愈发凸显。
　　究其原因，一方面是智能汽车中的软件占比相比传统汽车正在大幅提升。如可实现L2级驾驶辅助、智能座舱、语音助理、OTA等现阶段功能的智能汽车实现代码量相较传统汽车增加了十倍左右。
　　另一方面，则是由于智能汽车内部功能区域不再“泾渭分明”。当前汽车的电子电气架构正在由传统的分布式电子控制单元（ECU）向域控制器架构逐步升级，汽车动力域、座舱域、底盘控制域、自动驾驶域等功能需求正在逐步形成。“这种转变使得原本清晰的软件开发边界变的模糊，软件的耦合性变大，软件的复杂度也随之大幅增加。”中国汽车工业协会（以下简称中汽协）秘书长助理兼技术部部长王耀表示。
　　如何打造车规级软件
　　事实上，在智能汽车大行其道之前，汽车产业已对软件质量高度重视。
　　“随着系统技术复杂度、软件规模、机电部件的不断增加，由系统性失效和硬件随机失效导致的风险也在增加。”2011年针对电子电气系统安全相关的国际标准ISO26262发布，其开篇这样论述道。
　　而且，早在2005年，由欧洲20多家主流汽车制造商共同制定的ASPICE（Automotive Software Process Improvement and Capacity Determination，汽车软件过程改进及能力评定）就已发布，在欧洲汽车行业内被广泛应用。近年来，随着软件在汽车研发中的比重不断增加，ASPICE也被引入国内用以指导车载软件开发流程，改善软件质量。此外，包括车载软件的功能安全、网络安全都已有相关技术标准。
　　尽管已有相當严苛的流程指导和技术标准，但软件数量和复杂程度几何级增长的智能汽车，仍将打造“万无一失”的车规级软件的难度推到了新高度。
　　一方面，可靠性验证的内容和手段更加复杂。中国汽车技术研究中心有限公司的专家表示：尽管汽车行业软件开发依据统一代码书写标准和统一软件架构标准并基于模型设计开发，但软件代码撰写难度仍较大，无法有效及时保证其代码质量。因此，智能汽车相比传统汽车在可靠性验证上不再只关注车辆动力和底盘性能，同时需要验证车辆信息安全、功能安全、数据安全、驾乘安全和软件升级安全等多方面的可靠性和安全性。
　　另一方面，这是场时间金钱与可靠性之间的博弈。王耀指出：遵循ASPICE等相关流程和技术标准，可有效保证汽车软件的可靠性，“但未来随着汽车软件代码剧增，如果未来所有的汽车软件开发完全遵循上述的开发流程，汽车的研发周期以及研发成本将倍增。目前IT领域比较流行的敏捷开发模式虽然可以实现快速交付，但这种模式如何有效保证汽车系统级软件的质量，迭代频次一旦过高是否同样会带来软件开发成本过高等问题仍需要行业进行思考。”
　　谁来“造”汽车软件？
　　保证智能汽车的软件质量，不仅受制于量大、复杂、要求高的自身特性，同时还因开发者的边界愈发模糊而变得更加困难。
　　传统汽车开发流程中，主机厂只需要定义零部件信号接口，由零部件供应商根据定义提供软硬件一体的解决方案，主机厂更多的工作是做系统集成，无需关心零部件中的软件是如何实现功能的。
　　而智能汽车则打破了这一线性的合作模式。在引入域控制器甚至中央计算平台之后，各部件功能高度融合，“软硬分离”成为汽车行业共识。与此同时软件产品也已被进一步细分为软件工具链、基础软件、软件中间件、应用软件等产品。
　　由此，行业开发分工进一步明确，产业链上各方都开始“重新学习”。王耀表示，此前站在供应链核心位置的硬件Tier1需要具备一定的软件开发能力，如提供外设驱动及编译工具、底层操作系统等;曾处于第三甚至第四级供应商位置的“外行人”IT领域软件供应商，则需进一步了解智能汽车，具备更深与更广的软件开发能力;而主机厂除开始将硬件和软件产品分开，进行独立招标外，还需要拥有强大的系统架构、硬件架构、软件架构和通信架构的能力，并对总体集成负责。
　　但在产品端“软硬分离”的同时，行业端的“软硬融合”则成为了新的挑战。2020年底率先在汽车行业爆发的“芯片荒”中，“芯片不懂汽车、汽车不懂芯片”便成为困扰双方协同破除芯片紧张压力的阻碍之一。
　　“目前汽车行业内还没有形成应用于量产自动驾驶汽车产品的汽车软件架构及相关接口定义。同时，自动驾驶汽车的软件开发过程融合了IT领域软件开发技术和汽车领域软件开发技术，大量的跨域协同工作也增加了软件的开发难度。” 王耀表示。
　　如何监管软件质量？
　　“相较于传统汽车，智能汽车在车辆稳定性、一致性方面均需要满足更高的要求。”王耀表示：在车辆稳定性方面，智能汽车的自动驾驶系统从设计之初便增加了功能安全与预期功能安全的要求，通过核心器件冗余备份和提升性能边界等手段来保证更高的系统稳定性。
　　一致性方面，车辆测试与认证要求在相同测试场景下智能汽车完成的驾驶动作与行驶轨迹须保持高度一致，这对于智能汽车的摄像头、激光雷达、毫米波雷达、电控单元以及线控执行机构等电器元件的软硬件质量一致性提出了很高的要求。同时，智能汽车在生产，制造时要面对更加复杂、严格的出厂质量检验要求。
　　但仅凭行业自律显然不够。近年来，随着智能化成为汽车产业转型方向的共识，相关国际组织和国家也正紧锣密鼓的制定相应的标准和监管方向。
　　“第三方监管一定要站在公平公正第三方的立场上，服务于国家、企业和消费者，为行业进行监督。”中汽中心的专家向记者表示：首先，要引导企业强化自身的软件安全意识与安全保障能力，迅速建立OTA升级管理体系，并具备覆盖全流程的升级实施能力、信息安全保障能力、软件质量管控能力、升级测试验证能力、升级过程信息记录存储能力、风险防控和应急响应能力等;然后，针对汽车软件的功能不同进行分类，如哪些是影响车辆驾驶的安全性，哪些是提升车辆舒适性等。不同的功能分类，其风险定位以及监管力度以及手段也是不一样的。此外，在确保规范后，应对企业的开发流程和使用过程进行一定的监督，评估、验证企业内部的相关文件以及记录，确保其可供调取和检查。
　　对于创新技术下诞生的新生事物，容错与监管同等重要。这一道理对于攸关产业未来命运，也关乎普通消费者生命安全的智能汽车尤为重要。如何兼得创新与安全，将是产业、行业与政府共同面临的课题。