伴随着时代的改变，自己的日子如同解冻的江河，在阳光下的大地上纵横交错。人至中年，自己好像是积压了太多能量的江河，生命的浪潮在自己的河床上奔腾起伏，将自己的成年岁月变成了一道动荡不宁的急流。生命中诸多不可避免事宜向自己涌来，也让自己出现了情绪波动，现在的自己需要沉淀下来，让自己心如深湖，水下奔流激荡，湖面寂静如镜。
我们的人生是不能以明快或抑郁来简单划分的，也有阴影这个中间地带。能够认识和理解这个阴影阶段，才算得上是健全得知性，而获得健全得知性是需要相应得时间和辛劳的。类似于手机系统版本，随着时间推移在不断更新（推出系统新特性、解决老版本软件Bug等）。该特点也在慢慢引入到新能源电动车上面来，由于技术加需求的快速迭代，这样也可以成为新的盈利模式（特别是在车载娱乐域，一些新的特性会带来更好的用户体验，但是这些升级需要收费）。本文基于个人浅薄认识，分享下传统车载升级模式流程和OTA模式架构（只谈原理，不涉及技术细节，每家都不一样）。
传统车载网络是以CAN总线为主导地位，本位也以CAN总线为例分享传统刷写流程。在上位机加载待刷写ECU需要的Flash Driver、Flashdata以及刷写需要执行的刷写序列（Flash sequence）。3、待刷写ECU底层有Bootloader协议栈；执行刷写序列，进行内存擦除和写入操作，检验刷写数据的一致性和完整性。预编程过程是为 ECU 编程过程做网络功能设置的准备工作。首先由 Tester 端发送诊断服务 ID$22 用于阅读关于编程的信息日期、当前会话或引导装载程序版本（为测试人员和用户提供有用的信息）。再发送诊断服务请求$10$03，进入 extendedDiagnosticSession。接着发送诊断服务 ID$31$01+Routine ID，检查 ECU 升级的准备条件，确保系统在一个安全的状态下能够使 ECU 升级过程顺利进行。发送诊断服务 ID$85$02,使 DTCSetingType=off。DTC 的诊断和存储功能使不能，使网络资源可以全速提供给 ECU 升级。最后发送诊断服务 ID $28$03$01，切断需升级 ECU 与车载网络和其他 ECU 的通信联系。 在 Step1 执行完成后，进入升级过程中的第二步：Programming Step。首先发送诊断服务ID$10$02 ， 得 到 积 极 反 馈 信 号 后 进 入 Programming Session 模 式 。发 送 诊 断 服 务ID$27$11/$12，请求秘钥和发送秘钥解锁所要升级的 ECU。接着发送诊断服务 ID$2E$F1$84,获取 Tester 的 fingerprint，并保存在非你丢失的内存中。发送诊断服务 ID$34$36$37$31，下载 Flash 驱动，根据驱动头文件信息可以获取请求下载、发送数据和发送数据口等服务。 接下来发送$31，开始擦除内存。擦除内存后，所升级的数据分成 Segment，通过发送诊断服务请求$34$36$37,升级所需数据分好 Segment，确定好内存开始的地址和 Segment 的长度，传送数据。在此 Logical 块完成后，通过$31 检测是否还存在其他 logical 需要下载数据。若需要，从下载 Flash driver处开始。通过诊断服务请求$31$01$FF$01，确保所有 Logical 块都已经下载完成。 这是升级过程中最后一步，Tester 发送诊断服务请求 ID$2E$F1$99，写入刷新 ECU 日期等信息。接着通过$11$01,重启硬件完成升级（刷新）。全称“Over-The-Air technology ”，即空中下载技术，通过移动通信的接口实现对软件进行远程管理，传统的做法到4S店通过整车OBD对相应的ECU进行软件升级.汽车OTA升级就好比电脑的Windows系统升级，或者也可以理解为手机系统的升级，每次升级都可以得到改善、修复漏洞或者获得更多的功能、性能提升，又或者是视觉效果的改善，且这种更新是通过联网后在线检测、匹配版本、下载新的代码到本地进而执行安装、校验等程序。博世提出的电子架构发展路线图。汽车的电子架构，将从各自为战的分布式ECU，最终转化为基于云计算单一计算芯片结构（HPC）。而对于支持OTA的车型，必须拥有至少基于域控制器的全新电子架构。只有将整车各自为战的上百个ECU电控单元，进行集中管理，才能使上层软件更加灵活和快速的调用底层信息，并进行融合计算、快速输出。如上图是自己简略画的一个架构图。OTA是在线升级，因此首先需要一个云服务器，车载端需要一个支持无线功能的节点模块（e.g.T-box）。1、首先具备无线功能的车载节点接收云端以差分算法发送来的数据；2、将下载的数据在GW存储（存储策略不确定），该节点具备Flash Manager、Security Manager等策略；3、作为人机交互端，中控屏可以显示出车身具备升级的可能性以及是否升级的主动权（由驾驶员控制）。1)升级安全是OTA的最基础的要求。车辆上ECU的软件运行状况直接会影响到车辆上的人员的生命安全。从升级包制作，发布，下载，分发，刷写等环节，OTA需要从云，网络，车端来保证安全。在云端通过证书，签名和加密机制保证升级包的不会随意被制作和发布，升级包内容不会被恶意获取。通过冗余设计保证整车的功能可靠性，通过安全启动来保证可信的软件在ECU上加载启动运行。2)在OTA实现策略中，控制器版本管控很重要。因为车辆上ECU众多，不同ECU有不同版本的软件，不同车型ECU的需求有不同，版本也存在差异。版本的升级路径管理，需要能够全面准确进行管控3)整车升级进行车载ECU刷写时，特别涉及动力域传统ECU的刷写，是通过CAN网络进行安装包的分发。由于CAN传输速率很低（实际典型的速率为500Kb/s），并且CAN总线负载率通常要控制在30%以内，因此在带宽允许的情况下，尽可能采取并行刷写模式，选取刷写时间最长的节点优先处理等设计原则减少OTA升级时长。4)防变砖等异常处理。在OTA传输过程中，外界干扰或者其他因素导致刷写异常或者中断，车载ECU必须支持软件回滚、断点续传、丢失重传等处理机制。比如通过A/B分区实现软件回滚。当刷新软件不可用或者失败时，回滚到分区中备份的旧软件版本，保证控制器正常运行。
----------------------------------- 作者简介 | 穿拖鞋的汉子 汽车电子工程师 公众号：车载诊断技术 chuantuoxiedehanzi@163.com 来，每天进步一点点！
|
