布谷鸟产研-超越特斯拉OTA：自适应Autosar之UCM

特斯拉以OTA为特色，传统车厂因为历史包袱和成本因素，很少用OTA，特别是FOTA。新一代自适应Autosar专门为OT设计了UCM服务，降低OTA门槛和成本，同时大幅度提高OTA性能和安全性，让使用者可以轻松超越特斯拉目前的OTA水准。本文由布谷鸟科技-产研首席分析师周彦武老师编写。

OTA即空中升级，一般分FOTA和SOTA。前者为固件OTA难度远高于后者软件OTA，前者可简单看成ECU功能或控制策略的升级，后者主要是应用软件的升级，如导航地图等。特斯拉最早使用FOTA，其OTA供应商是三星哈曼，也是全球最大的OTA供应商，几乎垄断FOTA市场。三星哈曼OTA能力来自2015年收购的以色列厂家Redbend，当年收购价格为0.99亿美元股票和0.71亿美元现金，仅1.7亿美元，收购价格可谓相当低。Redbend也是手机领域第一大OTA供应商，市场占有率超过70%。

并非是特斯拉技术领先其他车厂才让特斯拉拥有FOTA能力，而是绝大部分车厂为了降低研发成本，提高研发成果复用率，减少研发时间，避免新架构带来的风险，绝大部分车厂的E/E架构都很老，传统车厂一般一个车型生命周期是7到8年，而E/E架构延续使用一般是两代，大多是本世纪初的水平。典型的如大众，就算是最新的旗舰奥迪Q8，E/E架构中的Infotainment还是MOST总线，这是1998年的设计了。当然大众已经痛改前非，今年导入全新的MEB平台。特斯拉没有历史包袱，可以使用最新的技术。

实际OTA能力有限，因为目前很多功能受限于硬件的性能，中低端汽车硬件的性能落后手机领域10年以上，甚至15年以上，可能连在板编程或足够的Flash空间都没有。还有很多机械部件的缺陷或错误，当然无法靠OTA解决。想要软件定义汽车对硬件要求极高，那种汽车注定只能是高端车。

典型的先进的FOTA流程分8个步骤，第一步是授权给电信运营商，第二步是将要更新的数据上传到电信运营商的服务器中，第三步是OTA的活动编排，包括与驾驶员和车辆的互动，对比前后软件版本大小，提出差分包，询问驾驶员升级安排。OTA供应商的主要工作就在这个环节。Redbend之所以市场占有率超过50%就是因为其更新包最小，无需考虑操作系统，无需考虑芯片或存储器等硬件限制。第四步是汽车上的T-Box下载更新包，下载后放在中央存储器中。第五步是加载在FOTA主ECU上，也就是中央网关ECU，由中央网关分发到目标ECU。第六步，目标ECU确认无误。第七步是激活，自适应Autosar的FOTA，类似Windows的A/B分区升级，旧软件在A区，新软件在B区，新软件不会对旧软件造成任何中断，检测到发动机或驱动电机关闭且处于驻车状态一次后（即真正重启后），即以B区启动。某些老旧的OTA设计不合理，一旦启动OTA就全车锁死，一动不动。在激活前，ECU会诊断新软件的可靠性或准确性，如果发现有误，则自动回滚到升级前的状态，并将这个错误回报云端。如果准确无误，就激活新软件。第八步，回报云端服务器。

这种FOTA离不开Redbend这样第三方的支持，OEM或Tier1的工作量不小，没有统一的标准。自适应Autosar为此特别增加了一个UCM模块来对应OTA，UCM定义了OTA过程中各种数据格式、接口和流程，让FOTA变得易如反掌，人人都能像特斯拉那样OTA。 UCM即Update and Configuration Management，它通过自适应Autosar的ara::com服务界面实现各种功能，没有直接的API，也就是说任何ECU里都不需要添加UCM。而特斯拉现在有些OTA是需要自己开发API的。人人都能像特斯拉那样OTA，并且比特斯拉更先进。此外，UCM可以将软件包存储到本地存储库中，在此处可以按照UCM Client 或UCM主Server请求的顺序处理软件包，无需等待数据缓冲。传输阶段可以与处理阶段分离，UCM支持不受限制地从多个Client接收数据。这都是特斯拉无法做到的。

