一键了解汽车OTA技术（一）

什么是汽车OTA？

OTA即Over The Air，翻译为中文即空中下载。有句话叫：”太阳底下没有新鲜事”。OTA这个概念在IT领域里，尤其是在我们常用的PC端windows系统里和智能手机里都是很常见的。无论是windows系统的更新，还是智能手机中应用商店里，都可以看到OTA的身影。

那OTA在汽车领域又是怎么应用的呢?汽车OTA的完整定义为：在满足汽车高安全性、良好用户体验等需求的基础上提供远程数据管理或软件升级服务的技术。汽车OTA狭义上理解为“汽车软件远程升级技术”，也细分为FOTA、SOTA等，其中“F”和“S”分别是“firmware”和“software”的缩写。

OTA技术在IT领域应用的已经很广泛了，但是在汽车上的应用，大概是在近五年内才逐渐发展成熟、壮大起来。

汽车OTA是“互联网+”的一种应用，即“互联网+汽车”，是智能网联技术在汽车上的重要应用，也为软件定义汽车这一理念的落地提供了支撑。软件升级在过去的十几年里逐步成熟，早期的多媒体系统就已经具备联网的功能，早期连接2G、3G的网络，现在连接4G、5G的网络，天然具备了联网的“基因”。其实，多媒体系统是IT技术手段在传统汽车领域应用最多的一个控制器，因为一般情况下，多媒体系统会自带操作系统，所以具备OTA升级的技术基础。由于软件体量较大，地图包等升级数据量较大等因素，为了满足软件升级的需要，很多多媒体供应商会根据自身产品的特点自主开发OTA升级的技术，这种OTA升级应该说是OTA升级技术在汽车领域应用的雏形，我们称之为ECU级OTA。

对于没有操作系统或者没有联网功能的ECU，OTA技术的实现会基于OBD接口连接诊断，基于车内的总线网络，通过UDS来实现内部软件升级。

没有汽车OTA之前，整车厂把车卖出去之后，软件升级召回的需求首先需要得到4S店的支持。整车厂需要先出一个详细的指导文件，流程说明等等发给4S店，4S店再通知车主把车开到店里，会有专业的技术人员用专业的设备对软件进行升级。这种情况下，车主需要耗费时间把车送到4S店，可能会排队等待，升级好之后把车开回，用户体验实际上不会那么友好。有了OTA之后，软件升级过程变得非常人性化，传统4s店的工作可以通过技术的手段，由OTA系统的某个或某些部件自动完成。

为什么汽车OTA会比IT OTA发展要晚呢？汽车OTA与传统OTA有什么区别？

传统的基于PC和基于手机实现的OTA，技术很成熟。汽车OTA和3C产品OTA的差别在于以下几方面：首先，从内部的软硬件架构来看，手机和电脑内部的软硬件架构是一种“All-in-one”的方案，他们内部的控制计算都集中在整个的单一处理器里面，那么对他们的升级，比如对windows操作系统的升级，安装包下载之后，最终只安装在一个地方，即安装在系统硬盘里，而不会对多个设备进行同步升级或软件包的下载，他们的升级载体是相对单一的；对汽车而言，目前的架构是还是由多个ECU来构成，虽然现在汽车架构在从分布式架构向集中式架构发展，但集中的程度远远不如PC和手机。畅想一下，如果未来汽车也可以像电脑一样，一个控制器解决所有问题，那不论对整车控制还是OTA实现，都是最理想的情况。到那时，汽车OTA的设计就会接近于电脑和手机OTA的设计。其次，对不同的载体而言，OTA考虑的重点是不一样的。对整车来讲，需要考虑人的安全，因为汽车最基本的定位是交通工具，载着人在路上行驶到达目的地。如果说升级过程影响了人的安全，或者汽车可以很容易地通过升级的通道被入侵，那就违背了对整车最基本的功能定位。另外，可能还会有用户体验等方面的考虑，也是使汽车OTA和传统IT OTA不同的原因。

汽车OTA技术架构主要有哪些？

汽车OTA的架构离不开整车的电子电器架构。汽车架构类似于人或者建筑的骨架，而OTA是利用了整车架构的一部分要素来实现远程升级的功能。目前应用比较广泛的OTA架构有两种：

分布式架构：车内刷写时诊断工具通过OBD诊断口接入整车网络，一般通过DoIP/DoCAN等协议与整车网关交互，一级级的通过网关形成分布式的架构。这种分布式结构通常通过UDS诊断协议来实现OTA车内数据交互，因为早期车内刷写基本都是基于UDS诊断实现的，很多厂商会在这个基础上兼容OTA升级技术。

SOA架构：OEM全新的打造基于SOA架构的汽车，电子电器架构从分布式朝着域集中式发展，控制器的控制权越来越集中，整车最终的架构可能会变成车云一体，整车的控制计算大量放到云平台上实现，车端则有一个中央控制器（另外可能再规划数个区域控制器），其他的一些节点只做一些传感和执行工作。对于这样的架构就可以利用SOA来实现OTA。比如说，引进SOA的一些协议，例如http，SOME/IP等来进行OTA的设计。

域控制器作为OTA master 有什么要求？

首先，OTA master在OTA升级过程中要充当诊断仪的角色，所以对其的存储功能有一定的要求。因为在并行升级（或者整车多个ECU同步升级）过程中，需要下载并储存大量的升级包，所以要具备较大的存储空间。当然，升级流程的控制和升级包存储也可以放到两个ECU中，需要时负责存储的ECU把升级包传回到OTA master中或者直接传给需要升级的ECU。但是，为了节省时间，提高升级效率，OTA master最好是具备一定的存储空间，简化升级流程。

其次，OTA master需要具备一定的计算能力和计算效率。因为在升级过程中会涉及到对数据包的解码、验签、解密、校验等，所以域控制器的算力需要跟得上。另外，针对一些并行升级的需求，域控制器也需要具备多线程处理的能力，能够并行的控制多个ECU的升级流程。

当然，在升级过程中也可能会涉及到其他的方面功能设计，比如人机交互，与整车其他ECU协同进行安全防盗的管理，能量管理等等，就需要放到实际的应用场景中进行分析讨论。

车辆并行升级是怎么实现的？

如果在汽车升级过程中，例如通过OTA master，Gateway对CAN ECU进行升级，由于CAN本身波特率比较低，升级时间比较长，如果通过one-by-one的方式来升级，总的升级时间会非常可观。在这个过程中，对某一个ECU进行升级时，总线的利用率实际上是不高的，如果在对一个ECU执行升级流程时，在ECU处理升级指令或数据间隙同时启动对下一个ECU的升级流程，以此类推来支持多个ECU的升级。对单个ECU而言，这个升级过程是单线程的，但是OTA master则需要同时处理多个升级任务，这样就可以实现并线升级，有效利用总线带宽、一定程度缩短升级总时间。

实车OTA测试要测什么内容？

在实车测试中，测试人员更多地是站在用户的角度来做测试。比如车辆在真实环境中的功能体验，用户交互的流畅度等等。实车测试会对不同的场景进行模拟，例如网络状态变化对OTA升级的影响、预约升级设置的安装时间点用户正在用车这种场景下的OTA行为，再比如人车交互在实车环境中的感受这一类偏向主观体验的场景，需要根据经验和人的主观判断进行评估并提出合理建议。