之前聊过Bootloader的刷写流程，其中是引用的ISO14229规范里的。[Bootloader刷写流程、刷写测试、自更新方案梳理]，那真正的一份Bootloader[以下简称Boot]企标需要什么内容呢？今天就一起来聊聊。

首先从章节上来说包含，概述、通用需求、编程过程、附录四个部分。

01.概述

概述包括文档的适用范围，例如只适用基于DoCAN刷写的MCU类控制器，其次包括参考文档描述，一般包括其他的企标，包括诊断规范、ISO-14229-1、15765，以及这些规范的具体版本。比如ISO14229-1的2013版。

除此之外还有术语和缩写的说明，例如如下表。

02.通用要求

首先是对通用需求的总体描述，例如所有支持应用软件及应用程序数据（包括网络配置数据和标定数据）编程的 ECU，应当包含 Boot软件。在正常运行过程中，执行的是应用软件和应用数据。仅当应用软件或应用数据失效，或者要求对此进行升级的时候， Boot软件才被激活。

应用软件和应用程序数据可以同时编程或者相互独立编程，禁止更新 Boot软件。

接下来则是描述各个部分的通用需求。

首先是硬件需求，可编程的ECU必须提供足够的存储器来维持下载，提供充足的缓冲空间来满足编程定时要求。用于编程的网络层缓冲区所占的字节数应该得到主机厂的认可。编程循环动作（擦除/写入）的次数满足引用的部件规范。

第二则是软件需求，Boot软件必须存储在被保护的存储器中，从而确保即使存在潜在错误， ECU始终是可编程的。

如果没有有效的应用软件， Boot软件将I/O口设置到一个安全的状态，从而避免车辆或操作人员出现危险。为了使ECU进入低功率状态，推荐 I/O 端口设置成最小功耗状态。

第三则是安全需求，为确保下载的安全性， ECU 应该实现一些安全需求， 避免下面几种情况：

1) 来自非法源的软件下载动作；

2) 下载错误的应用软件或者应用数据到 ECU；

3) 当前重编程条件不满足；

4) 软件之间不兼容。

诊断以上四部分，首先是安全访问，所有可编程的 ECU 应该支持种子和密钥的安全特性，并且可以通过安全访问服务（27h）进入访问，从而保护 ECU 免遭未授权的编程动作影响。

其次是预编程条件，ECU 应该确保编程的执行是处于安全状态。如果预编程编程条件不满足（如车辆或发动机正在运行等），那么编程请求将被拒绝。

第三则是完整性验证，ECU 应该检查已下载到存储器中的数据的完整性。当一个逻辑块下载后，将使用CRC32 算法验证当前逻辑块的所有数据字节是否被正确传输和写入。通过一个“检查编程完整性” 例程诊断服务请求激活此验证例程。

第四则是依赖性检查，不兼容的软件不能配合使用，可能会使功能异常或产生致命性错误。因此， ECU 应该通过验证其软件兼容性来检查编程依赖性，包括应用软件与 bootloader 软件、应用数据与应用软件等。依赖性检查机制由 ECU 供应商制定，并经得主机厂诊断工程师批准。

第三部分则是源文件格式要求，只要指定软件的格式，比如为Intel格式，软件版本号.HEX。

第四部分为通信需求，包括网络层参数，如定时参数（如 N_As、 N_Bs 等）、 BS 和 STmin 将按照诊断企标中给定的值来设置；以及诊断层参数，包括定时参数（如 P2server、 S3server 等），这些也是在诊断企标，或者是诊断调查表里。

第五部分则是ECU 启动时序，在上电/复位后， ECU 首先执行 Boot代码。Boot执行一些基本的初始化，然后检查外部重编程请求标志位是否置为 TURE。如果有重编程请求（标志被置为TURE），即使应用程序是有效的， Boot也会继续运行。如果当前没有重编程请求，则检查应用程序的状态：如果应用程序是有效的，则应用程序代码将被执行；如果应用程序是无效的，则继续执行 Boot代码。

03.编程过程

这一部分是整个规范的篇幅最长的部分，详细定义了将应用软件或应用数据模块下载到 ECU 内存中的编程过程。

首先是Boot的启动时序，也就是在Boot和应用软件不同会话之间的跳转逻辑，如下图所示。

