公众号前面几篇文章，笔者已经对FOTA、SOTA、信息安全等内容进行了系统性的综述。从本期开始，笔者将开设技术专栏，分别对上述主题展开更详细、深入的介绍，以飨读者，也期望在和同行的交流中碰撞出更四射的火花。
首先推出的是FOTA技术专栏，专栏第一篇文章，笔者将介绍整车部分控制器FOTA技术实现所需仰赖的底层技术之一：UDS刷写。
UDS（Unified Diagnostic Services，统一诊断服务）刷写，指的是基于应用层协议（ISO 14229)和网络层协议（与通信物理层相关，如面对CAN总线的ISO 15765-2）定义的控制器软件升级流程。
UDS刷写应用对象一般为采用ETH/CAN/LIN等总线通讯的车载传统控制器。车载传统控制器主芯片以MCU为主，MCU上主要运行嵌入式实时操作系统。UDS刷写主要是通过诊断上位机（Tester）给车载传统控制器发送定义好的诊断服务命令实现。
与车载传统控制器相对应的是存在高算力芯片的控制器，民间常称之为智能控制器。此类控制器一般存在双分区结构且具有满足POSIX标准的操作系统（一般为Android、QNX或Linux等），其软件升级流程一般自主实现，本文介绍的UDS刷写技术暂不适用此类控制器。
UDS线下刷写的应用历史已有几十年，最典型的应用场景是在4S店。帅气的技师们扛着电脑或者专用的诊断仪对车辆控制器进行软件升级便是UDS线下刷写的最生动体现。在这一场景中，电脑或诊断仪作为上位机，通过车辆OBD口接入整车网络总线，并将升级包（一般为hex，s19格式）按主机厂定义的的刷写流程对车辆控制器进行刷写。
UDS线上刷写的应用伴随着FOTA技术的成熟而得到不断推广。在FOTA的通用技术架构下，一般由FOTA的升级主控（升级Master）作为上位机，升级主控从云端下载升级包，并按照固定的刷写流程或者升级包中配置的刷写流程，对车辆上的对手件进行刷写。
UDS刷写无论线下还是线上，都离不开控制器中Bootloader以及UDS协议的支持，在正式介绍UDS刷写流程之前，笔者先简介上述两部分内容。
Bootloader称为引导加载程序，是软件执行的第一步，无论是否使用操作系统，Bootloader都是必须执行的。
我们日常办公电脑中的Windows系统是由BIOS引导启动的，BIOS开机自检并分配资源后，将Bootloader 读到系统的内存中。随后Bootloader获取电脑控制权，将指针带到系统内核，开始启动操作系统。
上文介绍的车载传统控制器启动过程同样离不开Bootloader的帮助。Bootloader初始化硬件设备，建立内存空间映射图，将系统的软硬件环境带到一个合适状态，以便为最终调用操作系统内核准备好正确的环境。在控制器软件升级过程中，Bootloader进入编程会话后会擦除指定地址的程序，并写入新的程序，从而实现控制器的软件升级，后文会详细阐述该过程。
UDS协议就是ISO 14229标准的别名，全称为统一诊断服务的应用层协议，标准规范了基于Bootloader的刷写过程。各家主机厂均是基于UDS协议制定企业的诊断刷写规范，在控制器的SOR阶段会一同释放给供应商。
对于各控制器的供应商而言，刷写流程的统一简化了开发复杂度。UDS协议可在不同的汽车网络通信（例如CAN、LIN、 Flexray、 Ethernet 和 K-line）上实现，最常用的为UDSonCAN和UDSonIP（DoIP）两种。下图为ISO 14229中各车内总线实现UDS协议的网络模型图。
以UDSonCAN举例， CAN总线协议是汽车内最常使用的总线协议，每帧仅有8字节，ISO 15765-2解决了ISO 11898协议中定义的经典CAN数据链路层与ISO 14229协议中定义的应用层数据长度不一致的问题。ISO 15765-2中定义的内容包括网络层和传输层的协议，包括寻址方式（物理寻址、功能寻址），组包方式、协议控制信息、流量控制以及时间控制。
UDS协议是一种交互协议，呈现一问一答的通信方式，提供了26种服务，各服务在报文中通过SID（Service Identifier，诊断服务ID）来区分。在UDS刷写流程中，主要应用的服务如下表所示。
10/27/11/3E等服务是基础诊断和通信相关服务，作用是切换系统的会话模式、安全模式解锁、重启ECU以及保持链接活跃；
22/2E读写DID的服务主要是为了读取版本号、VIN等信息，同时写入诸如指纹、VIN码等相关信息（OEM自定义）；
85/28服务主要是为了暂停其他控制器网络报文的发送和DTC的设置，使得刷写条件和网络带宽能达到最佳的状态；
31/34/36/37则是数据下载相关服务，负责数据下载的请求、传输和退出。
会话模式是诊断领域非常重要的一个状态机，不同的会话模式是用来区分诊断服务执行权限。UDS协议定义了三种会话模式：默认会话、编程会话、扩展会话，不同的会话模式可以相互切换。在Application中可使用默认会话模式和扩展会话模式。在Bootloader中可使用默认会话模式和刷新会话模式。
会话切换流程如下图所示，主要通过0x10服务在三种会话模式之间切换。
UDS刷写流程包括三部分：预编程阶段、主编程阶段和后编程阶段，如下图所示。其中，白色框步骤为功能寻址，蓝色框步骤为物理寻址。各家主机厂会根据实际情况对方案进行微调。其中Client为升级客户端，往往由诊断仪或FOTA master担任。Server指的是升级控制器端。
一、预编程阶段
此阶段是刷写前的网络准备工作，主要内容包括（1）检查升级前置条件；（2）提高刷写网络速度；（3）禁止其他ECU的网络报文并关闭DTC设置。
1、Client功能寻址发送0x10服务将所有控制器切换至扩展会话模式，以支持0x85服务和0x28服务；
2、Client物理寻址发送0x31服务至Server，判断当前是否满足升级的前置条件，如点火状态，车速等判断；
3、Client功能寻址发送0x85和0x28服务，禁用CAN总线上各Server的网络报文和DTC设置；
4、Client通过0x22服务读取控制器的DID数据；
5、Client在会话过程中通过0x3E服务保持与Server的会话模式
二、主编程阶段
此阶段是控制器的刷写主流程，在Bootloader的编程会话模式下进行，步骤如下：
1、Client功能寻址发送0x10服务将待刷写的Server切换到编程会话模式；
2、Client通过0x2E服务将指纹写入Server，例如本次刷写人的身份；
3、Client通过0x27服务向Server求安全模式的seed，并根据约定的算法得到key，Server验证通过后解锁安全模式。安全模式的作用是以防电控单元被意外地擦除或未经授权地刷新；
4、Client通过0x31服务擦除Server指定地址段的程序；
5、Client通过0x34服务请求数据下载，Server回复一次0x36服务传输数据的Block的最多字节数；
6、如果0x34服务得到了正确响应，Client就开始使用0x36服务启动数据传输。下载的数据是连续的，可使用34-36-36…-37命令实现。如果数据不连续，则需要重新进行0x34服务；
7、所有的0x36服务完成后，Client通过0x37服务请求退出传输；
8、Client通过0x31服务不同的子功能对程序的完整性和一致性进行验证；
三、后编程阶段
1、Client通过0x10服务恢复控制器的默认会话；
2、Client通过0x14服务清除Server中的故障码，整个刷写流程结束。
当前FOTA升级的一般策略是串行升级，即每个控制器升级完成后再对下一个控制器进行升级，单一时间只对一个控制器进行升级。如任务中有多个车辆控制器需要升级，则会对本次任务的升级时长和车辆电瓶电量提出挑战。如果能够在FOTA中并行刷写多个控制器，充分利用总线带宽，可减少OTA升级时长，实现整车的快速升级。
因此，并行刷写在FOTA的应用引起了各家主机厂的关注。产线的线下诊断仪刷写其实已实现了并行刷写，优势在于可缩减产线的工位数，并提高生产效率。当前并行刷写常用的做法为上位机开启多个刷写线程。不同总线间的并行刷写相对容易实现，如同时对CAN总线上的控制器和车载以太网上的控制器在同一时间进行刷写，总线之间的干扰并不大。
而对连接在同一网关下，不同路CAN上的两个控制器进行刷写，如Body CAN和Info CAN上的控制器并行刷写。上位机开启多个线程并且打开多个CAN通道 ，可通过通道号的不同对每个控制器进行识别，防止报文传输过程中不同控制器的报文相互冲突造成的报文混乱问题，实现了一上位机对多控制器的CAN报文传输。
与此同时，虽然开辟更多的RAM去处理诊断指令可以使得刷写速率更快，但是资源开销问题也不容小视。尤其当总线转换时，传输层和网络层的资源开销也会上升。上位机的RAM资源的消耗，处理能力足够与否，都需要O主机厂按实际情况和需求评估。
本期简单介绍了UDS刷写的基础知识，下一期，FOTA技术专栏将会介绍智能控制器常用的升级方式，A/B升级（汽车OTA领域的标杆企业ABup，其英文名称前两个字母寓意也来源于此）。
初心 | 记录生而为人的证据，分享工农阶层原创作品，聚焦智能网联与人情冷暖。
声明 | 本文部分文字及图片资料取自网络，如有侵权，请联系平台进行修改或删除；文章属于作者本人，仅代表个人观点，不代表平台立场，如有不妥，也请联系平台修改或删除；本文不作任何商业用途。
原文始发于微信公众号（十一号组织）：FOTA技术专栏—UDS刷写
