automotive OTA update system test requirement analyze

汽车OTA更新系统测试分析

• 汽车OTA能有多复杂
• OTA哪些地方必须测
• OTA测试的难点
• 参考链接

汽车OTA能有多复杂

汽车OTA升级跟移动终端（如手机）和物联网终端（如智能门锁）的升级一样，都是一种软件升级方式¹，该技术的最初目的是为应对行业内召回法规、产品定期维护和解决客户抱怨²。其中，质量问题强制召回是最主要的原因，因为随着汽车保有量和车内代码量的增长，传统的线下修复模式已经难以为继。

车联网概念渐起的这十多年间，OTA在汽车敏捷转型和软件定义汽车的研发热潮下，逐渐成为汽车必备的产品特性。与其他工控和消费电子产品不一样的是，汽车软件的升级控制对安全性（Safety）和保密性（Security）要求更高³，因为其涉及的用户数量规模、系统复杂性、和应用场景危害，在功能研发阶段有更多的要求。

典型OTA长什么样

汽车OTA是什么，可谓千人千面。

在用户的看来，车主可以说OTA功能是一个简单的App，通过车机大屏或手机提示信息，触发汽车执行软件升级。其实很多情况下升级可以是全自动的，但出于"用户为看得见的东西买单"和"人必须控制机器"方面的考虑，人机交互和手动授权常常是必须的。

站在车厂的角度，可以将OTA系统二分为车端和云端。云端一般由车厂OEM部署在自建的私有云或租用的公有云服务器上，车端则涉及车厂所生产的众多汽车品牌、车型、版本，由OEM定点选型的供应商按批次供货装配。ICT产业中作为管道的基站设备和无线通信服务商，作为成熟稳定的基础设施存在，在不出国门的情况下，并没有太大的选择空间。产品能做到像水一样无处不在又不可或缺，无疑是最成功的。安全可靠的OTA之于汽车软件，未来可能会像ICT之于移动互联网，数字货币之于电子商务一样重要。

而对于车内终端供应商来说，车上OTA相关的控制器终端可以进一步分为两类⁴：主控节点（Master ECU）, 目标节点（Target ECU）。实现整车所有控制器的OTA是有难度的，早期OTA往往只是个别软件迭代速度比较快的ECU才需要。需要注意的是，ECU节点在软件实现和部署上，与控制器MCU/CPU硬件芯片中的Core核对应，因此一个控制器硬件盒体内，可能有多个网络拓扑节点。如TBOX常常即作为Master主控节点分发升级包，也作为Target目标节点被后台升级。OTA主控节点一般位于车内网关上，按照DoIP的定义，负责与车外进行诊断通讯的网关，称为边缘网关（Edge Gateway）。在这里，主控节点或边缘网关供应商，在整个OTA车载系统中发挥了核心作用。

从系统配置维护人员的角度来看，OTA就是一系列软件和数据配置更新的过程，从云端传递到车端的镜像文件内容⁵，既可以是针单个控制器的软件包，也可以是整车系统软件包。如果将车内控制系统按功能域（Domain）或功能安全（FunctionalSafety）相关来划分⁶，还可以是针对EEA架构子系统的软件包。关键的是，对于在后台服务器打交道的维护人员来说，软件包之间是有复杂配置选型和版本依赖的关系网络⁷，如果没有详尽的发布测试或谨慎的版本管理，很可能造成大规模故障。尴尬的是，手机更新出错，用户大多会归咎于自己操作错误自行重试；汽车更新出问题，往往都会默认为是车厂的原因，需要对此负责。

系统功能如何考虑

包括汽车，在所有智能终端中OTA早已不是新鲜事物，但也不像机械产品长期一成不变。
AUTOSAR定义的两个平台（AP/CP）中，符合不同平台规范的网络节点，其OTA相关模块中参考规范也不同：

• 更新及配置管理(UCM, Update and Configuration Management)⁸
• 固件远程升级(FOTA, Firmware Over-The-Air)⁹