上电/复位后， ECU 首先执行 Bootloader 引导代码，然后检查外部重编程请求标志位：

1. 如果标志已被设置，那么即使应用程序是有效的， Bootloader 也会继续进一步执行，

在此情况下， ECU 直接进入编程会话模式。

2. 如果当前没有重编程请求，则检验应用程序的状态：

如果应用程序是有效的，则启动应用程序。

如果应用程序无效， ECU 停留在 Bootloader 模式下的默认会话模式。

在 Bootloader 模式下，诊断会话转换规则与应用模式下相同。

在 Bootloader 模式下，有以下几种方式，能导致 ECU 重启：

无论当前处于何种会话模式， “$11 $01”能引导 ECU 重启。

在扩展会话模式或编程会话模式下， S3 定时器超时能引导 ECU 重启。

在编程会话模式下， “$10 $01”能引导 ECU 重启。

第二部分则是刷写流程，跟14229一样，分为三部分预，编程步骤：做编程前的 CAN 网络准备；ECU 编程步骤：下载软件或数据；后编程步骤：重同步 CAN 网络。

预编程步骤用来为要下载的 ECU 做编程前的 CAN 网络准备。此步骤也包含了提高下载能力的准备。此步骤的请求报文采用是物理寻址，或功能寻址。

a）诊断会话控制$10 $03：为了禁止 ECU 间的正常通信和 DTC 设置，预编程需要启动非默认会话模式。通过使用会话类型为扩展会话模式的诊断会话控制($10)服务来完成。此请求使用一个单帧请求报文，通过功能寻址发送给所有的 ECU。完成扩展会话模式切换后，诊断仪应持续周期性（4 秒）发送诊断仪在线服务请求（3Eh 80h），以维持所有 ECU 的非默认会话模式。诊断仪在线服务请求使用一个单帧请求报文，通过功能寻址发送给所有 ECU。

（b）控制 DTC 设置$85 $02：诊断仪通过 DTC 设置类型设为“关闭”的控制 DTC 设置服务请求。此请求使用一个单帧请求报文，通过功能寻址发送给所有的 ECU。

（c）通信控制 0x28 $03 $03：诊断仪通过通信控制($28)服务请求，禁止非诊断报文的发送和接收。请求中的控制类型参数置为“disable the transmission and the reception ”，通信类型置为“application and network management messages”。此请求使用一个单帧请求报文，通过功能寻址发送给所有的ECU。

（d）读取数据 0x22 $xx $yy：在禁止正常通信后，读取被编程的 ECU 的状态（如：编程的应用软件和数据）。从被编程的 ECU 读取服务器标识数据，标识如应用软件标识、应用数据标识、 Boot 软件标识。读取数据服务为可选服务，读取的内容由 ECU 供应商定义。

第二部分则是主编程在预编程步骤之后，即为 ECU 主编程步骤。主编程时序是单个 ECU 编程事件的应用，因此所有服务的请求使用物理寻址。

（a） 诊断会话控制$10 $02：在收到一个会话类型为物理寻址的编程会话的诊断会话控制($10)服务后， ECU 开始编程条件检查。编程条件满足后， ECU 将分配编程需有的所有必须的资源， ECU 先发送肯定响应再执行跳转到编程模式动作；软件版本读取$22 $xx yy：读取 ECU 当前软件版本号，核对软件版本号和待刷写版本是否一致；

（b） Level 2 安全访问$27 09/0A：编程事件必须通过安全访问。安全访问($27)服务在排放相关和安全系统中是强制的。其它系统不要求使用该服务。下载前，通过安全访问过程是强制的，确保只有合法的诊断仪能对 ECU 进行下载操作。

（c）驱动下载$34， $36， $37， $31：当 ECU 的非易失性存储单元中没有存储内存擦除例程时，将执行内存擦除例程的下载。下载应该按照如下时序来进行：请求下载、传输数据、请求传输退出。下载完所有字节后，用“检查编程完整性”例程($31 $01 $02 $02)来检查所有的字节都正确传输。ECU 数据包必须包含驱动软件，如果没有驱动，必须包含虚拟无效驱动的下载。

