汽车整车OTA升级为什么困难重重（OTA升级第一篇）
作者 / 阿宝
编辑 / 阿宝
出品 / abao1990
吃瓜群众问：机哥都21世纪了，手机都能随时随地更新APP或者操作系统，为什么还在讨论汽车整车OTA的事情呢？
机哥：额，这个问题说来话长，那我就长话短说，尽量说的简短有趣一些。
什么是汽车OTA
首先，要弄清楚什么是OTA,我们先来看看各位吃瓜群众的理解
群众A: 机哥，机哥，这个我清楚，无非就是升级打补丁嘛，形象一些，就是衣服穿的破烂了，需要打一个好看的补丁。
曾经机哥在上初中的时候，为了衣服显得酷一些，在好的衣服上也弄一个超酷补丁，现在也有一些车企也在这么做，为了显示自己能OTA，本来没有必要的升级，非得弄的高大上，所谓让用户更有粘稠度。
群众B：机哥，汽车OTA太吓人了，动不动就整“趴火”，这个不太安全吧。在19年1月30日，蔚来ES8在长安街出糗的这条朋友圈截图，火遍了圈里圈外。
机哥回复：也许很多朋友会觉得整车OTA不安全，机哥要在这里郑重的强调一下，对，你的感觉没有错，目前整车OTA确实不太成熟。不过上次那个事件和OTA运营有一定的关系，这个驾驶员，确实有魄力，在长安街这种稍作停留都会引来警察的敏感位置敢于停车后挂P挡，且在不详细阅读提示的情况下进入ES8的整车OTA（记住整车OTA这个词，后面很关键）升级，结果尴尬的被堵在车里一个小时。
群众C：机哥、机哥，OTA我知道哇，这个是好家伙，自从购买了特斯拉以后，隔三差五的升级新功能，解锁新姿势，感觉天天都开新车。
机哥：土豪，我们交一个朋友吧，OTA运营好，确实是主机厂发家致富的一条好道路，正所谓要致富，先修路。
特斯拉官方针对Model3长续航全轮驱动版车型推出了加速提升包服务。这套升级包售价为1.41万元，升级后车辆百公里加速能力可以从从4.6秒提升到4.1秒。车主只需通过OTA升级功能，就可完成升级包的安装升级。此套加速提升包是通过释放Model3长续航全轮驱动版双电机的冗余性能。
不要小看这0.5s，如果是传统汽车，就需要3-4年才能实现，因为要修改硬件参数，要重新设计一款新车，改变发动机相关性能参数，整个车的性能在设计之前就确定了。通过OTA升级，所以特斯拉一辆车让你随时都感觉在开新车的惊喜，竞争力大大提升。
说了这么多，到底OTA是什么，是补丁，是惊喜，是增加新体验，到底是什么呢？为什么有的厂家宣传的是FOTA，有的宣传的是SOTA，有的又说OTA，几个名词有什么区别。
名词解释
从手机到汽车嘛，大家也都知道个大概。解释几个名词吧：
OTA，Over The Air/空中下载，所谓“空中”指的是远程无线方式，指通过移动通信（GSM或CDMA）的空中接口对 SIM 卡数据及应用进行远程管理，OTA 技术可以理解为一种远程无线升级技术。
我们先来看看软件的一个架构，其实可以分为驱动层、系统层、应用层、不同的层级的内容是不同的，而且对于硬件的影响是不同的，就好比你手机上升级失败腾讯视频，不会影响到其他APP功能的正常使用，但是如果你升级整个手机OS软件版本，如果升级不成功，那么就极容易变砖头了，此时需要拿到手机售后维修店进行强制修复。
FOTA说的更容易理解点就是对驱动的升级和对系统的升级。FOTA的升级是涉及硬件的，如果刷写失败，硬件就会变砖。所以，FOTA在技术上还是有一定难度的。汽车上有很多的控制器，车辆在什么状态下进行刷写，如何确保刷写过程稳定，安全，这些实现上的难点都是要考虑的。行业里常规所说的整车升级，就是基于FOTA技术的。原则上，车上任何一个控制器都是可以升级的，但为什么现在很多车还有做到这一点，主要是考虑到稳定性。毕竟，升级生成砖这种事情连苹果都不敢说100%的避免，更何况一辆更为复杂的汽车产品。
SOTA，Software Over The Air/软件空中升级，偏向于应用软件升级。SOTA是在操作系统的基础上对应用程序进行升级，整个过程相当于我们在电脑上对一个程序进行了升级，特别指出只是程序的升级，WINDOWS系统更新打补丁的技术都比SOTA要难。市面上的安卓车机，如果想要对APP进行升级，只要找几个开发和测试就能干完，几乎没有技术壁垒。也许有人问，既然实现起来很简单，也没有什么技术含量，那为什么很多车上都没有呢。最主要的原因是，创建了一个应用市场，关键的点在于应用从哪来。即便是现在也是这样，在导航车机上能使用的互联网应用还是很少，即便是放的最开的后装车机，也没有超过上百个应用。
事实上 FOTA 与 SOTA 界限比较模糊，Windows 操作系统升级、手机升级、嵌入式系统、单片机控制程序等都的远程升级可以笼统地称为 FOTA；转移到汽车电子这块，为了方便讨论，我们将 HU 中的 APP 更新称为 SOTA，将其他 ECU 的更新甚至于所有更新统称为 OTA。
群众C:机哥，你这个解释完，我还是没有看懂怎么办？
机哥：我靠，逼着我出大招了，那我用通俗易懂的方式再解释一遍。
看到上面这个装修图片了吧，类似于装修，FOTA是对驱动和系统升级，这个驱动底层就是你好比你家的涂墙的油漆，布置的走线，地砖的选择、装修的风格，这些都是属于底层驱动。
你家的沙发、餐桌这些都要和家里的这些进行搭配恰当，这个就相当于APP应用软件。
比如哪天你觉得不喜欢这个沙发的样式了，想换一个沙发就行了，这个更换就比较容易，所以SOTA升级是比较简单的，更换一个沙发，如果沙发没有买来的情况下是不允许餐桌的正常使用的。
要是不喜欢这个地砖了，那就比较麻烦，需要把这些拆了重新来，此时你家餐桌、沙发都需要搬离出去，不用使用，只有等地砖翻新完后再搬进来使用，所以FOTA是比较困难的，而且如果你装修期间遇到事情，停下来不装修地砖了，此时整个家里是没有办法使用的，所以FOTA升级失败的话，整个器件相关的APP是不能使用的，风险度会比较高。
汽车厂家为什么热衷于研究OTA
1、软件定义汽车已经形成共识---软件有bug风险也是趋势
全球最大的汽车制造商大众宣布，组建自己的软件部门：数字汽车与服务部（Digital Car&Service），大众CEO迪思在今年的达沃斯世界经济论坛上表示：“在不远的将来，汽车将成为一个软件产品，大众也将会成为一家软件驱动公司”。在汽车行业向出行服务和智能化转型的大趋势下，新的智能功能和服务需求几乎每个月都需要更新，大众的组织变革表明软件定义汽车已经成为业界共识。
计算集中化：服务导向的系统构架（SOA）将成为主流，为软件提供高性能实时计算平台，在这样一个大的理念下，计算集中化将催生真正的汽车大脑：超级中央计算机。目前各个玩家对这个概念的叫法五花八门，包括车载计算平台、主机（Host）以及服务器（Server）等，但本质都一样。
为了满足ASIL-D功能安全的要求，一台汽车通常需要有两台相同的主机互为备份，目前领先的Tier1如安波福、大陆等都使用这样的理念。
伴随着计算集中化，产生了一个新的概念：区控制(zone control)，与目前流行的域控制器概念不同的是，区控制模块没有高级功能决策权，而是完成执行器、传感器、诊断以及传统I/O的连接汇总，类似于PC中的南北桥。
拿军事打个比方，域概念就像是按照职能划分海陆空三军（电源域、底盘域、娱乐域、安全域），并且有独立的作战权，但不能彼此共享资源，而区概念则是按照战区进行组织划分，与中央计算机形成了联合作战司令部+战区的概念，协同性和执行效率将得到质的飞跃。
在这样的构架下，决策通常都是由中央计算机来发出，但是也有例外，比如AEB紧急制动的功能，是最重要的ADAS功能，一旦前向智能传感器发现前方有障碍而且即将发生碰撞，可以不经中央计算机决策指令，直接启动执行机构进行刹车，或者在两台中央计算机都出现故障的时候接管刹车执行器，从而提供更高的安全冗余。
如果我们对照人的决策机制，会发现有高度类似的情况：假如我们在野外突然碰到一头老虎，身体的第一反应是僵住不动，这个决策并不是来自大脑的高级理性系统（即皮质），而是来自非常原始的大脑边缘系统（哺乳动物都有），它在紧急情况下会切断大脑对躯干的控制，自动接管以保证能够在瞬间完成必须的生存反应。手碰到烫的东西立马缩回去也是一样的决策机制，这样的例子不胜枚举。
在未来，OEM交付的汽车将不是一个功能固化的产品，而是一个持续进化的机器人，在汽车整个生命周期内，硬件平台需要持续支持软件迭代升级，这意味着，我们必须打造一个开放的、工具链完善的、拥有强大算力保障的计算平台，提供高达1000TOPS的算力，为各种软件功能提供充足的算力储备。
软件定义汽车的其核心思想是：决定未来汽车的是以人工智能为核心的软件技术，而不再是汽车的马力大小、是否真皮座椅、机械性能好坏。
高端汽车控制器节点 80~100，整车代码量已经突破 1 亿行。而汽车行业80%~90% 的创新基于电子，离不开软件的支撑，还在不断发展。
不断攀升的代码量即使按照 CMMI（capability maturity Model integration，能力成熟度集成模型）5 级的最高软件标准进行控制，代码缺陷率仍为 0.32‰，潜在问题的规模不容小觑；OTA 可有效解决软件故障， 通过应急响应降低开发周期短带来的软件风险问题，以及完成对信息安全漏洞的修复；
2、汽车由于软件质量导致的召回成本巨大
整车 OTA 应该成为汽车产业优先解决的问题。自动驾驶汽车可能确实对降低交通事故伤亡率有帮助，但假设没有靠谱的修补软件漏洞的方法，到时候一旦面临大规模召回，消费者的不满情绪对品牌而言是最大的灾难。
我们细数下近些年发生的因软件问题而导致的汽车召回事件：
1. 2016 年，日产召回了 320 万因气囊系统问题无法识别乘客的车辆；
2. 2016 年，通用召回了 360 万气囊系统自动进入诊断模式的车辆；
3. 2017 年，道奇召回了 125 万辆安全气囊传感器故障的车型；
更严重的是，很多消费者在知晓车企发布的召回通知后，继续放任软件故障存在。根据调研机构 Stout Research 发布的数据，购买 5 年内的车辆在召回通知发布后的九个月内，维修率只有 40%。例如，2018 年通用宣布因方向盘软件故障召回 100 万辆车型，到现在约有 60 万台未得到修复的车辆仍行驶在道路上。
汽车厂家召回一辆车，需要车主把车开到4S店，有的需要下发优盘进行升级，而且需要人工去操作，整体费用算上一辆车的召回费用基本上是500-800元，如果是重要器件费用会更贵，（比如什么机油漏油处理，需要把整个发动机抬起来，整个汽车拆卸的费用会更贵），召回100W车的费用就是5-8亿RMB，如果仅仅是通过软件升级的话，这笔钱是非常可观的。
如果车企的整车 OTA 技术能够就位的话，对付这些 bug 就变得易如反掌。而且 OTA 升级不光能让产品的电子系统保持最新，一旦出现因软件故障导致的召回，可以节省大量的时间和金钱成本。
3、OTA能够给车企带来的好处
对很多车企而言，OTA 技术上车的主要动力是出于成本节约的考虑。网络安全则是 OTA 必须成为互联汽车标配的另一个重要原因。
而 OTA 升级对主机厂真正具有吸引力的地方在于它能够实现车辆重要功能的常用常新。通过 OTA，汽车制造商通过软件升级的方式可以在产品售出后通过增加功能的方式继续获得收入。这也是为什么 Musk 认为未来搭载了 FSD 的特斯拉车型会变成一件持续升值的产品。
此外，在搭载了一套双向通信的 OTA 平台后，车辆能够将车端系统和零部件的诊断及运行信息及时传输至云服务器，这也有利于主机厂对某些潜在隐患进行预防性监测，做到将风险提前扼杀在摇篮里。
快速修复系统缺陷
传统汽车在用户行驶验证中出现了系统方面的缺陷，而这些问题的解决办法只有一个，汽车厂家启动召回程序，在用户收到召回程序后返厂进行系统的统一升级。而OTA技术则可以通过远程快速的通过数据包的形式完成缺陷的修复，大大避免了持续数月的进厂召回带来的风险。
快速迭代、提升产品和使用体验
由于在产品设计中的硬件的超前配备，智联网汽车操作系统可以通过一次次OTA升级，不断给车主逐步开启新功能，优化产品体验，进行快速迭代，提供更加优质的系统服务。真正让车主感受到什么是“常开常新”。
进行界面优化更新，提升人机交互体验。汽车连接互联网，改变了过去销售是研发过程结束的汽车销售模式，使销售成为厂商与客户互动的开始，因此会带来投诉率高的风险。而是用界面和内容的更新可以从一定程度上降低投诉率。
节约双方的时间和金钱
传统的召回是需要走内部及外部审批的过程，时间和金钱的成本都非常高，通过OTA升级的形式，可以大大降低由于软件缺陷带来的召回成本，把这个钱省下来给大家研发新产品不好么？
汽车整车OTA升级为什么困难重重
1、传统汽车电子的架构介绍
ECU电子控制单元
ECU(Electronic Control Unit) 是电子控制单元， 也称“行车电脑”是汽车专用微机控制器。一般ECU由CPU、存储器(ROM、RAM)输入/输出接口(I/O)、模数转换器(A/D)以及整形、驱动等大规模集成电路组成。
最开始ECU是用于控制发动机工作， 后来随着车辆的电子化发展，ECU逐渐占领了整个汽车， 从防抱死制动系统、4轮驱动系统、电控自动变速器、主动悬架系统、安全气囊系统，到现在逐渐延伸到了车身各类安全、网络、娱乐、传感控制系统等。
随着车子电子化程度越来越高，尤其是自动驾驶、主动安全等功能的增加，车子的ECU会急速增加。1993年， 奥迪A8上使用了5个ECU， 到了2010年， 奥迪A8上使用的ECU数量超过了100个。
汽车EE架构中存在着数十到上百数量的功能ECU，这些功能ECU由不同的供应商提供，不存在统一的中央代码仓库，其中运行着各种不同的操作系统及应用软件，以至于整车代码行数规模达到上亿级。过去分散的功能架构使得汽车不像现代手机一样有中央大脑处理器集中处理软件逻辑。在分散的EE架构中做整车OTA，就好比把30个人的脚绑在一起大家同时往前迈一步一样，这个协调难度比起只有2~3个人做这件事情困难很多。
传统软件应用开发，功能代码耦合，程序整体打包，修改部分逻辑，需整体重新编译跨控制器功能分散，所有相关控制器都需要更新软件。
如果我要更新一个ABS，那关联的BCM、仪表、网关都要改，而且都分属于不同的供应商，代码也是别人写的。从这一点也应证传统车企被供应商绑架了。这个属于牵一发而动全身，比较麻烦。
2、目前电子架构下，整车OTA时间非常长
人们都是利用自己熟悉的事物去思考和理解新事物的，讲到升级大部分人对升级的理解是手机上APP的升级，手机系统的升级，windows系统的更新等这些熟悉的事物，觉得升级是一件相对比较容易的事情。汽车软件升级要比手机和电脑升级所消耗的时间长，主要的原因是：
汽车内部通讯网络的传输速度较慢。手机和电脑内部的数据传输是非常快的，为了保证数据传输的速度，内部总线的条数和传输频率都是很高的。汽车则大不相同，汽车内现在主流的还是采取CAN网络，理论上高速CAN的传输速率是1M/s,低速CAN的传输速率是125K/S，这些都是理论上，实际的传输速度要远低于这个速度，如果我们将一个100M的文件从一个零件传输到另外一个零件，消耗的时间本身就比较长。可能有人会问，为啥汽车里不能用网线呢。现在是有的，但关键就是成本啊。
汽车内部各控制器的刷写需要时间。汽车内部各个控制器是有安全防护的，不是谁给我发刷写指令我就认的，首先要通过控制器的安全认证，然后将文件传输给控制器，控制器再重启完成刷写。如果中间出了错误，刷写不成功，还需要重试。这个过程类似于我们给电脑的硬件升级驱动程序，整个过程需要较长的时间。如果是遇到那种运算能力和存储空间小的控制器，需要将数据按照一定的格式慢慢的写进控制器里去。那消耗的时间就更多的。
基于以上两点，整车软件OTA的耗时会是小时来计算，升级的控制器越多，升级的时间也就越长。所以，各位车主如果想要给自己的爱车进行软件升级，最好是选择一个网络条件好，停车方便的地方，同时还得关注一下，自己的电瓶电量是不是够。另外，升级过程中车辆的一些设备是不能够使用的，也有可能会出现屏幕或者是仪表的突然黑屏或者是闪动等现象，不用担心，现在汽车软件远程升级技术已经非常成熟，所有的升级过程都是经过了非常严格的测试才准予上线的，有点小异常，只要等待的时间不是太长，完全可以忽略。
3、传统整车厂还没有准备好OTA升级相关的条件
为什么这么说呢，与其说没有准备好，其实是能力还不够，目前够实现整车 OTA 功能的新能源车型共有 7 款，分别是蔚来 ES6/ES8、特斯拉 MODEL S/X/3、理想 ONE、小鹏 G3。
可以看到这些车型无一例外都是新能源车，整车的架构的传统车的电气架构有着很大的区别，基本上核心的域控制的软件是在自己手里，才能实现整车的OTA，否则只能实现部分ECU的OTA功能。
这里举一个小例子，艾比拉副总裁曾说传统车厂如果实现了OTA升级皮肤主题收取费用，这部分钱在传统车厂找不到收费的部门，软件部门是负责升级软件的，没有收费的权限，以前都是通过4S店收取费用，现在直接OTA后没有运营部门，收费都不知道谁去收取。这就需要传统整车厂不仅仅是技术方面的改变，对于部门架构也要做对应的调整和改变。软件升级绝非想象的那么简单，在升级任务执行的过程中，会遇到各种各样的问题，需要运营部门、服务部门、营销部门甚至是当地的4S店参与。
前面提到了ECU复杂，整车通讯网络也复杂，而且整车OTA升级慢，其实OTA涉及到很多部门，而且涉及到的事情非常多，举例一个版本管理需要考虑和设计注意事项：
1、不同车型的系统适配
2、不同品牌的系统适配
3、同车型不同配置的系统适配
4、同车型不同系统版本的适配
5、不同车型不同配置不同品牌不同系统版本的适配
如果把这些问题穿插起来，你会发现跨品牌、跨车型、跨版本的OTA系统升级，将是一件工作量巨大的系统工程。甚至也超乎我们的想象。
OTA设计主要从安全、时间、版本管理、异常处理等方面综合考虑，具体为：
升级安全是OTA的最基础的要求。车辆上ECU的软件运行状况直接会影响到车辆上的人员的生命安全。从升级包制作，发布，下载，分发，刷写等环节，OTA需要从云，网络，车端来保证安全。在云端通过证书，签名和加密机制保证升级包的不会随意被制作和发布，升级包内容不会被恶意获取。通过可靠的物理链路和安全传输协议来保证网络传输安全。通过汽车的功能域隔离，划分不同ASIL等级，通过冗余设计保证整车的功能可靠性，通过安全启动来保证可信的软件在ECU上加载启动运行。
版本管控对于OTA来说很重要，因为车辆上ECU众多，不同ECU有不同版本的软件，不同车型ECU的需求有不同，版本也存在差异。版本的升级路径管理，需要能够全面准确进行管控。
整车升级进行车载ECU刷写时，特别涉及动力域传统ECU的刷写，是通过CAN网络进行安装包的分发。由于CAN传输速率很低（实际典型的速率为500Kb/s），并且CAN总线负载率通常要控制在30%以内，因此在带宽允许的情况下，尽可能采取并行刷写模式，选取刷写时间最长的节点优先处理等设计原则减少OTA升级时长。
防变砖等异常处理。在OTA传输过程中，外界干扰或者其他因素导致刷写异常或者中断，车载ECU必须支持软件回滚、断点续传、丢失重传等处理机制。
4、整车OTA对于硬件底层的架构知识要求非常清晰
很多人之前把未来的汽车畅想成「一台手机加四个轮子」，所以也理所当然地认为整车 OTA 应该和我们升级手中的 iPhone 一样简单。但其实从架构的角度来看，智能手机基本只配备了一台处理器来运行各种 APP，但汽车内部 ECU 的数量至少有上百个，它们连接在不同的车内通讯网络上，同时每条网络又有着不同的数据传输协议。
目前绝大多数 OTA 能够做到的还只是将软件升级包发送至车内的 T-Box，而不能实现 ECU 层面的软件升级，譬如对气囊、动力总成、车身控制或安全等功能做出及时更改。
之前也提到过了，互联汽车和智能手机有着截然不同的电子架构。要在汽车上实现真正的 OTA（从云端到 ECU），供应商首先要在计算硬件上有很深的知识储备，比如了解车内不同硬件单元的区别。因为如果要与 ECU 进行通讯直连，你得知道它是不是有两个内存库。这样在 OTA 的时候，其中一个内存库可以写入升级包，而另一个内存库则可以存放旧版本的程序。
显然这种双内存的配置十分占用空间。尽管升级数据可以进行压缩，但 OTA 供应商仍需要考虑它要传输升级包的 ECU 是否有足够的片上内存（on-chip memory）。
其次，OTA 供应商还应该熟悉车内的通讯网络拓扑结构。因为不同的 ECU 连接着从 CAN 总线、FlexRay、LIN 到 MOST、以太网等不同的通讯网络，只有对每条线路的特点有清晰的认知才能高效地实现软件升级。
对此，芯片供应商瑞萨认为要实现从 OTA 的第一阶段（对单一 ECU 的升级）进化到能够对整车功能更新，包括一些安全部件的更新。需要从两个方面入手：一是降低车内通讯网络的复杂性；二是简化车内 API 接口同时增加 MCU 对多个系统的集成化控制。
这其实涉及到了从传统燃油平台向智能电动化迈进的过程中，整车电子电气架构随之发生的演化：从分布式逐步向集中式过渡。而全新车用计算平台的引入能够简化车内网络的结构，加速通讯协议的编译过程同时增强各个子版块的安全性。同时位于整个中枢系统的 MCU 应该足够智能，它需要把从以太网获得的数据提前进行压缩，然后再传输给 CAN 总线。
汽车OTA从经销商推广有难度，这点我们不难看出，以前我们车要升级都要去经销商升级，升级同时会帮你检测车辆然后推广一些用品和服务，一旦OTA全面实行难免会使客户与经销商的接触少了很多，这是一个面包与爱情的故事，所以是不可避免的
由于上述OTA升级要求非常高、目前传统车厂的电气架构又不能满足车厂OTA、而且整车电气架构非常复杂，各个零部件的耦合度高、传统车厂又对于ter1非常依赖，自己开发软件能力非常弱，升级某个零部件就会涉及到关联件的升级，而且整车上基本上没有自己的服务器，需要ter1去搭建云平台，而且会涉及到远程升级安全问题，升级策略、综合因素造就了整车OTA升级困难重重。
汽车OTA典型架构简单介绍
上图展示车辆内从主机厂服务器更新程序到指定 ECU 的过程中的主要部件。首先通过蜂窝网络建立车辆与服务器之间的安全连接，确保全新的，待更新的固件安全地传输到车辆的 TelemaTIcs Unit，然后再传输给 OTA Manager。OTA Manager 管理车辆所有 ECU 的更新过程。它控制着将固件更新分发到 ECU，并告知 ECU 何时执行更新 - 在多个 ECUs 需要同时更新的情况下尤为重要 - 例如推送一项新功能，而该新功能涉及多个 ECUs。更新过程完成后，OTA Manager 将向服务器发送确认。
针对 OTA Manager 它可能需要外挂 NAND flash 用来存储固件包，同样也可以用来存储其他车辆 ECUs 的备份，以期在 ECU 升级失败之后进行调用。这些备份应该通过加密&认证的方式进行防护避免外部攻击。
OTA Manager 内部有一个表格，包含各个车辆 ECU 的相关信息，譬如 SN 号以及当前的固件版本。这样便于 OTA Manager 核实接收到的固件升级包并确保是通过授权的。如果是正在更新的 ECU 不具备加密能力那么 OTA Manager 同样需要负责更新过程的解码及验签。
从上图不难看出 OTA Manager 的重要性，也正是基于此，并结合网关的安全性、隔离性以及天然的多连接属性，部分主机厂启动自研网关（集成 OTA Manager 角色），譬如蔚来、FF。
汽车OTA升级过程中有哪些技术问题需要注意？
综合看来汽车上实现OTA在线升级软硬件，主要考量的还是安全问题，包括Telematics以及通信技术都已成熟并且在电脑、手机这些设备上都经过实践的验证，把这种技术转移到汽车上就需要考虑更多环境、汽车工况等安全因素。归纳起来主要包括以下两个方面：
信息安全；主要是通信加密、软件包验签、更新隔离以及安全芯片等；
功能安全；主要包括OTAManager的启动条件判断（车辆状态等）、ECU升级的预编程条件判断、整车模式配合以及升级方案考量（A/B法等）；对于汽车OTA，我们不能很随便地做整车ECU升级，而必须要在一个合适的时间、合适的地点以及车辆合适的状态下进行升级。
这就要求车企制定相应的升级策略，特别是对“合适”二字进行定义，以尽可能安全、经济的方式来开展这项操作，而不是像手机一样在任何时间、任何地点实施升级。
当然，安全是 OTA 升级中最关键的问题所在。不像手机，升级不成功顶多是「变砖」，但汽车就不一样了，稍有不慎就可能车损人亡。所以显然不能很随便地做整车 ECU 升级，这就要求车企要制定相应的升级策略，特别是定义好「合适」二字，避免出现类似蔚来车主在长安街遭遇的窘迫事件。
这里的「合适」既包括了对时间、地点、车辆状态等要求，同时还要对软件的功能性进行区分，比如关键系统一定要保持车辆静止且电量充足等，像音乐、视频类似的 APP 则可以在行驶过程中升级，只要确保不影响行车安全即可。
从这个角度出发考虑的话，在对汽车进行 OTA 升级时，其实要先让云端服务器与目标车辆进行通讯，锁定并同时对目标进行持续监测，确保其符合升级要求。而一旦进入升级状态，又会涉及一个新问题：中间发生错误怎么办？
其实升级过程中出现 bug 很正常，但对汽车而言，需要制定更妥善的防错机制保证车辆功能安全不受影响。像「断点续传」就是目前已知的 OTA 防错机制中一种较常见的方案。此外还有回滚机制，因为升级后新系统如果不稳定就需要退回到之前的版本，这也是对车辆安全的一种保护方式。
OTA场景策略与规则
从OEM车联网运营角度划分，根据车辆销售前和销售后不同，OTA升级场景一般会区分为静默升级和非静默升级。静默升级主要用于销售前处于库存状态的车辆升级。OTA云平台通过发送远程唤醒命令，通过TBOX唤醒车辆上电，连接到平台进行升级任务的处理。
非静默升级主要是用于是销售后车辆归属于车主后的升级场景，软件升级变更需告知给车主，在车主知情和同意的下进行升级。非静默升级其中又分为普通升级和紧急升级，紧急升级一般是用于特别重要安全补丁的推送升级，车主知情但是无法拒绝。
OTA升级任务下发到车辆后，升级管理程序OTA Manager也必须判断车辆条件是否符合。对于不符合条件的车辆，升级管理程序必须中止升级任务并上报给云平台。在OTA架构中，升级规则定义了各个车型在升级包下载，安装刷写阶段的判断条件。升级规则会随着云平台上的升级任务下发到车辆。例如最低版本要求，车辆运行状态、车辆位置。
某电动车厂商的车辆在长安街街心升级导致交通堵塞的新闻曾在互联网上议论纷纷，如果在升级执行前能否判断车辆处于一个不适合升级的地点，那么升级任务也不会推送给停车等候红绿灯的车主了。一个好的OTA系统一定是能够灵活的配置升级条件，并且合理准确控制升级和用户推送的系统。
最后，结合OEM运营的要求，OTA升级还需要能够灵活定义升级的具体范围，升级时机，升级内容，提示事项，失败后给用户的失败处理提示，提升大规模升级中的运营效率和运营体验，持续为车主和OEM提供价值。