基于刷写的一些反思.docVIP

基于刷写的一些反思 类似于手机系统版本，随着时间推移在不断更新（推出系统新特性、解决老版本软件Bug等）。该特点也在慢慢引入到新能源电动车上面来，由于技术加需求的快速迭代，这样也可以成为新的盈利模式（特别是在车载娱乐域，一些新的特性会带来更好的用户体验，但是这些升级需要收费）。 本文基于个人浅薄认识，分享下传统车载升级模式流程和OTA模式架构（只谈原理，不涉及技术细节，每家都不一样）。 一、传统刷写流程 传统车载网络是以CAN总线为主导地位，本位也以CAN总线为例分享传统刷写流程。 实现对ECU刷写常规要满足如下三个条件: 1、PC端上位机； 在上位机加载待刷写ECU需要的Flash Driver、Flashdata以及刷写需要执行的刷写序列（Flash sequence）。 2、PC与车辆（控制器）总线连接； 进行刷写数据传输的载体连接。 3、待刷写ECU底层有Bootloader协议栈； 执行刷写序列，进行内存擦除和写入操作，检验刷写数据的一致性和完整性。 对于刷写流程，主要分： ?Pre-programming Step ?Programming Step ?Post-programming 1、Pre-programming Step 在UDS协议中对相应阶段都有笼统的定义，如下： 是UDS协议定义或者推荐内容。 预编程过程是为 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 的通信联系。 2、Programming Step 在 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 块都已经下载完成。 3、Post programming 这是升级过程中最后一步，Tester 发送诊断服务请求 ID$2E$F1$99，写入刷新 ECU 日期等信息。接着通过$11$01,重启硬件完成升级（刷新）。 二、OTA模式 全称“Over-The-Air technology ”，即空中下载技术，通过移动通信的接口实现对软件进行远程管理，传统的做法到4S店通过整车OBD对相应的ECU进行软件升级. 汽车OTA升级就好比电脑的Windows系统升级，或者也可以理解为手机系统的升级，每次升级都可以得到改善、修复漏洞或者获得更多的功能、性能提升，又或者是视觉效果的改善，且这种更新是通过联网后在线检测、匹配版本、下载新的代码到本地进而执行安装、校验等程序。 如下图： 博世提出的电子架构发展路线图。汽车的电子架构，将从各自为战的分布式ECU，最终转化为基于云计算单一计算芯片结构（HPC）。而对于支持OTA的车型，必须拥有至少基于域控制器的全新电子架构。只有将整车各自为战的上百个ECU电控单元，进行集中管理，才能使上层软件更加灵活和快速的调用底层信息，并进行融合计算、快速输出。 如上图是自己简略画的一个架构图。OTA是在线升级，因此首先需要一个云服务器，车载端需要一个支持无线功能的节点模块（e.g.T-box）。 以下是个人很窄的观点，欢迎留言