汽车在线升级OTA，从安全驶向更安全

2022年11月，特斯拉召回了40,000辆汽车，原因之一便是在汽车在线升级（OTA，over-the-air）中发现了一个错误，从而导致汽车在道路上遇到坑洼或颠簸后出现动力转向的问题。

两年前，本田曾召回60多万辆汽车，原因是软件错误导致仪表盘速度读数错误，和后视镜摄像头视频出现问题。

梅赛德斯也曾召回130多万辆汽车，原因是应急位置追踪器代码出现故障，最后是通过OTA完成了故障修复。
今天就跟大家好好聊聊关于汽车OTA的那些事。

为什么OTA很重要

OTA发挥作用的地方很多。当车辆出现故障后，传统的召回流程可能需要数月的时间，而且无法保证能够完成，或者要等到车主碰巧前往4S店或修理店，才能侥幸完成。OTA远比召回更具成本效益。

通过OTA，制造商不仅可以确定车辆是如何做出反应的，还可以确定做出这种反应的原因究竟是软件错误、不当的软件更新、还是操作参数的调整导致了事故……通过OTA，制造商能够深入了解车辆的操作情况，还能在无需车主前往4S店或修理店的情况下轻松地解决问题。OTA功能有着巨大的优势，而且能从根本上节省成本，但糟糕的实现或不当的软件开发实践却可能会导致代价高昂的错误。

此外，“网络攻击”也是许多人最关心的问题，OTA功能为其提供了应对之道。

不管导致车辆出现问题的原因是软件错误、不当更新还是网络攻击，对消费者来说并没有什么区别。制造商可以大规模执行OTA，在出现网络攻击或测试不佳的更新等不利局面时，这可能会影响数十万辆汽车。与传统的召回流程相比，OTA是一条能够更快、更直接地解决问题的重要途径。

在大多数情况下，汽车OTA对车主来说是无缝体验。OTA的透明性质更大限度地减少了需要车主前往当地服务经销商所需的行程以及给车主带来的时间损失。除了信息安全和软件安全修复外，更新中还可以添加一些汽车在制造时所没有的增强功能，以改善驾驶体验，或者在某些情况下延长车辆部件的寿命。OTA可以提高驾乘的安全保障，并且会随着技术的不断发展而做出调整，其代码数量达数十亿行，由此增强了软件定义的自动驾驶汽车的互联性和融合性。

考虑到这些新功能和OTA本身，车辆的整体攻击面会相应增加，出错的可能性也随之增大。

在出现问题时，OTA是一个很好的解决方案，但规模和速度却成为决定硬件和软件开发实践能否成功的关键。鉴于当今的技术复杂性和风险之多，这里列出了一些方法，以帮助开发者在部署OTA之前更好地保护系统并更大程度地减少错误。

解决系统基础设施和流程创新问题

OTA比较复杂。它们并不是一个简单的解决方案，并不是封装在一个简洁的盒子里，随时可以部署。因此，务必要关注交付软件的底层系统基础设施，以及适当的流程和检查，以验证一切在任何情况下都能正常工作。事实上，要想得到一个有效的OTA计划，需要开展大量活动。这些活动通常分为三类：

1.稳健的公钥基础设施

虽然大规模密钥管理已经出现了一段时间（比如零售业中的信用卡应用），但对于汽车应用来说，这仍然是一个相对较新的概念。例如，正确管理汽车PKI会涉及到多方面的技术和广泛的参与者，包括汽车制造商、OEM以及协助打造OEM解决方案的关键基础设施管理机构。

不法分子可能会伪装身份，甚至是窃取身份验证密钥，以提供感染病毒的软件或在入侵期间阻止服务访问。遭到入侵后再设法处理就不是一件容易的事。这时要撤销的不是数百个密钥，而是整个供应链中的数万到数十万个密钥，然后再重新发放。这只是其中的原因之一，毕竟确保PKI安全是一项涉及多学科、多组织且需要各方充分参与的工作。

要想获得成功，打造一个可用于测试和评估流程的仿真环境至关重要，因为现在并不是攻击是否会发生，而是何时会发生攻击。PKI计划应包括对攻击者可以利用的各种故障条件和极端情况进行测试。该计划还应遵循ISO/SAE 21434实践，以确保相关过程是开发计划的一部分，并会随着软件特性和功能的发展而发展。

2.定义明确的软件验证与确认实践

在软件验证与确认流程中，开发者需要综合考虑软件开发的方方面面。其中一个发展迅速的领域就是用于软件测试的硬件虚拟化。鉴于软件的快速变化和参与其中的开发者人数，开发周期的早期不可能有足够的硬件测试台来有效地测试软件。虚拟化硬件允许进行硬件仿真，它们可以集成到CI/CD管道中，并提供给更广泛的开发受众使用。这其中还包括后期制造环境的开发。硬件访问要容易得多，但由于硬件数量、空间限制等原因以及缺乏相关专业知识，这一切很快就变得不切实际。

利用新思科技的Virtualizer™等虚拟化技术和其他仿真技术，开发者可以在受保护的环境中快速交付单元级和系统级测试。这种形式的测试在一定程度上增加了软件测试周期的严格性，降低了测试软件与所部署软件之间出现纰漏或发生意外交互的可能性，而这在传统测试环境中是不可能的。

3.高效的车辆软件部署、存储与激活

即使进行了最强大、最全面的测试，也还是会有这样或那样的问题。原因可能包括部署后的指示不清晰、意外交互或售后调整。各种情况可谓层出不穷。重要的是要有适当的保障措施和适应性强的做法，以处理各种各样的问题和状况。

制定更新的验证与确认政策是关键。的确，许多组织都制定了此类政策，但他们是否考虑到了部分失败的部署？他们有没有想到“开箱即用”？更为关键的是，虽然一些简单的步骤（例如代码签名检查）很重要，但对错误平台部署的简单检查却要困难得多。

在将更新推送给车辆后，更新的存储和激活必须要做到尽善尽美。更新的软件存储需要架构方面的决策，例如车载存储空间和闪存的大小。多大的空间够用？对于车辆的使用寿命来说，该空间是否大小合适？它是否适合特定内存类型的读写次数？这些决策都将对软件更新的数量、频率和大小产生影响。如果内存不足，便无法存储当前固件的副本以进行回滚。而如果内存过大，则可能造成制造成本攀升。