万字长文趣味解读整车OTA，建议收藏！
第1篇
整车OTA为什么困难重重
什么是汽车OTA
首先，我们先来看看各位吃瓜群众对OTA的理解，搞清楚什么是OTA？
群众A: 小宝，这个我清楚，无非就是升级打补丁嘛，形象一些，就是衣服穿的破烂了，然后再打一个好看点的补丁。
曾经，小宝上初中的时候，为了让衣服显得酷一些，在好的衣服上也弄一个超酷的补丁，现在也有一些车企也在这么做，为了显示自己能OTA，本来没有必要的升级，非得弄的高大上，所谓让用户更有粘度。
群众B：小宝，汽车OTA太吓人了，动不动就整“趴火”，这个不太安全吧。在2019年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是什么？是补丁，是惊喜，是增加新体验，到底是什么呢？为什么有的厂家宣传的是OTA，有的宣传的是FOTA，有的又说SOTA，这有什么区别？
名词解释
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是不能使用的，风险度会比较高。
OEM为什么热衷于研究OTA
1、OTA能够给车企带来的好处
对很多车企而言，OTA 技术上车的主要动力是出于成本节约的考虑。网络安全则是 OTA 必须成为互联汽车标配的另一个重要原因。
而 OTA 升级对主机厂真正具有吸引力的地方在于它能够实现车辆重要功能的常用常新。通过 OTA，汽车制造商通过软件升级的方式可以在产品售出后通过增加功能的方式继续获得收入。这也是为什么 Musk 认为未来搭载了 FSD 的特斯拉车型会变成一件持续升值的产品。
此外，在搭载了一套双向通信的 OTA 平台后，车辆能够将车端系统和零部件的诊断及运行信息及时传输至云服务器，这也有利于主机厂对某些潜在隐患进行预防性监测，做到将风险提前扼杀在摇篮里。
快速修复系统缺陷
传统汽车在用户行驶验证中出现了系统方面的缺陷，而这些问题的解决办法只有一个，汽车厂家启动召回程序，在用户收到召回程序后返厂进行系统的统一升级。而OTA技术则可以通过远程快速的通过数据包的形式完成缺陷的修复，大大避免了持续数月的进厂召回带来的风险。
快速迭代、提升产品和使用体验
由于在产品设计中的硬件的超前配备，智联网汽车操作系统可以通过一次次OTA升级，不断给车主逐步开启新功能，优化产品体验，进行快速迭代，提供更加优质的系统服务。真正让车主感受到什么是“常开常新”。
进行界面优化更新，提升人机交互体验。汽车连接互联网，改变了过去销售是研发过程结束的汽车销售模式，使销售成为厂商与客户互动的开始，因此会带来投诉率高的风险。而是用界面和内容的更新可以从一定程度上降低投诉率。
节约双方的时间和金钱
传统的召回是需要走内部及外部审批的过程，时间和金钱的成本都非常高。通过OTA升级的形式，可以大大降低由于软件缺陷带来的召回成本，把这个钱省下来给大家研发新产品不好么？
2、软件定义汽车已经形成共识，软件风险也是趋势
大众汽车之前宣布，组建自己的软件部门：数字汽车与服务部（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 可有效解决软件故障， 通过应急响应降低开发周期短带来的软件风险问题，以及完成对信息安全漏洞的修复；
3、汽车由于软件质量导致的召回成本巨大
汽车厂家召回一辆车，需要车主把车开到4S店，有的需要下发优盘进行升级，而且需要人工去操作，整体费用算上一辆车的召回费用基本上是500-800元，如果是重要器件，费用会更贵，（比如什么机油漏油处理，需要把整个发动机抬起来，整个汽车拆卸的费用会更贵），召回100W车的费用就是5-8亿RMB，如果仅仅是通过软件升级的话，这笔钱是非常可观的。
整车 OTA 应该成为汽车产业优先解决的问题，自动驾驶汽车可能确实对降低交通事故伤亡率有帮助，但如果没有靠谱的修补软件漏洞的方法，一旦面临大规模召回，消费者的不满情绪对品牌而言是最大的灾难。
我们细数下近些年发生的因软件问题而导致的汽车召回事件：
1. 2016 年，日产召回320 万因气囊系统问题无法识别乘客的车辆；
2. 2016 年，通用召回360 万气囊系统自动进入诊断模式的车辆；
3. 2017 年，道奇召回125 万辆安全气囊传感器故障的车型；
更严重的是，很多消费者在知晓车企发布的召回通知后，继续放任软件故障存在。根据调研机构 Stout Research 发布的数据，购买 5 年内的车辆在召回通知发布后的九个月内，维修率只有 40%。例如，2018 年通用宣布因方向盘软件故障召回 100 万辆车型，到现在约有 60 万台未得到修复的车辆仍行驶在道路上。
如果车企的整车 OTA 技术能够就位的话，对付这些 bug 就变得易如反掌了。而且 OTA 升级不光能让产品的电子系统保持最新，一旦出现因软件故障导致的召回，可以节省大量的时间和金钱成本。
汽车整车OTA升级为什么困难重重
1、汽车电子的架构介绍
ECU(Electronic Control Unit) 是电子控制单元， 也称“行车电脑”是汽车专用微机控制器。一般ECU由CPU、存储器(ROM、RAM)输入/输出接口(I/O)、模数转换器(A/D)以及整形、驱动等大规模集成电路组成。
最开始ECU是用于控制发动机工作， 后来随着车辆的电子化发展，ECU逐渐占领了整个汽车， 从防抱死制动系统、4轮驱动系统、电控自动变速器、主动悬架系统、安全气囊系统，到现在逐渐延伸到了车身各类安全、网络、娱乐、传感控制系统等。
随着车子电子化程度越来越高，尤其是自动驾驶、主动安全等功能的增加，车子的ECU会急速增加。汽车EE架构中存在着数十到上百数量的功能ECU，这些功能ECU由不同的供应商提供，不存在统一的中央代码仓库，其中运行着各种不同的操作系统及应用软件，以至于整车代码行数规模达到上亿级。过去分散的功能架构使得汽车不像现代手机一样有中央大脑处理器集中处理软件逻辑。在分散的EE架构中做整车OTA，就好比把30个人的脚绑在一起大家同时往前迈一步一样，这个协调难度比起只有2~3个人做这件事情困难很多。
传统软件应用开发，功能代码耦合，程序整体打包，修改部分逻辑，需整体重新编译跨控制器功能分散，所有相关控制器都需要更新软件。如果我要更新一个ABS，那关联的BCM、仪表、网关都要改，而且都分属于不同的供应商，代码也是别人写的。从这一点也应证传统车企被供应商绑架了。这个属于牵一发而动全身，比较麻烦。
2、传统整车厂还不具备OTA升级相关的条件
为什么这么说呢，目前够实现整车 OTA 功能的新能源车型共有 7 款，分别是蔚来 ES6/ES8、特斯拉 MODEL S/X/3、理想 ONE、小鹏 G3。
可以看到这些车型无一例外都是新能源车，他们的E/E架构与传统车的电气架构有着很大的区别，基本上核心的域控制的软件是在自己手里，才能实现整车的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必须支持软件回滚、断点续传、丢失重传等处理机制。
3、目前电子架构下，整车OTA时间非常长
人们都是利用自己熟悉的事物去思考和理解新事物的，讲到升级大部分人对升级的理解是手机上APP的升级，手机系统的升级，windows系统的更新等这些熟悉的事物，觉得升级是一件相对比较容易的事情。汽车软件升级要比手机和电脑升级所消耗的时间长，主要的原因是：
汽车内部各控制器的刷写需要时间。汽车内部各个控制器是有安全防护的，不是谁给我发刷写指令我就认的，首先要通过控制器的安全认证，然后将文件传输给控制器，控制器再重启完成刷写。如果中间出了错误，刷写不成功，还需要重试。这个过程类似于我们给电脑的硬件升级驱动程序，整个过程需要较长的时间。如果是遇到那种运算能力和存储空间小的控制器，需要将数据按照一定的格式慢慢的写进控制器里去。那消耗的时间就更多的。
汽车内部通讯网络的传输速度较慢。手机和电脑内部的数据传输是非常快的，为了保证数据传输的速度，内部总线的条数和传输频率都是很高的。汽车则大不相同，汽车内现在主流的还是采取CAN网络，理论上高速CAN的传输速率是1M/s,低速CAN的传输速率是125K/S，这些都是理论上，实际的传输速度要远低于这个速度，如果我们将一个100M的文件从一个零件传输到另外一个零件，消耗的时间本身就比较长。可能有人会问，为啥汽车里不能用网线呢。现在是有的，但关键就是成本啊。
基于以上两点，整车软件OTA的耗时会是小时来计算，升级的控制器越多，升级的时间也就越长。所以，各位车主如果想要给自己的爱车进行软件升级，最好是选择一个网络条件好，停车方便的地方，同时还得关注一下，自己的电瓶电量是不是够。另外，升级过程中车辆的一些设备是不能够使用的，也有可能会出现屏幕或者是仪表的突然黑屏或者是闪动等现象，不用担心，现在汽车软件远程升级技术已经非常成熟，所有的升级过程都是经过了非常严格的测试才准予上线的，有点小异常，只要等待的时间不是太长，完全可以忽略。
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提供价值。
第2篇
整车OTA需要注意些什么
上期我们聊了由于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，而黑客老王不知道密码，所以他看不到保险箱里边的东西，李四收到快递后用预先沟通好的密码就可以打开保险箱了。这里保护的手段就是张三对物品进行加密，同时给了告诉李四解密的方法！
那如果现在要求张三的密码只能通过快递传给李四呢？如果张三直接传密码给李四，老王如果嗅探到这个快递，那老王也知道密码了，这就无法保护快递的安全性了。因此还需要有个方案，让张三能够告诉李四密码的同时，老王又无法查看到张三跟李四通信的数据。
非对称加密在这个时候就发挥作用了，来看看怎么回事：
张三拥有两把钥匙，一把叫做公钥，一把叫做私钥。公钥是公开让全社会都知道，没关系，张三告诉所有人，你们要传递数据给我的时候请先用这个密钥(公钥)去加密一下你们的数据，加密后的数据只能通过张三私自藏着的私钥才能解密。
回到刚刚例子，
张三先发给保险柜（张三公钥）给李四，接着李四把自己的保险柜（李四公钥）放到张三的保险柜(即使用张三的公钥加密李四的公钥)里边发还给张三，接着张三拿到李四的数据包后，用自己的私钥解开了外层保险柜(张三的公钥)，拿到了里边李四保险柜(李四的公钥)。此时李四跟张三都有了各自的公钥(并且都有他们自己的私钥)，接着只要保证每次互相传递数据的时候，把数据放在对方的保险柜里边即可(即每次都用对方的公钥加密数据)，这样无论如何，老王都无法解开保险柜（因为只有各自的私钥才能解开各自的保险柜）。
从OTA基本流程中的安全防护来说。主要包含了升级包的加密与签名，服务器端对于升级包的安全存储，基于身份验证建立安全链接通道，以及汽车端信息安全防护，对升级包的验签和解密管控，需要配合OEM定义清晰的信息安全防护架构以及升级流程，最终还要通过专业第三方的渗透测试来验证OTA的信息安全防护能力达到预定的防护等级。
加密，是不让别人看见我传输的是什么内容。认证，就是确保车辆端、云端是我期望的、认可的对象。
比如车机进行软件升级时，要发出认证请求到服务器；服务器收到车端请求信息后，发回反馈，要求发送数字证书自证身份。车端发送数字证书到服务器端；服务器对数字证书进行校验是否存在问题；验证无误后终端管理系统向终端发送验证结果，这时才可以开始进行相应的软件升级。更新包会被加密后传输到车端，在T-box解密后再分发到车机。另外一个比较重要的车端部分是网关，可以避免ECU与联网的远程信息处理单元直接接触，提高了OTA更新的安全性。
第3篇
uboot介绍
前面提到FOTA，需要升级的时候如果涉及到uboot部分，这部分会要求非常高，毕竟我是硬件出身，就在这里班门弄斧简单通过有趣的内容给大家介绍一下uboot，为什么需要uboot。
先进行一下科普吧，大家都在家炒过菜吧，其实你发现做一顿晚餐的过程就特别像安卓系统的工作原理。
1、首先要有基本的炒菜的环境，厨房要有电、天然气要通气，有锅和铲子等工具，这些类似底层硬件的电源管理，需要有这些基本的电气条件满足。
2、其次要有炒菜的基本佐料，包括盐、酱油、白醋、陈醋,糖、味精、鸡精,生抽、老抽、香油,芝麻油,葱,姜,蒜,孑然,耗油、白胡椒、黑胡椒,番茄酱,花椒,辣椒,辣椒油。
无论你炒什么菜，都首先把这些佐料准备好，可能炒爆炒肥肠和番茄炒蛋所需要的佐料有很多不同的，但是盐和油肯定是都需要的，只是其他佐料有区别，这个不影响提前把这些炒菜的佐料进行准备好，尽可能的把这些佐料都准备齐全。
这里就相当于Linux内核层，进行USB接口、蓝牙、wifi、摄像头、音视频、显示屏等基本服务，可能不同的APP应用所需要调用的这些服务不同，比如一款聊天软件可能需要使用到WIFI、摄像头、显示等等，不需要使用USB接口，但是不影响另外APP会可能调用到USB、存储等等。
3、不知道你们炒菜是否需要菜谱，至少小宝我炒菜需要使用到菜谱的，需要百度一下某个菜需要什么佐料，什么样的配比材料，没错小宝这期内容修改为美食栏目去了，下面是网上水煮肉片的菜谱。
其实这里使用到的菜谱就可以理解为安卓系统里面的硬件抽象层，这里简单理解为，就是你如果知道这个菜谱中佐料的比例，在你自己家里炒菜和在朋友家里炒菜，这个炒出来的味道基本上也就味道相同，就可以理解为为什么这个在安卓系统中硬件抽象层可以在不同的平台进行移植，也就是掌握了菜谱的精髓，功夫我有，天下我走。
4、最后就是炒菜的动作了，其实熟练的厨师是可以至少掌握好几个菜同时操作，这个不仅考验厨师的速度，也考验厨师的精准度，对于火候的掌控要精准，对于佐料使用要合理分配。
其实这里炒不同的菜就类似于使用不同的APP的应用，这里如果有一个菜炒胡了，不能影响到另外一个菜的正常发挥，类似于多线程中的某个APP挂掉了，但是不能影响到其他APP的正常使用。
这里也会出现占用资源的情况，比如同时用两个锅炒菜，左边那个锅在炒爆炒肥肠，直接把所有的盐都一不小心全部倒完了，此时右边锅里面的菜也就报废掉了，没有盐的菜不能称之为一道菜。这个是不是类似于某个APP调用内存泄露，把全部的内存占用没有释放，导致机器只能重启。
安卓系统启动简单介绍
1、安卓系统平台架构
可以看出整个架构由5部分构成，从下到上分别为：
1. Linux内核层
Android 的核心系统服务基于Linux 内核，在此基础上添加了部分Android专用的驱动。系统的安全性、内存管理、进程管理、网络协议栈和驱动模型等都依赖于该内核。
2. 硬件抽象层（HAL)
硬件抽象层是位于操作系统内核与硬件电路之间的接口层，其目的在于将硬件抽象化，为了保护硬件厂商的知识产权，它隐藏了特定平台的硬件接口细节，为操作系统提供虚拟硬件平台，使其具有硬件无关性，可在多种平台上进行移植。HAL 由多个库模块组成，每个模块都为特定类型的硬件组件实现了一个接口，例如相机或蓝牙模块。当框架 API 调用设备硬件时，Android 系统为该硬件组件加载库模块。
3. 系统运行库层（Native)
系统运行库层分为两部分，分别是C/C++程序库和Android运行时库。C/C++程序库被Android中不同的部分使用 runtime库主要是Java核心库（提供了Java语言核心功能因此开发者可以使用Java编写应用）和ART（Android 5.0 之前是Dalvik）该虚拟机不同于JVM是专门用于移动设备的虚拟机 允许在有限的内存内运行多个虚拟机实例 并且每个应用都是独立的linux进程这样可以防止虚拟机崩溃时不会导致所有的进程被关闭。
4. 应用框架层（Java Framework)
应用框架层为开发人员提供了可以开发应用程序所需要的API，我们平常开发应用程序都是调用的这一层所提供的API，当然也包括系统的应用。这一层的是由Java代码编写的，可以称为Java Framework
5、应用层
系统内置的应用程序以及非系统级的应用程序都是属于应用层。负责与用户进行直接交互，通常都是用Java进行开发的
2、安卓系统启动介绍
上图是车载中控导航的系统启动的简单介绍
1. POWER 部分
目前的导航系统基本上都是CPU+MCU的架构，MCU进行电源部分的管理，CAN通讯的处理、收音部分的处理，所以这里的开电源的时候，一定是MCU完成整个中控导航系统的电源初始化。
MCU内部的电源管理器(regulator)将系统置于POR复位状态，直到VDD电压上升到超过POR复位门限电平，然后低电压检测模块会接管系统复位，直到VDD电压上升超过其LVR复位门限电平。在完成POR和LVR复位后，MCU系统的电源系统已经能够为内部时钟(FIRC、SIRC和LPO等)和存储器(NVM)模块以及CPU内核提供稳定的工作电压了。
这里的加载时间一般是500ms，这里考验的时间其实更多的是MCU的启动时间，一些整车的网络管理也要求ECU在低功耗模式唤醒后，能够尽快响应CAN/LIN总线报文，也要求MCU的启动时间要足够快。
一些功能安全要求较高的汽车ECU应用，比如电子助力转向(EPS)、电子档位控制(gear control)等，对于ECU的启动时间(startup/boot time)有严格的要求， 希望ECU使用的MCU能够尽快完成系统启动初始化，执行功能程序。
2. uboot 部分
这里的uboot主要进行CPU状态检查、DDR/emmc/usb等初始化，同时也有电源管理、USB升级检测等等，这里耗时基本上1S左右。
3.kernel部分
linux内核的启动，包括硬件初始化，驱动模块加载，包括USB、video、camera、touch等初始化，init进程，这里耗时1.5S左右。
4. Android初始化
init进程启动程序，zygote加载进程，系统启动服务。这里其实就是我们常见的开机动画就在这个初始化的时候完成的，这包含窗口管理服务，蓝牙服务、GPS服务，这里的GPS默认设置为打开状态，即服务初始化完成后就可以马上启动GSP定位开始，所以GPS的冷启动定位时间不是进入主界面开始算的时间，而且在动画界面初始化完成后就可以算时间了，这样可以让用户感觉体验更快就能GPS定位了。
5.主界面
系统启动，以下应用启动工作：收音、音视频播放、导航、语音、倒车、DVR、360全景、蓝牙等其他应用，这里的时间为2S左右。
一般的安卓系统启动时间为18S左右，应用启动2S，总计20S就可以正常操作APP应用了，这就是为什么安卓车机开机时间都会很久的，不太适合用于仪表，因为仪表要求开机5S左右就能正常显示工作。
从这个耗时来看，Android初始化的时间15S最长，所以要优化整个系统的启动时间的话，可以优先考虑这部分的优化时间。
吃瓜群众：小宝，你说的这些我都不懂，我们还是说回炒菜吧。
小宝：好的，那我们再来看看uboot在整个炒菜中，它是起到什么作用，初始化uboot，如果是炒菜，就是准备了哪些东西。
其实这里的uboot主要进行CPU状态检查、DDR/emmc/usb等初始化，同时也有电源管理、USB升级检测等等，想想炒菜之前是不是要检查锅是否干净，是否需要重新洗一遍，然后佐料这些是否足够，炒菜的燃气是否够大，有一个初步的火量大小的控制，等后面放好佐料后根据实际运气的情况再调节燃气大小的控制，就类似于前面初始化DDR和FLASH的运行速率，后面实际还可以调整这部分的运行速率。
Uboot 的简单介绍
1、为什么需要uboot
计算机系统的组成部件非常多，不同的计算机系统组成部件也不同。但是所有的计算机系统运行时需要的主要核心部件都是3个东西：CPU+外部存储器（Flash/硬盘+内部存储器（DDR SDRAM/SDRAM/SRAM）。
而一般的PC机启动过程为：PC上电后先执行BIOS程序（实际上PC的BIOS就是NorFlash），BIOS程序负责初始化DDR内存，负责初始化硬盘，然后从硬盘上将OS镜像读取到DDR中，然后跳转到DDR中去执行OS直到启动（OS启动后BIOS就无用了）。
总结：嵌入式系统和PC机的启动过程几乎没有两样，只是BIOS成了uboot，硬盘成了Flash。
从第一章节中我们简单介绍了Android系统的启动流程，Android系统的启动流程大致分为三个阶段：
1、电源键按下后加载引导程序Bootloader到RAM 然后Bootloader把OS拉起
2、Linux 内核层面的启动
3、Android系统层面的启动
这里的uboot就是刚开始被放到flash中，板子上电后，会自动把其中的一部分代码拷到内存中执行，这部分代码负责把剩余的uboot代码拷到内存中，然后uboot代码再把kernel部分代码也拷到内存中，并且启动，内核启动后，挂着根文件系统，执行应用程序。
2、uboot有什么特点
uboot 属于bootloader的一种，是用来引导启动内核的，它的最终目的就是，从flash中读出内核，放到内存中，启动内核。
1.自身可开机直接启动
1)一般的SoC都支持多种启动方式，譬如SD卡启动、NorFlash启动、NandFlash启动等·····uboot要能够开机启动，必须根据具体的SoC的启动设计来设计uboot。
上图是安霸A12的boot支持的启动方式，有NOR FLASH，NAND FLASH，USB、EMMC等多种存储设备，但是要注意，这里启动的地址默认都是从第一个零地址开始，比如NAND FLASH就是BLOCK 0启动，如果这个block损坏那么就无法启动，如果要跳转到block 1，那么就需要CPU芯片内部支持存储代码进行判断，否则只能从默认block 0启动。
2)uboot必须进行和硬件相对应的代码级别的更改和移植，才能够保证可以从相应的启动介质启动。uboot中第一阶段的start.S文件中具体处理了这一块。
2.能够引导操作系统内核启动并给内核传参
1)uboot的终极目标就是启动内核。
2)linux内核在设计的时候，设计为可以被传参。也就是说我们可以在uboot中事先给linux内核准备一些启动参数放在内存中特定位置然后传给内核，内核启动后会到这个特定位置去取uboot传给他的参数，然后在内核中解析这些参数，这些参数将被用来指导linux内核的启动过程。
3.能提供系统部署功能
1)uboot必须能够被人借助而完成整个系统（包括uboot、kernel、rootfs等的镜像）在Flash上的烧录下载工作。
2)裸机教程中刷机（ARM裸机第三部分）就是利用uboot中的fastboot功能将各种镜像烧录到iNand中，然后从iNand启动。
4. 能进行soc级和板级硬件管理
1)uboot中实现了一部分硬件的控制能力（uboot中初始化了一部分硬件），因为uboot为了完成一些任务必须让这些硬件工作。譬如uboot要实现刷机必须能驱动iNand，譬如uboot要在刷机时LCD上显示进度条就必须能驱动LCD，譬如uboot能够通过串口提供操作界面就必须驱动串口。譬如uboot要实现网络功能就必须驱动网卡芯片。
2)SoC级（譬如串口）就是SoC内部外设，板级就是SoC外面开发板上面的硬件（譬如网卡、iNand）
5. uboot的'生命周期'
1)uboot的生命周期就是指：uboot什么时候开始运行，什么时候结束运行。
2)uboot本质上是一个裸机程序（不是操作系统），一旦uboot开始SoC就会单纯运行uboot（意思就是uboot运行的时候别的程序是不可能同时运行的），一旦uboot结束运行则无法再回到uboot（所以uboot启动了内核后uboot自己本身就死了，要想再次看到uboot界面只能重启系统。重启并不是复活了刚才的uboot，重启只是uboot的另一生）
3)uboot的入口和出口。uboot的入口就是开机自动启动，uboot的唯一出口就是启动内核。uboot还可以执行很多别的任务（譬如烧录系统），但是其他任务执行完后都可以回到uboot的命令行继续执行uboot命令，而启动内核命令一旦执行就回不来了。
总结：uboot的一切都是为了启动内核。
1)uboot主要作用是用来启动操作系统内核。体现在uboot最后一句代码就是启动内核。
2)uboot还要负责部署整个计算机系统。体现在uboot最后的传参。
3)uboot中还有操作Flash等板子上硬件的驱动。例如串口要打印，ping网络成功，擦除、烧写flash是否成功等。
4)uboot还得提供一个命令行界面供人来操作。很简单，至少你能看到。
3、Uboot完成后进入的模式有哪些。
安卓开机后，硬件系统上电，首先是完成一系列的初始化过程，如 CPU、串口、中断、timer、DDR 等硬件设备，然后接着加载 bootloader，为后面内核的加载作好准备。在一些系统启动必要的初始完成之后，系统会通过检测三个条件来判断要进入何种工作模式，流程如图。
这里重点说说Recovery模式，我们可以简单的理解为工程模式，手机进入Recovery模式可以进行重启手机、清空SD卡数据、恢复出厂设置、刷机、备份与恢复数据等诸多功能。
以前买到小米手机，手机无法正常开机进入不了系统了，此时就从百度上搜索怎么强制恢复出厂设置，方法是先关闭小米手机，然后同时按住“小米3音量+键”和“电源键”，大约3s左右，即可进入小米3Recovery模式了。
怎么加快uboot的启动时间
1、使用通讯速率快的存储，接口需要不占用
一些功能安全要求较高的汽车ECU应用，比如电子助力转向(EPS)、电子档位控制(gear control)等，对于ECU的启动时间(startup/boot time)有严格的要求， 希望ECU使用的MCU能够尽快完成系统启动初始化，执行功能程序。此外，一些整车的网络管理也要求ECU在低功耗模式唤醒后，能够尽快响应CAN/LIN总线报文，也要求MCU的启动时间要足够快。
在有双核的CPU的时候，可以在不同的内核执行不同的程序，这样可以缩短启动时间。
液晶仪表的开机速度要求比较快，一般要求在6S之内要进行开机进行工作，这样就可以更快的让用户处理相关的车身检测和报警功能。
其实这里比较简单粗暴的方便就是使用通信速度更快的存储，下图就是东芝产品介绍boot time的在使用普通NOR flash，EMMC、UFS的存储设备，可以看到UFS接口的EMMC在64MB的数据下，也就115ms可以运行完成，而SPI NOR FLASH需要1185ms，基本上差了10倍时间的差距。
这里唯一的不同就是存储设备的通讯速率不同，UFS的通讯速率可以达到850MB/S，而NOR FLASH最快也就是54MB/S。
在仪表赛普拉斯推荐的平台上，使用hyperflash，可以让开机时间在2S之内。
赛普拉斯主推的hyperflash，独占带宽无抢占的情况下，目标带宽为200MB/s，1280x480的标清屏的开机速度可以达到0.7S。目前创维汽车智能在使用这个平台供货仪表，做的非常棒。
2、优化一些时钟、ECC校验等方法加快启动速度（参考浅谈嵌入式MCU软件开发之S32K1xx系列MCU的启动过程和启动时间优化方法详细）
下图是S32KXX系列的MCU的启动流程图，首先是关闭CPU到的全局中断，把CPU的内核寄存器清零，初始化SRAM的ECC，然后进行系统的初始化等等。
比如在MCU的硬件加密模块CSEc的安全启动(Secure boot)功能，建议使用串行(Sequential) Secure boot而不是并行(Parallel) Secure boot, 因为后者工作时CSEc和CPU内核都会访问P-Flash，从而导致CPU内核从P-Flash取指令的速度变慢，从而拉长Startup运行时间，而且Secure boot运行完之前不允许修改系统时钟配置(尤其是Flash的工作时钟FLASH_CLK)：
Freescale S12G系列汽车MCU的外部晶振时钟起振时间如下，作为参考，也是频率越高，启动越快(start-up时间越短)
BOOT升级的模式
正常情况下，下载了升级固件，肯定是要把新固件替换到老固件，这个时候就涉及到两种模式。
其实这个最容易理解了，小宝给你说一个生活中的例子就好理解了，你手里拿着一个冰淇淋，现在老板告诉你有新款的冰淇淋来了，可以免费领取一个，你会怎么做呢？
有的人是把手里的冰淇淋扔掉，直接去领取新的冰淇淋，这样的做法是不占用手的资料，反正都只占用一个手，缺点就是可能去排队的时候，老板新的冰淇淋都领取完了，这个时候你就一个冰淇淋都没有了。
有的人的做法是先排队，确认领用到新的冰淇淋后再把老的冰淇淋扔掉，此时在领用的过程中会耗费掉两个手的资源，不过这样最保险，哪怕没有领用到最新的冰淇淋，老的冰淇淋还可以继续吃。
同样的道理，新固件替换老固件覆盖的两种方式：双区模式和单区模式。
双区模式：
双区模式中老固件和新固件在flash中各占一块bank（存储区）。假设老固件放在bank0（运行区）中，新固件放在bank1（下载区）中，升级的时候，应用程序先把新固件下载到bank1中，只有当新固件下载完成并校验成功后，系统才会跳入BootLoader程序，然后擦除老固件所在的bank0区，并把bank1的新固件拷贝到bank0中。后台式下载必须采用双区模式进行升级。
优点：升级过程中出现问题或者新固件有问题，它还可以选择之前的老固件老系统继续执行而不受其影响。
缺点：多占用flash空间的一个存储区，在系统资源比较紧张的时候较为困难。
单区模式：
单区模式的非后台式下载只有一个bank0（运行区），老固件和新固件共享这一个bank0。升级的时候，进入bootloader程序后先擦除老固件，然后直接把新固件下载到同一个bank中，下载完成后校验新固件的有效性，新固件有效升级完成，否则要求重来。
优点：跟双区模式相比，单区模式节省了Flash空间的一个bank，在系统资源比较紧张的时候，单区模式是一个不错的选择。
缺点：如果升级过程中出现问题或者新固件有问题，单区模式碰到这种情况就只能一直待在bootloader中，然后等待再次升级尝试，此时设备的正常功能已无法使用，从用户使用这个角度来说，可以说此时设备已经“变砖”了。
相比较，双区模式虽然牺牲了很多存储空间，但是换来了更好的升级体验。