（d）写入数据$2E xx yy：在擦除内存例程之前，将“指纹”写到 ECU 内存中是强制的。“指纹”标识了是哪个诊断仪对 ECU 内存做了修改。我们使用xx yy 数据标识符而不是引导软件指纹、应用软件指纹、应用数据指纹这些数据标识符。每个逻辑块（除了驱动）下载前，诊断仪将首先写“指纹”，在下载完逻辑块后， ECU 将之前下载的程序是哪个逻辑块（即逻辑块序号），并根据逻辑块的序号将它存储。在追踪指纹信息时，诊断仪将发报文“$22 xx yy”，ECU 将通过 “$62 xx yy…”， 返回每一个逻辑块指纹信息的序号。

（e）例程控制——“擦除内存”$31 $01 $FF $00：为了允许应用软件和数据下载， ECU的内存将被擦除。此步骤通过例程来完成，使用例程控制($31)服务，来执行擦除内存。如果擦除内存例程被调用，那么应用程序有效标志位将被置为无效。

（f）下载过程$34， $36， $37：应用软件或者数据的每一个连续的数据块（可能是一个完整的应用软件或者数据，也可能是应用软件或者数据的一部分） 下载到 ECU 非易失性内存中， 都是遵循下面的服务顺序完成数传输。

（g）例程控制——“检查编程完整性”$31 $01 $02 $02：此例程用来检查逻辑块的下载是否成功，例程的功能是检查下载的完整性。

（h）例程控制——“检查编程依赖性”$31 $01 $FF $01：一旦完成所有的应用软件或数据块/模块的下载，诊断仪将开始一个例程来验证执行成功的下载。此例程触发 ECU 检查重编程的依赖性。ECU 供应商来定义检查内容，但必须确保所有逻辑块的兼容性和一致性。

（i）电控单元复位$11 $01：诊断仪使用物理寻址，发送一个复位类型为硬复位的 ECU复位($11)服务请求报文到 CAN 网络上。

通过 ECU 复位服务请求将使 ECU 结束编程过程，返回到正常的操作模式。内存驱动代码必须从 RAM 缓存中完全清除，避免意外激活这些可能会进行非预期的内存擦除或程序操作的代码。

主编程完成后，就是后编程流程。

（a）诊断会话控制 10h 03h：诊断仪发送一个会话类型为扩展会话的诊断会话控制服务请求报文到 CAN 网络上，使所有 ECU（包括刷写执行完毕已复位的 ECU）切换至扩展会话模式。此请求使用一个单帧请求报文，通过功能寻址发送给所有的 ECU。

（b）通信控制 28h 00h 03h：诊断仪通过通信控制（28h）服务请求， 开启非诊断报文的发送和接收。请求中的控制类型参数置为“enable the transmission and the reception”，通信类型置为“application and network management messages”。此请求使用一个单帧请求报文，通过功能寻址发送给所有的 ECU。。

（c） 控制 DTC 设置 85h 01h：诊断仪发送 DTC 设置类型设为“开启” 的控制 DTC 设置服务请求。此请求使用一个单帧请求报文，通过功能寻址发送给所有的 ECU。

（d） 诊断会话控制 10h 01h：诊断仪发送一个会话类型为默认会话的诊断会话控制（10h）服务请求报文到 CAN 网络上。所有的 ECU 接收到诊断会话控制（10h），而进入到默认会话模式。此请求通过功能寻址发送， 发送给所有 ECU。诊断仪应停止发送周期性的诊断仪在线请求（3Eh 80h）。

（e） 清除诊断信息 14h FFh FFh FFh：如果重编程 ECU 在编程步骤被重启，当编程 ECU运行在默认会话模式时，网络上其它的 ECU 仍然在不能正常通信状态，此时，一些可能被存储在编程 ECU 中的诊断信息就应该通过物理寻址的清除诊断信息（14h）服务来清除。

刷写流程陈述清楚后，则是对整个流程中用到的诊断服务、DID、RID的数据流进行详细的定义。

首先是服务的示例，标明各个服务在哪些会话、哪些模式、哪些寻址下支持，如下图所示。

对于DID和RID也会有详细的定义，包含各个数据位的含义。例如上面提到的读到的完整性检查的RID定义如下。

最后一部分则是附录了，通常附录会列举整个刷写的正向流程，为了供应商能够正确的理解各个步骤。

以上就是一份Bootloader规范的全部内容。