UCM类似于Ubuntu里的apt+dpkg或者yum+rpm，比如你使用163的源，然后你apt-get/yum install xxx的时候，就从你的源配置文件中读取位置（这里是163的服务器），然后可能在第一次会更新本地数据库（这个数据库中记录163服务器上拥有的软件包，软件包的依赖情况等），本地更新完了就从本地缓存数据库中读取依赖情况以及软件包的具体url，然后就会下载到本地缓存目录。下载完成后执行安装操作。yum获取到的是rpm，apt获取的是deb，其实你都可以看成是一个压缩包。里面有对应的软件。因为开发者不一样，所以两种软件包的解包方式不一样，和gz，rar包差不多，需要特定的命令去解，rpm包是rpm命令，deb是dpkg命令。

UCM输入的安装单位是软件包。该程序包包含（Container）的一个或多个可执行文件。除了应用程序和配置数据外，每个软件包都包含一个软件包Manifest，该Manifest提供元数据，例如软件包名称，版本，依赖关系以及可能的一些特定于供应商的信息，以处理该软件包。

UCM Master架构，也就是上文里的FOTA Master。

诊断Client上传软件包(Software Package)通过UDS服务。之后经过分解和确认步骤进入到OEM的OTAClient里，之后再进入UCM里进行进一步处理。

UCM升级的全局状态机如上图，跟普通的FOTA类似，多了一道清除安装包的工序。

软件Cluster状态机，开始(Initial) 升级软件(们)(SoftwareCluster) 被下载添加(ADDED)进车里的ECU(PRESENT), 然后经过升级(UPDATED)操作成功, 然后继续留在ECU上(PRESENT)服务,可能过了很多年后，又有新的相同功能的软件更新，于是我们就需要把这个之前的软件删除(REMOVED)，之后他就完成了它的历史使命，消失在了这辆车里(Final)。

UCM软件包有普通软件A/B包，类似Windows的A/B分区升级，旧软件在A区，新软件在B区，重启后，即以B区启动，通常由软件集成商提供。还有车辆包和后端包，都由OEM掌控，除了红字部分必须以ARXML格式写之外，其余皆可自由发挥。车辆包的manifest中包含一、依赖关系： Dependencies继承，软件群集之间的依赖关系将取代软件包清单中已定义的依赖关系。通常由车辆系统集成商用来添加与后端包装供应商不知道的车辆系统相关的依赖项。二、Origin，URL，链接地址，用于升级日志，跟踪数据。三、版本。四、车辆目标Vehicles Target描述，包括与驾驶员互动，征求其更新的意见或更新的时间与联网方式安排。五，CampaignOrchestration。运动综合编排。

Integrator必须使用和目标UCM 兼容的打包工具。在集成商装配完可执行apps，数据，Manifest等，接下来这个软件包会和采用ARXML语言写的整体Manifest软件包一起嵌入到后端包中。签名包含在软件包清单中。为了避免软件包清单修改，软件包和软件包清单以及签名应该在一个container中。

安全方面，自适应Autosar自然也很重视，采用的HSM硬件安全模块方式，上图为处理器Flash存储器内部升级流程，DCM为诊断通讯管理器，CSM为密码服务管理器。安全车载通信系统(SecOC)使用CSM对传输数据包中信号值进行加密验证。顾名思义，CSM管理密码服务。通过制造商专用密码库实现。HSMs是由一种防火墙连接到主机系统总线的独立微控制器，大部分现代车载SoC都有。HSM通常有其受保护的内存（RAM），程序代码和数据的专用闪存区，及其外围设备，例如定时器、用于某些密码算法的硬件加速器或用于真随机数的发生器。它能够访问主机的所有硬件。在运行时实现系统的安全、认证启动或主机监测。专用数据闪存可以用来存储秘钥，主机系统无法随意访问。这意味着主机可以请求HSM执行加密操作，而密钥无需离开HMS。然而，在这方面，HSM的特殊优点是它是可自由编程的。作为一个独立的微控制器，HSM能够运行为当前用例优化的任何程序代码。这使得其安全性要求比简单的协处理器更高。

这一切也是有代价的，那就是硬件要足够强大，自适应Autosar中间件会消耗相当多的算力，虽然官方推荐使用20000DMIPS的处理器即可，但要流畅运行并保证足够冗余，推荐40000DMIPS算力的处理器。