基于UDS的BootLoader设计——架构设计及规范
01
BootLoader概述
1.1 Boot Loader设计目的
车载控制器软件需要满足两方面的要求：
1）、功能方面的需求：用户需要的基本功能实现；
2）、更新及升级需求：对于售后的要求，车辆上市后针对软件缺陷修复及后续功能扩展等要求。
刷写App程序存在两种方式：
1)、使用仿真器或烧录器直接烧录Application；
2)、将Application数据通过总线（CAN、LIN、CANFD或以太网）按照一定格式传输给ECU。
对于实车，直接连接烧录器或仿真器这种方式极不方便且花费较大，再者安全性不高。因此，产品很少存在烧录接口。从经济使用的角度来讲，普遍采用第二种方式。
1.2 Boot Loader基本功能
Boot Loader又称为引导加载程序，引导加载程序是系统上电后运行的第一段软件代码，常被用来加载系统或者更新系统等。因此，大部分的Boot Loader存在两种不同的操作模式：
1）启动模式
启动加载（BootLoading）模式也称为自主模（Autonmous）式，即BootLoader从目标机上某个固态存储设备上将操作系统加载至RAM中运行，整个过程中并没有用户的介入。
2）下载模式
在下载（DownLoading）模式下，目标机上的Boot Loader将通过串口连接或者网络连接等通信手段下载文件，如下载内核映像和根文件系统映像等。通常文件会保存在RAM中，然后将其写入目标地址完后系统的更新等。
02
BootLoader基本需求设计
2.1 Boot Loader功能概述
两个SWC：
1）、启动管理——控制器的启动管理等
2）、应用程序——ECU软件下载升级及标定数据再编程等
四个服务模块：
1）、内存管理——软件更新主要是将Flash中的Application及标定数据重编程，内存擦除与重写驱动必不可少的模块；
2）、CAN协议栈——软件更新媒介
3）、看门狗模块——软件运行保护
4）、安全模块——软件数据保护，下载数据校验等
2.2 ECU启动时序
Bootloader是所有支持重编程的ECU必须具备的软件功能，在ECU运行过程中，执行的是应用软件和应用数据，仅当应用软件或应用数据无效时，或者要求对其进行升级或特殊测试时，Bootloader软件才被激活。启动过程如下图所示：
2.3 软件执行安全机制设计
2.3.1 应用软件运行安全性
应用软件和应用数据可以同时编程或者相互独立编程，不允许Boot Loader在软件运行时被非法修改。因此，Bootloader软件存储于被保护的存储器区域，即使发生潜在错误时，控制器始终保证可重新编程。
基于软件运行安全性考虑，flash diver不会存在放在flash中，避免正常程序在发生错误时可能的非法修改。在需要执行应用程序或应用数据需要时，首先将flash diver下载至ram中，然后执行相应的更新。
基于以上考虑，将Boot Loader划分为：
PBL（Primary Boot Loader）：用于启动过程中的状态管理及下载软件等，下载 SBL、更新应用软件及应用数据
SBL（Secondary Boot Loader）：本质为Flash Diver（可被用来修改写在flash中生产信息校验信息等），下载完成后重新启动将会被清除
##SBL也可是运行在RAM中的另一个完整Boot Loader，以上将其认为flash driver
2.3.2 软件更新安全机制设计
为确保下载的安全，ECU需设计安全机制，避免以下几种情况：a. 来自非法源的下载动作；b. 当前编程条件不满足；c. 下载错误的应用软件或应用数据到ECU；d. 软件之间不兼容；
解决措施：
1）、安全访问——ECU通过SEED&KEY机制进行安全访问服务限制，保证ECU免遭未授权的编程动作影响。
2）、预编程条件——ECU确保编程时处于安全状态，条件不满足（如高压上电或车辆运行）时，编程服务请求将被拒绝。
3）、完整性校验——ECU对即将下载到存储器的程序或数据进行完整性检查，当一个逻辑模块下载后，使用CRC32算法验证当前逻辑块的所有数据字节是否被正确传输和写入。通过“检查编程完整性”例程控制激活ECU完整性校验。当ECU接收到此服务请求时，Bootloader将计算下载数据字节的CRC32值，并将计算结果与诊断仪请求报文中发送的校验值进行比较。
4）、一致性检查——不兼容的软件不能配合使用，如果配合使用可能会使功能异常或产生致命性错误。为此，ECU通过验证软件兼容性来检查编程程序的一致性，包括应用软件与Bootloader软件、应用数据与应用软件检验等。
5）、有效性检查——ECU内部有一个标志位，用于标识应用软件是否有效。如果编程完整性检查和一致性检查都正确时，ECU才会设置应用软件的标志位为有效。只有标志位为有效时，应用软件才可以运行。
03
BootLoader重编程流程设计
3.1 BootLoader重编程会话跳转设计
在应用模式下，使用了两种不同的诊断会话模式：默认会话模式和扩展会话模式。
在Bootloader模式下，使用了三种不同的诊断会话模式：默认会话模式，扩展会话模式和编程会话模式。
如果ECU在正确的条件下收到“$10 $02”指令，ECU将重编程请求标志状态位设为有效，并执行ECU重启。
上电/复位后，ECU首先执行Bootloader引导代码，然后检查外部编程请求标志位：
1）、如果外部编程请求标志位为有效，那么即使应用程序是有效的，Bootloader也会继续进一步执行，在此情况下，ECU直接进入编程会话模式。
2）、如果外部重编程请求标志位为无效，则继续检查应用软件的标志位状态：(a)、 如果应用软件是有效的，则启动应用模式；(b)、如果应用软件无效，ECU停留在Bootloader模式下的默认会话模式。
在Bootloader模式下，ECU重启方式：
1)、无论当前处于何种会话模式，“$11 $01”都会引导ECU重启；
2)、 在扩展会话模式或编程会话模式下，S3定时器超时会导致ECU重启；
3)、在编程会话模式下，“$10 $01”会导致ECU重启。
3.2 BootLoader重编程时序设计
编程时序分为三个编程步骤：
预编程步骤：编程前的CAN网络准备；
主编程步骤：下载应用软件或应用数据；
后编程步骤：重同步CAN网络。
如果在预编程、主编程和后编程步骤过程中，任何物理寻址的请求及响应不满足要求，则全部时序需再次执行。
3.2.1 预编程步骤
预编程步骤用来为要下载的ECU做重编程前的CAN网络准备。此步骤也包含了提高下载速度的准备。此步骤的请求报文能采用的是物理寻址，或功能寻址。如下图所示：
a)、诊断会话控制 $10 $03：为了禁止ECU间的正常通信和控制DTC设置，预编程需要启动非默认会话模式。通过使用会话类型为扩展会话模式的诊断会话控制（$10）服务来完成。此请求使用一个单帧请求报文，通过功能寻址发送给所有的ECU。
b)、例程控制“检查编程预条件” $31 $01 $XXXX：通过此例程来检查ECU编程条件，从而确保系统安全，如果有任何不安全的因素，ECU将拒绝编程。
注意：如果ECU在未收到“检查编程预条件”例程（$31 $01 $XXXX）的情况下，收到“$10 $02”请求，ECU将拒绝进入Bootloader模式，并且发送否定响应。
c)、控制DTC设置 $85 $02：诊断仪通过DTC设置类型设为“关闭”的控制DTC设置服务请求。此请求使用一个单帧请求报文，通过功能寻址发送给所有的ECU。
d)、通信控制 $28 $03 $03：诊断仪通过通信控制（$28）服务请求，禁止非诊断报文的发送和接收。请求中的控制类型参数置为“disable the transmission and the reception”，通信类型置为“application and network management messages”。此请求使用一个单帧请求报文，通过功能寻址发送给所有的ECU。
3.2.2 主编程步骤
在预编程步骤之后，是主编程步骤。主编程时序是单个ECU编程事件的应用，因此所有服务的请求都使用物理寻址。如下图所示：
a)、诊断会话控制 $10 $02：在收到一个寻址方式为物理寻址，子功能为编程会话的诊断会话控制（$10）服务后，ECU启动Bootloader，并分配编程所需的所有资源。ECU需先发送肯定响应，再执行跳转到编程模式动作。
b)、安全访问 $27 $XX/XX：编程事件必须通过安全访问。安全访问（$27）服务在排放相关和安全系统中是强制的。其它系统不要求使用该服务。下载前，通过安全访问过程是强制的，确保只有合法的诊断仪能对ECU进行下载操作。
c)、驱动下载 $34，$36，$37，$31：当ECU的非易失性存储单元中没有存储内存驱动时，将执行内存驱动的下载。下载应该按照如下时序来进行：请求下载、传输数据、请求传输退出。下载完所有字节后，用“检查编程完整性”例程（$31 $01 $XX $XX）来检查所有的字节都正确传输。
d)、写入数据 $2E $XXXX：在擦除内存例程之前，将“指纹”写到ECU内存中是强制的。“指纹”标识了是哪个诊断仪对ECU内存做了修改。使用XXXX数据标识符而不是引导软件指纹、应用软件指纹、应用数据指纹这些数据标识符。每个逻辑块（除了驱动）下载前，诊断仪将首先写“指纹”，在下载完逻辑块后，ECU将识别之前下载的程序是哪个逻辑块（即逻辑块序号），并根据逻辑块的序号将它存储。在追踪指纹信息时，诊断仪将发报文“$22 $XXXX”，ECU将通过“$62 $XXXX”，返回每一个逻辑块的指纹信息。
e)、例程控制——“擦除内存” $31 $01 $XXXX：为了允许应用软件和数据下载，ECU的内存将被擦除。此步骤通过例程控制服务（$31）来执行擦除内存。如果擦除内存例程被调用执行，那么应用软件的标志位将被置为无效。
f)、下载过程 $34 $36 $37：应用软件或者数据的每一个连续的数据块（也叫段，可能是一个完整的应用软件或者数据，也可能是应用软件或者数据的一部分）下载到ECU非易失性内存中，都是遵循下面的服务顺序完成数传输：请求下载（$34）、传输数据（$36）、请求退出传输（$37）。
注：单个应用软件或数据块可能需要多个数据传输（$36）请求报文来完成传输（当数据块长度超出网络层缓存大小时，就会出现这种情况）。
g)、例程控制——“检查编程完整性” $31 $01 $XXXX：此例程用来检查逻辑块的完整性。
h)、例程控制——“检查编程一致性” $31 $01 $XXXX：一旦完成所有的应用软件或数据块/模块的下载，诊断仪将开始一个例程来触发ECU检查重编程的一致性。
i) 、电控单元复位 $11 $01：诊断仪使用物理寻址，发送一个复位类型为硬复位的ECU复位（$11）服务请求报文到CAN网络上。
备注：通过ECU复位服务请求将使ECU结束重编程过程，返回到正常的操作模式。内存驱动代码必须从RAM缓存中完全清除，避免意外激活这些可能会进行非预期的内存擦除或程序操作的代码。
3.2.3 后编程步骤
a)、诊断会话控制 $10 $01：诊断仪发送一个会话类型为默认会话的诊断会话控制（$10）服务请求报文到CAN网络上。所有的ECU接收到诊断会话控制（$10），而进入到默认会话模式。此请求通过功能寻址发送，请求发送给所有包含在编程事件中或因此而进入非默认会话模式的ECU。跳转到默认会话模式，表示通信控制（$28）服务和控制DTC设置（$85）服务也将复位到默认状态。
b)、清除诊断信息 $14 FF FF FF：如果重编程ECU在编程步骤被重启，当编程ECU运行在默认会话模式时，网络上其它的ECU仍然在不能正常通信状态，此时，一些可能被存储在编程ECU中的诊断信息就应该通过物理寻址的清除诊断信息（$14）服务来清除。
版权声明：本文为CSDN博主「摸鱼的攻城狮」的原创文章,转载请附上原文出处链接及本声明。