OTA不是“安全良药” 自动驾驶软件冗余才是根本

　　随着越来越多的智能化汽车的量产上市，在业内看来，软件驱动汽车的时代已经到来。但软件驱动的关键作用越来越突出的情况下，软件安全也需要列入汽车安全评级的目录中，甚至应该被视为“第六星级”。

　　根据此前数年的汽车召回案例统计数据，软件故障导致的汽车召回频率正在快速增加。有数据显示，在所有汽车召回中，软件故障比列的达到了15%，而且在未来数年，这样的比例还有可能快速上升。

　　在目前的量产车中，软件代码多达1亿5000万行，而且随着智能化功能的逐步叠加，代码数量还会呈几何数增长。按照目前业内普遍的观点，平均每1000行业代码中会存在15-50处错误，而目前普遍使用的标准QA测试至少会忽略其中大约15%的错误代码。

　　目前，在汽车软件安全领域，还没有出现绝对的市场领导者，相比传统汽车时代，各家汽车OEM厂商在硬件领域的安全口碑并未在智能汽车时代延续。

　　在过去的一年时间里，由于软件故障，从发动机管理程序、稳定性控制问题、制动控制系统以及车载信息娱乐系统，经历了数次召回事件。

　　美国市场在过去五年中共发生189次汽车软件问题致使的召回事件，涉及1300多万辆汽车。这些召回中，有141次召回与碰撞风险有关，44次召回与潜在损伤后果相关，涉及动力传动系统、电气系统、发动机冷却系统和车辆控制系统方面。

　　但这也给了汽车OEM厂商新的市场机会和新车营销卖点，那就是像过去标榜自己的硬件配置及安全性的基础上，如何把自己的软件安全提升为一个新的营销卖点。正如传统汽车时代，消费者不会考虑购买没有配置更多安全气囊的新车。

　　这其中，首先是ISO 26262（道路车辆功能安全标准）是根据汽车行业特点而产生的功能安全应用标准，它从可编程电子电器系统的功能安全标准IEC 61508发展而来。

　　以ISO 26262-6中的软件级产品开发为例，这部分的核心内容包括：软件级产品开发初始化软件安全需求规范软件架构设计软件单元设计和实现软件单元测试软件集成和测试软件安全需求验证。

　　在目前的自动驾驶开发策略中，硬件冗余是行业内普遍认可的方式之一，但软件冗余似乎并没有成为重点的一环。同时，硬件冗余通常非常复杂，而且会产生间接成本，是对资源的不合理使用。

　　“不同阶段自动驾驶功能的实现，要结合不同路况、天气等因素，从感知、定位、规划、执行等多方面进行冗余设计。”博世底盘控制系统中国区销售总监段勇在2017高工智能汽车年会上发表演讲表示。

　　比如，不同级别的自动驾驶功能还要进行不同的冗余设计，如果自动驾驶功能一旦失效，最好的是能把车驾驶到安全地带并舒适停车。

　　与此同时，不同的标准体系反应安全等级的方法也各不相同，但其主要目的是直观的反映功能的关键性。

　　IEC 61508将安全完整性等级（SIL）分成4级，第4级为最高完整性。与之相似，ISO 26262提出了汽车安全完整性等级（ASIL），最低为ASIL A，最高为ASIL D。

　　其中，车载诊断系统、OTA软件升级等等，正在成为汽车OEM厂商和众多初创公司的“营销重点”。尤其是去年开始，OTA成为了标榜“互联网汽车”的重要标签之一。

　　但这都是事后安全机制。当然，对于信息娱乐系统来说，OTA的确是很好的手段来迭代功能的用户体验。但对于汽车的驾驶功能安全来说，汽车出了bug，可能是要以生命为代价的。

　　传统车企都有一整套完善的开发流程，保证严谨和安全，而“新进入”企业，特别是互联网车企和自动驾驶初创公司，往往追求小步快跑，快速迭代，开发时间短，测试过程还不够严谨和周全。

　　同时，由于量产车本身要考虑成本问题，因为很难在硬件配置上做过多的冗余性能。

　　以特斯拉早期车型为例，由于早期车型的配置相对较低，随着软件不断的自动升级，系统开始变得越来越慢了，并且会经常死机，而特斯拉的答复是，要车主自费升级硬件。

　　当然，迫于市场竞争压力的传统汽车OEM厂商，也在不断犯错。

　　今年早些时候，外媒报道宝马在英国市场召回超过30万辆问题车辆，这些车辆被指可能会在正常行驶过程中突然失速。此前，丰田汽车意外加速问题引发全球范围内超过1000万辆汽车被召回。

　　越来越多的汽车制造商使用软件电子控制机制及人工智能技术，造成驾驶者对车辆的直接操控越来越少。这对车辆软件系统提出了越来越高的要求。