|
作者 / 阿宝 编辑 / 阿宝 出品 / 阿宝1990（个人微信号 woabao1990） 上期我们聊了由于OTA升级要求非常高、目前传统车厂的电气架构又不能满足车厂OTA、而且整车电气架构非常复杂，各个零部件的耦合度高、传统车厂又对于ter1非常依赖，自己开发软件能力非常弱，升级某个零部件就会涉及到关联件的升级，而且整车上基本上没有自己的服务器，需要ter1去搭建云平台，而且会涉及到远程升级安全问题，升级策略、综合因素造就了整车OTA升级困难重重。 这期重点来讲讲OTA中需要注意的问题点，整个升级流程中需要注意的地方。本文有借鉴参考艾比拉李总的演讲和PPT内容，一家专注于OTA升级的公司，非常的牛。 OTA方案架构 汽车OTA系统是一个云管端的系统方案。云端主要负责升级策略、升级任务、软件版本、数据分析等升级管理工作。车端主要负责软件包下载，软件包刷写，差分还原、安全及完整性校验等单车软件升级工作。车端与云端的连接方式也有很多种，如WiFi、蜂窝网络、近场通讯（蓝牙、LoRa、ZigBee等），无论哪种连接方式，都是让云端与车端建立连接，让软件包和车辆刷写策略能够下发到车端执行，完成汽车软件升级的最终目标。 OTA云平台，主要包括了OTA云端的升级模型管理，升级包管理，升级任务，升级策略以及日志管理的功能。OTA云端的设计要求是物理上实现租户隔离的云平台，能够支持多种协议下升级接入，支持多车型、多品牌、多种类型ECU软件版本管理，升级包制作，升级模型定义和升级策略和规则配置。能够支持批量升级任务的调度和分发。能够提供适配层与TSP平台和OEM的IT系统进行集成。性能上能否实现100万以上车辆升级并发，差分效率能够不小于90%，可靠性能否实现3个9的要求和7*24小时的系统连续服务。 车端架构按功能域划分，分为动力系统域、车身系统域、影音娱乐域、ADAS主动安全域、自动驾驶域，不同的功能域有着不同的通信网络和功能安全等级设计。。自动驾驶域或者影音娱乐域等部分ECU存在主备分区的设计，即ECU内部用于两片区域，一部分用于存储当前运行的程序，一部分用于存储备份程序。除第一次安装或者设备下线时，ECU内部只有一份软件外，之后更新安装的软件都会与上一份共存。当前运行的是最新的软件，如果升级过程中发生错误或者刷写的程序不能运行，ECU根据OTA Manager的升级策略要求，能否自动回滚至上一个版本的程序，防止车辆ECU变砖。 升级任务是OTA平台用于执行和监控一组设备的升级活动的集合。升级任务可针对特定范围的设备，使用相应的升级包和升级策略，进行升级任务创建，下发，监控，状态维护等整组活动的管理。升级任务的监控功能，提供了对一组升级活动中，升级任务状态，进度和结果的反馈。按照升级任务状态的状态，主要包含了成功，失败，升级中等设备的数量和各个状态下的比例。升级任务的控制功能，提供了对一组升级活动中，升级任务的启动，停止，暂停，恢复，重启，撤销等操作能力，实际上是维护了任务状态机的状态变迁干预能力。 升级日志包括云平台的日志，车端与云平台通信产生的日志和车端升级程序搜集上来的日志。主要用于升级失败后的分析和支撑升级运维运营管理。 OTA车端主要包含通信终端和各功能域的ECU。OTA通信终端一般由TBOX负责，上面运行OTA升级管理程序和升级代理程序。其中，OTA升级管理程序OTA Manager是负责连接车辆与OTA云平台的管理程序。它实现了端云的安全通信，包括协议通信链接管理，升级指令接收和升级状态发送，升级包下载、升级包解密、差分包重构等功能。升级代理Update Agent，是为了兼容不同的车内通信网络和通信协议，以及不同OEM间各品牌车型的接口差异，进行封装适配的部分。升级代理提供了统一接口，由OTA厂商负责实现接口，完成接口和业务逻辑的适配。 OTA升级流程简单介绍 汽车软件升级一般从ECU的软件新版本产生开始，到车端升级结果反馈回云端结束。升级过程涉及云端（由OEM来掌控）和车端（由用户来掌控），双方的交界点就在于升级任务的发布，用户开始接受到升级通知。大致的流程描述如下： · 软件新版本：OEM自身或供应商研发了某个电子元器件（ECU）的软件新版本，经过测试后，将软件包上传到OTA的云端系统。 · 升级包生成：OTA云端会依据上传的软件包和零部件当前的软件版本情况，自动或手动生成软件升级包。其中包含对体量较大升级包的差分等相关功能。 · 升级包测试：为了确保升级过程中不出现问题，所有的升级包都必须经过测试，经过测试后的升级包才会被下发给真实的用户。好的OTA系统还会有测试车辆的管理能力。 · 升级策略：不同的车型的不同控制器升级，在升级过程、升级条件及安全上都有不同的要求，云端要能够将这些升级所需的操作制作成升级策略。升级策略测试通过后，再跟软件包一起下发到车端。升级策略制定的灵活性，决定了OTA系统的优劣。 · 升级任务：升级策略约定的是一辆车的升级过程，升级任务则是约定一批车辆的升级过程。升级任务一般都会约定哪些车的哪些零部件要升级，升级前要给用户发什么样的通知，向用户提示哪些内容等。升级任务在内部还需要有必要的审核机制。升级任务发布后，车辆就可以接受到相应的升级通知。 · 获取通知：OEM在云端发布升级任务后，在升级范围内的车辆就会获取到升级通知，通知内容一般情况下是云端约定好的内容，包含升级范围、升级耗时等内容。 · 用户授权：车辆销售给用户后，其搭载的程序和存储空间都是用户的私人财产，OEM想要在车辆上做软件改动必须要经过用户授权。用户授权后才能够下载软件包，并执行相应的升级操作。 · 升级包下载：车端从云端获取本次升级所需的软件包和相应的升级执行脚本。在车端进行安全性和完整性校验，确保安全后才能够执行升级。 · 升级包安装：升级包的安装就是汽车软件升级的具体过程。不同的零部件有不同的升级方式，这个过程类似我们在电脑上对某个软件进行升级，但实际上区别较大。 · 升级结果反馈：车端在升级过程执行完成后，无论成功还是失败，都需要向云端报告相关的情况，车端数据的回传是做好管理的基础。 汽车OTA升级重点的几个地方 1、升级包的生成考验OTA厂家的算法功力 软件包是用于升级使用的程序或配置。软件包包含有设备软件修复的缺陷或者要加入的新功能，更新前和更新后需要做哪些验证检查逻辑等，都会被打包到这个文件里。软件包一般都是由设备软件供应商提供的，会通过特定渠道，发布给OTA服务方。在整车升级中，OTA 分为两类，一种是 FOTA固件在线升级），指的是给一个零部件的ECU闪存下载完整的固件镜像，或者修补现有固件、更新闪存。而固件之外的软件更新，就是 SOTA（软件在线升级）。例如，车机屏应用程序和车载地图的升级，都属于 SOTA 的范畴。这两种文件形态，都属于软件包管理的范畴，通过软件包分类进行区分。软件包管理允许软件包能够基于软件包版本进行分版本的存储和管理，并维护软件类型，全量与差分等属性。 升级包是在升级任务中，用于真正下载和安装部署的文件。升级包可以是设备软件供应商发布的软件包文件，也可以是经过OTA平台完成了打包处理的文件。常见的升级包制作处理包括文件压缩合并，生成特定的文件描述信息，文件签名和加密处理。许多物联网设备和车辆设备的闪存都比较小，升级包需要要能在嵌入式设备的小内存中完成安装。因此，升级包会尽可能地压缩大小。为了保证效率和成功率，OTA平台在升级包制作中提供了差分生成的离线和在线工具。升级差分包之前，通过比较新旧版本之间的差异，生成差异文件。差分更新的核心技术是各家OTA供应商掌握的字节差分算法。 2、升级策略至关重要 升级策略是升级活动中的用于描述任务特征和目标设备升级行为的配置。升级主要会涉及到下载和安装两个阶段，升级策略中，一般会包含升级包下载策略和升级包安装的策略，以及异常情况下的处理策略。例如，在整车升级中，升级策略包括静默升级，常规升级和紧急升级的分类，也包括了升级包下载前，是否需要通知给用户下载确认的配置。 OTA升级场景一般会区分为静默升级和非静默升级。静默升级主要用于销售前处于库存状态的车辆升级。OTA云平台通过发送远程唤醒命令，通过TBOX唤醒车辆上电，连接到平台进行升级任务的处理。 非静默升级主要是用于是销售后车辆归属于车主后的升级场景，软件升级变更需告知给车主，在车主知情和同意的下进行升级。非静默升级其中又分为普通升级和紧急升级，紧急升级一般是用于特别重要安全补丁的推送升级，比如某些发动机的软件故障等等，车主知情但是无法拒绝。 某电动车厂商的车辆在长安街街心升级导致交通堵塞的新闻曾在互联网上议论纷纷，如果在升级执行前能否判断车辆处于一个不适合升级的地点，那么升级任务也不会推送给停车等候红绿灯的车主了。一个好的OTA系统一定是能够灵活的配置升级条件，并且合理准确控制升级和用户推送的系统。 手机升级扔在一边等手机自动升级，反正升级时间也快，尤其汽车是一个大件物品，很多老司机在升级的时候生怕有什么问题，就会熄火坐在车里等整车OTA，目前的升级速度又慢，一做就是1个小时，而且涉及到娱乐系统&空调系统升级的时候，大夏天30多℃，汗流浃背的焦急等待1个小时，确实不会是一个好的体验，哪怕你告诉升级后汽车能飞，我都不想升级。 其实此时可以通过手机授权，在车停在地上停车场后，通过手机联网授权，预约OTA升级，在空调房里面吹着冷风，吃着西瓜，升级成功后把信息反馈到手机给你提示，下班后就是一辆升级完后的新车了，这样的体验是不是超级perfect。 在整车升级中，因为涉及到车型与ECU的配套关系，因此升级模型一般能够体现一个车型下各个零部件ECU的依赖关系，例如多个零部件ECU直接软件包配套关系和升级顺序控制，对于升级任务在设备侧的准确完整执行非常重要。此外，升级模型还包含了升级规则的定义。升级规则可以用于描述升级流程中，用于允许升级能否继续进行的判定条件。在整车升级中，一般包括了一款车型在升级下载前，下载中，安装前，和安装中的判定规则配置。 3、OTA的运营管理是OTA能否展开工作 现在OTA系统的两大核心目的是修复车辆上的软件问题，给车辆新增更好的功能。针对OTA发挥价值的这两个点上，运营的目标是怎样的呢？ 1、针对问题修复类的软件升级运营。运营目标很明显，那就是在最短的时间内修复所有有问题的车辆，让可能会发生的质量问题或者是投诉都被扼杀在摇篮里。这就要求OTA系统在升级效率上要有所保障。现在很多人说OTA系统运营难，其实大部分指的是想要快速的让新版本取代旧版本是一件非常难的事情。升级任务的执行总是会给你一开始的惊喜，然后是焦灼的期待和漫长的等待，最后是手足无措的放弃。 2、针对新增软件功能类的软件升级运营。我们就是奔着把软件功能成功卖给用户赚钱这个目标去的。之前听说过一句话，讲的很有意思，世界上最难的事情有两种，一种是把别人口袋里的钱拿到自己口袋里，另一种是把自己的思想放到别人的脑子里去。想要在车上软件挣钱，行的通，但很多OEM还没有这方面成功的商业模式。且不说商业模式，后面我们会说，想要卖功能挣钱，首先得有东西卖才行。 行业里大家都在拿着特斯拉、小鹏、蔚来等企业来说OTA，每每说到的时候都会说，你看人家有更新了什么功能，所以他们的OTA技术一定很牛。这里我想澄清一下，OTA是软件更新的通道，主机厂通过这个通道升级什么并不是通道来决定的。所以，看到特斯拉更新了新功能，例如赛道模式，就下结论说特斯拉的OTA技术做的好，这两者之间是没有什么本质联系的。只能说，新锐电动车厂商在软件功能定义上做的好，运营做的好，而不是他们的OTA技术多牛。所以，对于想急切进步的传统OEM，OTA运营才是关键所在，只有经历过项目打磨，做过深度思考的供应商，在运营上才会有真知灼见。“技术+服务+运营”才是OTA系统的全部。 汽车软件远程升级绝对不是在系统上下发一个升级任务，然后新版软件机会乖乖的跑到用户车上的过程。车辆已经销售给客户，我们在用户车辆上下载文件、安装程序必须要经过用户同意。因为车辆的所有者是用户，而不是OEM。所以，在升级的过程中，我们必须获取用户的授权，否则我们升级就如同电脑中的流氓软件，自己下载自己安装，还会弹消息。 在以往的软件升级运营活动中，遇到的最大的问题不是升级刷写速度的问题，不是网络不畅通的问题，而是如何获取用户授权，用户不授权升级任务就只能等待，这个等待的时间可能会比车辆升级过程的真正耗时要长很多倍。升级任务下发后，如果时间设置的好，通知设计的巧妙，一开始会有很多用户配合进行升级，但一段时间后，升级用户的数量会逐渐减少，甚至是停滞。究其原因，是用户对升级这件事情的不理解。 车辆用户会想，我的车现在挺好的，为什么要升级？升级会不会给自己的车辆带来新的问题？升级后会不会像苹果手机一样，老机型会卡顿和变慢啊？还有的用户会开始怀疑OEM升级的动机，没有问题为什么样升级呢？这车肯定是哪出问题了，要是遇到几个较真的用户，解释起来都是一件让售后服务头疼的事情。 其实，提出问题的用户我们一般都不担心，至少他们关注到了车辆的软件版本更新，最怕的是那种什么反馈都没有，反正就是不升级的用户，想要调用他们的积极性，那可是十分困难的事情。 用户不是OEM的木偶，发一个指令就会让用户有相应的动作。对于运营人员而言，可以说无所不用，甚至用其极啊。个人总结出来的经验是，打着车辆安全旗号的软件更新往往会执行的比较快，但同样的方法用的多了，用户也不会信你了。他们会甩给你一个表情包：我信你个鬼！ 从本质上来说，需要用户配合的升级运营活动，要从用户意愿，时间和操作说明几个点上去思考。任何一个升级活动在开始宣传的时候就要思考清楚，如果我作为车主，我为什么要对车辆进行升级，如果不升级对我有什么坏处？我们应该怎样发通知，怎样描述软件的变化才会让用户更容易接受。 做的再精细点，不同的用户群体也需要有不同的运营策略。依托用户的用车时间和用车习惯，以及用户的活跃度等信息，给一个固定的群体制定细分的升级方案，是升级效率提升的有效手段。只不过，OEM要有人来负责这个事情，如果我们把这个事情交给OTA系统建设的信息部或者是技术部门，那效果可想而知。 OTA的运营是需要专业人才的，这些人要懂车，懂车主，懂互联网运营，同时还需要有一个功能足够强大的OTA系统。OEM还是要腾出点时间来关注系统的运营功能，一开始做好了，就会减少很多后期的烦恼。例如：升级任务的重要度排序，升级任务中未升级车辆的额外通知，升级任务的灰度发布设置等等。每一个功能设计的细节都是经验的积累啊。正所谓，一分钱一分货，有些供应商之所以价格低肯定是有原因的。 用户获取软件升级的正式通知，了解到自己的车辆已经有新版本可以使用。虽然就是一个简单的通知，但有的时候细节上好的设计也能够让人耳目一新，特斯拉这个升级通知就一目了然。
4、升级的信息安全才是整个OTA升级的守门员 去年有两名白帽黑客远程控制了一辆吉普切诺基，当然这次“事故”只是潜在的危险，并没有造成严重的损失，随后克洛斯勒召回了140万辆车。 今年已经看到欧洲最大的汽车俱乐部（ADAC）的研究人员展示了无钥匙的“舒适锁定”机制在市场上的普及程度，无疑是技术精明的小偷。在阿尔法罗密欧，雪佛兰，福特，蓝旗亚，欧宝，标致和雷诺等大众汽车集团中，可以使用廉价且易于使用的硬件工具绕过整个车辆系列的锁定机构。 车辆网络安全的核心挑战之一是汽车的各种ECU通过内部网络连接。因此，如果黑客设法访问易受工具的外围ECU（比如汽车的蓝牙或者信息娱乐系统），那么黑客们就可以控制关键的ECU，如制动器或者发动机，从而造成严重的破坏。 如今的汽车有多达100多个ECU，超过1亿行的代码，这就给与了巨大的供给面。困难的是汽车制造商是从许多不同的供应商里获取ECU，意味着没有一个黑客可以控制甚至熟悉车辆的所有源代码。
汽车越来越附能也就意味着攻击汽车的点越来越多，上图中显示有很多点都是新能源汽车相对于传统汽车的“高大上”功能，比如手机的远程控制，云端的远程监控等。通信和娱乐系统特别容易受到攻击，并且可以通过逆向工程来访问API库，从而促进系统之间的数据共享。从这里，攻击甚至可以将恶意代码注入到电子控制单元（ECU）和控制器区域网络（CAN）总线中，该总线控制关键系统，如电动转向和制动。OBD设备是厂商用来诊断汽车的各种数据，该接口集成了很多ECU的CAN总线接口，通过OBD接口可以变向的访问汽车其他设备，比如雨刷，空调等，现在有很多创业公司在做基于OBD外设控制汽车，但目前做的都不温不火，甚至有些公司在基于该接口做自动驾驶的方案。 很多汽车厂商的服务器甚至都没有提供安全加密的算法，当然网络攻击只是入侵汽车的步骤之一，汽车攻击相对于PC或者手机难以攻击的点在于汽车本身是个集成度很高的产品，里面有大量不同厂商的ECU，每家零部件供应商或者整车厂都有一套自己的车载协议，而且这些协议是不公开的，这是黑客们攻击汽车最难以逾越的屏障，同时也是汽车最安全的一道保护层。 说了这么多，其实在OTA升级中最重要的就是需要涉及到数据加密的身份校验的问题，数据加密在整个物联网中都比较成熟了，一般都是采用非对称加密的算法。这里简单对加密的逻辑进行一下说明。 最简单易懂的非对称加密 北京的张三发了一个快递到广州的李四，途中经过了上海，上海快递中心出现了一个黑客老王，他偷偷打开了张三给李四的快递，然后偷偷把里边的衣服剪烂，再按照原样包装好发往广州，可以看到对于这样简单包装的传输在中途是可以偷偷修改里边的东西。 HTTP的数据包是明文传输，也即是如果中途某个黑客嗅探到这个HTTP包，他可以偷偷修改里边包的内容，至于张三跟李四是互相不知道这个动作的，因此我们必须要有一个方案来防止这种不安全的篡改行为，有个方法就是加密！ 非对称加密 张三将衣服放到一个保险箱里边锁起来，他打了个电话告诉李四保险箱开柜密码是1234，而黑客老王不知道密码，所以他看不到保险箱里边的东西，李四收到快递后用预先沟通好的密码就可以打开保险箱了。这里保护的手段就是张三对物品进行加密，同时给了告诉李四解密的方法！ 那如果现在要求张三的密码只能通过快递传给李四呢？如果张三直接传密码给李四，老王如果嗅探到这个快递，那老王也知道密码了，这就无法保护快递的安全性了。因此还需要有个方案，让张三能够告诉李四密码的同时，老王又无法查看到张三跟李四通信的数据。 非对称加密在这个时候就发挥作用了，来看看怎么回事： 张三拥有两把钥匙，一把叫做公钥，一把叫做私钥。公钥是公开让全社会都知道，没关系，张三告诉所有人，你们要传递数据给我的时候请先用这个密钥(公钥)去加密一下你们的数据，加密后的数据只能通过张三私自藏着的私钥才能解密。 回到刚刚例子，
张三先发给保险柜（张三公钥）给李四，接着李四把自己的保险柜（李四公钥）放到张三的保险柜(即使用张三的公钥加密李四的公钥)里边发还给张三，接着张三拿到李四的数据包后，用自己的私钥解开了外层保险柜(张三的公钥)，拿到了里边李四保险柜(李四的公钥)。此时李四跟张三都有了各自的公钥(并且都有他们自己的私钥)，接着只要保证每次互相传递数据的时候，把数据放在对方的保险柜里边即可(即每次都用对方的公钥加密数据)，这样无论如何，老王都无法解开保险柜（因为只有各自的私钥才能解开各自的保险柜）。
加密，是不让别人看见我传输的是什么内容。认证，就是确保车辆端、云端是我期望的、认可的对象。 比如车机进行软件升级时，要发出认证请求到服务器；服务器收到车端请求信息后，发回反馈，要求发送数字证书自证身份。车端发送数字证书到服务器端；服务器对数字证书进行校验是否存在问题；验证无误后终端管理系统向终端发送验证结果，这时才可以开始进行相应的软件升级。更新包会被加密后传输到车端，在T-box解密后再分发到车机。另外一个比较重要的车端部分是网关，可以避免ECU与联网的远程信息处理单元直接接触，提高了OTA更新的安全性。 |
|
|