UCM需求规范从AP-R17（自适应平台2017年发布）版本开始引入，目前已更新到AP-R19版本。值得注意的是，UCM这里配置（Configuration）的概念，既有CMMI配置管理（CM, Configuration Management）中版本控制的意思⁷，也有开发构建过程中Pre/Post-Build Configuration和部署运维过程中Runtime Dynamic Configuration的作用。

对于很多传统汽车电子工程师而言，OTA=UDS+FBL+TBOX¹⁰。FOTA作为经典平台CP-R19才引入的模块，其底层基础模块需求如DoIP、Dcm等在早前的CP版本中就已经稳定。值得注意的是，早期通过OBD接口有线连接的方式进行的刷写（Reprogram/Reflash），一般都是针对Firmware固件的更新，文件大小最多也就几十K，几乎不存在Runtime Dynamic Configuration的可能性。面对未来SOA架构演化和域控应用集中趋势的挑战，OTA对配置的需求会越来越复杂。

从汽车协议栈模块相关需求清单中可以看出，除版本回滚和签名认证外，市面上听得比较多的AB备份切换、差分数据传输在AUTOSAR中还不是必须的，出于稳定、可靠、安全的考虑，未来车上可能出现的OTA功能包括：

• 应用于整车各网络的多点并行升级
• 用户可自定义触发条件的预约升级
• 用户个性化配置备份及热切换升级
• 带入侵检测及防护功能的系统升级
• …

汽车软件生命周期

在产品有限的生命周期内，用户除关注实用功能外，也关注流行时髦的特性。2-3年前设计出来的车，要在10年的使用寿命中不断给用户带来新鲜和惊喜，老实说，还不如租车或换车来得方便。
汽车升级更新从"几年一次"的机械产品进化到"一年几次"的软件产品，要解决的不仅是显见的后期配置维护过程中发布管理问题，还有前期研发测试过程中的系统功能设计和版本配置定义。
现在无论软件研发和UI设计所占比重多大，只要人车交互主要还以自驾为使用场景，必然要求汽车软件的升级更多是以安全、可靠为目的。或许只有在突破自动驾驶和共享用车的瓶颈后，汽车软件更新才会以社交和娱乐为目标。
奢谈DevOps或Agile研发模式，对于目前软件工程师占比极低的车厂研发部门来说，是不明智的，短期内能提高HIL自动化测试和整车CI持续集成水平，会更实际一些。

OTA哪些地方必须测

眼下对于整车OTA，很多车厂非不能，实不（敢）为。要想让汽车软件具备不断更新的能力，集成测试和发布测试是必要的过程。OTA系统测试往往是主机厂的难点，也是供应商的盲点。

数据通路

按照AUTOSAR的描述⁴，汽车OTA升级过程可分为7个步骤：授权、上传、活动编排、下载、安装、验证、激活或回滚、报告。按照测试覆盖的要求，针对任何OTA使用场景的测试，要能拆解成针对上述步骤的测试用例。

主要的数据通路可以分为：云端通路；车云通路，车内通路。以第5步下载过程车内通路为例，主控和目标ECU之间数据传输的过程就可能涉及不同总线连接（CAN、CANFD、LIN、Eth、FlexRay），不同网络拓扑（网关直连、跨网路由），不同运行工况（静态闭锁、静态充电、静态远程启动、动态低速等），不同操作权限（工厂产线EOL、维修店修复、试驾体验切换、用户自定义更新），不同更新范围（单节点串行、单网多节点、多网多节点）等多种组合工况的测试要求。

并发性能

云后台系统的建设，性能上主要考虑传输时间限制和并发控制弹性的要求。基于当前车联网TBOX的渗透率，考虑当前具备OTA车型的保有量，其实对后台服务器并发控制的要求并不高，即便是在软件安全隐患或紧急漏洞修复的特殊情况下，同车型多批次的远程更新也是一种可接受的方案。相较之下，产线EOL生产节拍要求下的整车软件更新，和研发过程中路试车队高频软件补丁修复，对服务器的并发控制性能要求可能会更高¹¹。

信息安全

