标签: 空中升级

什么是汽车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行为，再比如人车交互在实车环境中的感受这一类偏向主观体验的场景，需要根据经验和人的主观判断进行评估并提出合理建议。 第二期已上线： 一键了解汽车OTA技术（二）-面包板社区 (eet-china.com)

BLE 空中升级谈   -- CC2541 的产品开发中OAD注意事项(续）   TI CC2541支持多个硬件，多个软件对它进行空中升级，可以有不同的组合，硬件有     编号 名称 Hex 用法 1 Cc2540 dongle CC2540_USBdongle_HostTestRelease_All.hex 直接插在电脑上使用，驱动程序是ccxxxx_usb_cdc，usb作为CDC串口使用。 2 Cc2541 module CC2541_SmartRF_HostTestRelease_All.hex 需要一个USB-UART,或者RS232-UART接口板，连接模块的P02,P03(UART0) 3 Cc2540 module CC2540_SmartRF_HostTestRelease_All.hex 需要一个USB-UART,或者RS232-UART接口板，连接模块的P02,P03(UART0)   目前可以使用的软件有   编号 名称 平台 可用硬件 用法 验证 A BLE device monitor Windows PC 2，3 电脑与模块连接，可借助RS232-UART,或者USB-UART接口板，连接上以后的操作见软件使用向导。 是 B BLE device monitor Android BLE android 手机 apk文件没有找到 否 C Bluetooth LE OAD tool Windows 8/10 带 BLE BLE win8 / win10 电脑，可用dongle 将boot + imageA写入目标设备后，在系统设置/蓝牙中绑定设备，如果要输入PIN的话，输“0”，之后运行app,刷新列表后可以选定目标开始升级。 是 D TI BLE Multitool iOS iPhone4s以上（含） 点此查看 否     以A2的组合来实现空中升级是比较容易凑齐硬件的，只是要注意A的串口配置，不要带流控，若是A1组合，则可以在ti.com找到很详细的说明，也可点 这里 。其他的软件基本可以相应平台直接运行， 不需要额外的硬件。   硬件齐备之后，准备一个可以用来升级的image B，TI-BLE Stack 1.4.0当中的SimpleBLEPeripheral工程有个CC254x-OAD-Img B选项，原封不动的编译生成一个bin文件就好了。它就是接下来空中升级的主角，为了说明，我们不妨给生成的文件取名为imgBSample.bin。   传输imgBSample.bin的时间在各个组合里是不一样的。通常生成的bin文件也就刚过100kb，使用BLE传输完成它，这几个平台都可能要3到4分钟，区别不大。但若使用原生的Image A，在windows 8/10就差不多要18分钟。这是非常慢的。想要缩短这个时间，密决就是调整连接参数。本人使用Bluetooth LE OAD Tool (WIN 10)，简单测试过连接参数对传输时间的影响，大致如下。   序号 连接间隔 connInterval   SlaveLatency   Timeout OAD耗时 Time 说明   1 6 1 50 3:27   2 48 0 960 18:00 Windows默认 3 11 0 50 4:58   4 6 0 50 Failed   5 7 0 50 Failed   6 8 0 50 3:49   注：这里的连接间隔1代表1.25ms   图一 Newbit Bluetooth LE OAD Tool 界面   传输完成后，系统自动重启，然后运行imgBSample.bin这个程序。但通常也会遇到如下问题，传输完成了，本应自复位后运行新程序，结果一定要手动复位才能正常运行，建议使用开发板来验证，若开发板可以自动重启并正常运行，说明程序没错，接着就要检查硬件了，比如电源供电，是否有32K晶体等，具体可以参考这里。     完成以上所有工作，那么你已经完整的体验了空中升级，若只是按照这样做也还是Demo, 并不是一个产品所需要的空中升级，完整的空中升级还应该有完全保护措施，比如升级的客户端身份确认， 升级失败后的处理，甚至断点断传也可考虑进来。据说nordic可以实现增量升级，可以大大地缩短升级的时间，但不清楚它具体如何实现。当然，关于这些暂时就不多说了，若见此文的你有兴趣，我们可根据本文所描绘的空中升级，在2541上做一个boot, image A的固件，外带image B的模板。   附windows 10, ios 8.3, miui 6的BLE连接参数默认值   Platform connInterval SlaveLatency Timeout Win10 48 0 960 MIUI 6 39 0 700 IOS 8.3 24 0 72      

BLE  空中升级谈   -- CC2541  的产品开发中 OAD 注意事项     现在的智能设备（可穿戴，智能家居，智能玩具等）是越来越多了，大公司的产品颜值高，功能强大而完备的应该说是比比皆是，这里不谈论它是满足所谓的刚性需求。许多新 (shan) 创 (zhai) 公司做的产品就只能凭一面之缘了，要是喜欢你就买下，反正后面觉得哪里不好，用着不爽就扔掉便是，看官自是不缺这几十一百块钱。比如像小米的一代手机  Mi BNAD （现售 69 ） , 电子称 Mi Scale （现售 99 ）。虽说便宜事实上这确是匠心之作，就本人了解，从空中升级来看，它们就很棒，设备它的目前的程序存在严重问题，或者它的功能在现有硬件资源还能进行合理的扩增，小米会在后续推出相应的 firmware ，就算产品已经到了用户手上也可以得到升级，这一切都是免费的，甚至是不知不觉的，要不怎么说相信大公司呢。所以有着完美主义情节的在下总觉得空中升级就应该是此类设备必备的功能（之一）。   前言说小米是大公司，产品有带空中升级，话外音就是想说当前市面上许多众筹，或者外贸品牌转内销，一些刚开创的小牌产品，基于快速上市这一当前市场的最高原则，几乎把这个“不 (hen) 起 (zhong) 眼 (yao) ”的功能给选择性忽略了。话说在这里，不怕砖块。事实上这个功能之于产品是非常重要的， 对于这些很容易就被弃之不用的小物件是极重 / 相当重要的！   这么重要的功能，如何开发呢，以低功耗蓝牙来说，本人最早自 TI BLE Stack 1.4.0 开始了解，也基于这里开始开发。而这个版本的协议栈，就已经自带了空中升级的例程，并且编写了相当不错的 boot ，这是从 IC 原厂的角度来看，也是 IC 原厂的态度，一个小的 智能设备 本来就应当具备空中升级。没错，不用怀疑，必须的特性。虽然原厂给了这么大力的支持，还是很遗憾，现在市面还是有不（ zhu ）少 (duo) 产品就是没有空中升级的，让人难予置信。除了 TI ， 其他原厂比如 NODIC 也有，这是半导体大厂的共识。 有了这么好的基础，想演示空中升级已经是极其容易了，于是应该也出现了按照这个 demo 水准而推出的“产品”，但我没有去一一验证过，相信找找肯定还是会有的。有的产品根本没有，有的也只是一个 demo ，这让趟这行浑水的人总觉得世间坑无数，此处再添来的感慨。好了，牢骚发完，谢谢各位的耐心，我再接着讲讲这个空中升级也称 Upgarade over the air( 简记为 OTA), Over Air Download （简记为 OAD ），大概怎么来做，原谅这里也不会太详细，详细的部分各方案的开发向导中就有，可能是英文的，但也容易读懂。以 TI 的 CC2541 为例，对于其他 IC 请举一反三。   第一条 是了解原厂的空中升级方案，作为一线开发者，要达到深入的理解，只是了解还不够的。 TI 的 OAD 方案大致是使用  boot + image A + image B 这样的方式， boot 负责启动系统， image A 能更新 image B ， 反过来 image B 也能更新 Image A ，这样设备就可以反复进行 OAD 了，  Image A/B 的作用是完全等同的。而通常在实际的开发中，  image B 才是设备正常使用时运行的程序 , Image A 仅是用来更新 Image B 会更好，一来安全，再者可以让 Image B 有更多的空间。按照后面的设计它们分别占用三个分区，仅 image B 区域是可以擦除的。另外还有一个区域是前面三者共同使用的，用于存储用户信息等，这个空间是共享的。具体的解读可以找度娘。 STEP BY STEP 1,  http://bbs.ednchina.com/BLOG_ARTICLE_3019402.HTM   干货在后面。 未完待续。。。