随着技术的进步，没有一个老系统是绝对安全的，能否保证信息安全，关键看IPDS安全系统能否与时俱进。OTA带来便利的同时，信息安全的风险也在不断扩大，在智能汽车生态系统的各个受攻击面上，漏洞与新功能总是同步增长¹²。传统PC领域的防火墙、入侵检测防护系统或杀毒软件、可信的软件更新源，也在随着OTA一齐在汽车技术生态圈中落地。

OTA测试的难点

能仿真吗

作为分布式或集群式的控制系统，模块隔离和仿真验证是必要的测试手段。整个OTA系统中涉及的仿真子系统包括：用户终端仿真、应用服务器仿真，无线网关仿真，车内节点仿真。除车内通讯外，其他系统的仿真系统并没有太高实时性的要求。
成熟的仿真测试区别于原型控制系统最主要的不同之处在于，测试系统能否在各个位面做故障注入。功能原型开发的工作量是1的话，仿真测试系统需要投入的研发至少是5以上。

能自动化吗

手机和PC行业的测试驱动开发，服务器软件和网站应用的CI/CD，都是以研发工具链高度集成和标准化为基础的。汽车上大量使用的控制器芯片还在从MCU向CPU过度，调试和测试过程涉及大量品牌繁杂的工具设备，对测试自动化实施过程中的工程服务提出了的挑战。

能迭代下去吗

作为一项覆盖了车内近百个电控单元和后台数十台服务器的系统功能，OTA自身的升级维护就是一个需要精细控制的系统¹³。
想一想我们多久换一次手机或家电就能猜到，在整车十年设计寿命的使用过程中，智能汽车至少会经历2-4次局部电子器件的升级或更换。现有OTA技术架构和应用生态要想兼容未来的发展要求，还有很大的不确定性。

未来的挑战

车内硬件型号碎片化，导致软件移植和版本维护工作量扩散
前期信息安全设计缺失，导致难以弥补的信息安全隐患
按需付费对升级的限制，导致功能锁止和性能退化

参考链接

---

1. 《Telecom and Automotive - through Standards》, OMA, 2017.载于: https://wiki.openmobilealliance.org ↩︎

2. M. Shavit, A. Gryc和R. Miucic, 《Firmware Update Over The Air (FOTA) for Automotive Industry》, 8月 2007, 页 2007-01–3523, doi: 10.4271/2007-01-3523. ↩︎

3. H. Roger和T. Symphony, 《Keeping the Connected Car Current with SOTA/FOTA》, 发表于 Automotive Linux Summit, September 19th, 2012. 载于: https://events.static.linuxfound.org/images/stories/pdf/als2012_hampel.pdf. ↩︎

4. 《Explanation of Firmware Over-The-Air》, AUTSOAR, 945, 2019. ↩︎ ↩︎

5. 《Specification of Update and Configuration Management》, AUTOSAR, 888, 2019. ↩︎

6. U. E. Larson, P. H. Phung和D. K. Nilsson, 《Vehicle ECU classification based on safety-security characteristics》, 收入 IET Road Transport Information and Control Conference and the ITS United Kingdom Members’ Conference (RTIC 2008), Manchester, UK, 2008, 页 102–102, doi: 10/gg879f. ↩︎

7. C. Heinisch, V. Feil和M. Simons, 《Efficient configuration management of automotive software》, 页 10, 2004. ↩︎ ↩︎

8. 《Requirements on Update and Configuration Management》, AUTOSAR, 887, 2019. ↩︎

9. 《Requirements on Firmware Over-The-Air》, AUTOSAR, 944, 2019. ↩︎

10. 《Software Update and Upgrade Over the Air (SOTA)》, 发表于 Vector India Conference 2019, Pune, 2019. ↩︎

11. https://mp.weixin.qq.com/s/RA0ut3tZVaGVTvqvGX0Gbw ↩︎

12. 《Connected car cybersecurity in the era of new regulation》, McKinsey. https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/the-race-for-cybersecurity-protecting-the-connected-car-in-the-era-of-new-regulation. ↩︎

13. 《Driving Data to the Edge: The Challenge of Traffic Distribution》, AECC, 2019. ↩︎

本文地址：https://blog.csdn.net/spacecraft/article/details/108830825