ECU 安全启动和安全刷写的技术实现演示案例

场景: 诊断仪将新的应用程序软件下载到ECU中。

假设条件:

ECU硬件支持CAN通信。
ECU已安装Bootloader软件。
诊断仪支持UDS协议和所需的诊断服务。
应用程序软件已打包成HEX格式文件。

流程步骤:

预编程步骤:

STP1_a: 切换扩展会话

- 诊断仪发送: $10 03 (功能寻址)
- ECU响应: $50 03 00 32 (功能寻址)
- 目的: 进入扩展会话模式，禁止ECU间正常通信和DTC设置。

STP1_b: 扩展会话保持

- 诊断仪发送: $3E 80 (功能寻址)
- ECU响应: 无 (持续发送，周期4秒)
- 目的: 维持ECU在非默认会话模式。

STP1_c: DTC设置 Off

- 诊断仪发送: $85 02 (功能寻址)
- ECU响应: $C5 02 (功能寻址)
- 目的: 关闭DTC设置，避免升级过程中产生错误代码。

STP1_d: 禁止通信

- 诊断仪发送: $28 03 03 (功能寻址)
- ECU响应: $68 03 (功能寻址)
- 目的: 禁止非诊断报文的发送和接收，降低总线负载。
主编程步骤:

STP2_a: 软件版本核对

- 诊断仪发送: $22 F1 88 (物理寻址)
- ECU响应: $62 F1 88 XX (物理寻址)
- 目的: 读取ECU当前软件版本号，并与待刷写版本进行核对。

STP2_b: 切换编程会话

- 诊断仪发送: $10 02 (物理寻址)
- ECU响应: $50 02 00 32 (物理寻址)
- 目的: 进入编程会话模式，准备进行软件下载。

STP2_c: 安全访问

- 诊断仪发送: $27 09 (物理寻址)
- ECU响应: $67 09 aa aa (物理寻址)
- 诊断仪发送: $27 0A bb bb (物理寻址)
- ECU响应: $67 0A (物理寻址)
- 目的: 通过安全访问服务验证诊断仪的合法性。

STP2_d: 下载FlashDriver

- 诊断仪发送: $34 aa bb cc dd (物理寻址)
- ECU响应: $74 ee ff (物理寻址)
- 诊断仪发送: $36 gg hh (物理寻址)
- ECU响应: $76 gg (物理寻址)
- …
- 诊断仪发送: $37 (物理寻址)
- ECU响应: $77 (物理寻址)
- 目的: 下载内存擦除例程到ECU的RAM中。

STP2_e: 写入指纹

- 诊断仪发送: $2E F1 5A XX (物理寻址)
- ECU响应: $6E F1 5A XX (物理寻址)
- 目的: 将“指纹”信息写入ECU内存，记录诊断仪信息和下载时间。

STP2_f: 擦除内存

- 诊断仪发送: $31 01 FF 00 aa bb cc (物理寻址)
- ECU响应: $71 01 FF 00 00 (物理寻址)
- 目的: 使用内存擦除例程擦除ECU内存中的旧软件。

STP2_g: 下载主程序

- 诊断仪发送: $34 aa bb cc dd (物理寻址)
- ECU响应: $74 ee ff (物理寻址)
- 诊断仪发送: $36 gg hh (物理寻址)
- ECU响应: $76 gg (物理寻址)
- …
- 诊断仪发送: $37 (物理寻址)
- ECU响应: $77 (物理寻址)
- 目的: 将新的应用程序软件下载到ECU的Flash存储器中。

STP2_h: 检查数据完整性

- 诊断仪发送: $31 01 02 02 aa (物理寻址)
- ECU响应: $71 01 02 02 00 (物理寻址)
- 目的: 使用CRC32算法验证下载的数据完整性。

STP2_i: 检查编程依赖性

- 诊断仪发送: $31 01 FF 01 (物理寻址)
- ECU响应: $71 01 FF 01 00 (物理寻址)
- 目的: 检查应用程序软件与Bootloader软件、应用数据之间的兼容性。

1. 应用程序软件与Bootloader软件的兼容性:

软件版本匹配: 验证应用程序软件版本号是否与Bootloader软件支持的版本范围匹配。
硬件平台兼容: 验证应用程序软件是否针对ECU的硬件平台进行了适配，例如CPU架构、内存大小等。
功能接口兼容: 验证应用程序软件是否使用了Bootloader软件提供的接口函数，以及接口函数的参数和返回值是否正确。

2. 应用程序软件与应用数据的兼容性:

数据格式匹配: 验证应用程序软件使用的应用数据格式是否与应用数据文件格式匹配。
数据版本匹配: 验证应用程序软件版本号是否与应用数据版本号匹配。
数据内容兼容: 验证应用数据内容是否与应用程序软件的需求相符，例如参数范围、数值类型等。

3. 其他可能的验证内容:

固件依赖性: 验证应用程序软件是否依赖于其他ECU的固件版本，例如网关ECU或CAN总线驱动程序。
配置依赖性: 验证应用程序软件是否依赖于ECU的配置信息，例如CAN总线ID、波特率等。
安全策略依赖性: 验证应用程序软件是否满足ECU的安全策略要求，例如安全访问级别、密钥管理等。

验证步骤的实现方式:

静态检查: 在软件下载之前，检查应用程序软件的版本号、数据文件格式等信息是否符合预期。
动态检查: 在软件下载过程中或下载完成后，执行代码来检查应用程序软件与其他软件的兼容性。
接口调用: 通过调用Bootloader软件提供的接口函数，获取相关信息并进行验证。

验证结果的处理:

如果依赖性检查通过: 设置例程状态为正确，允许继续进行软件下载。
如果依赖性检查失败: 设置例程状态为错误，终止软件下载流程，并通知用户依赖性检查失败，无法进行软件升级。

总结:

“检查编程依赖性”例程的目的是确保应用程序软件与其他软件能够正常配合使用，避免出现功能异常或致命性错误。具体的验证内容和方法需要根据ECU的实际情况进行定义和实现。

STP2_j: ECU复位

- 诊断仪发送: $11 01 (物理寻址)
- ECU响应: $51 01 (物理寻址)
- 目的: 重启ECU，结束编程过程，并清除RAM中的内存擦除例程。
后编程步骤:

STP3_a: 切换扩展会话

- 诊断仪发送: $10 03 (功能寻址)
- ECU响应: $50 03 00 32 (功能寻址)
- 目的: 重新进入扩展会话模式。

STP3_b: 开启通信

- 诊断仪发送: $28 00 03 (功能寻址)
- ECU响应: $68 00 (功能寻址)
- 目的: 允许非诊断报文的发送和接收。

STP3_c: 开启DTC设置

- 诊断仪发送: $85 01 (功能寻址)
- ECU响应: $C5 01 (功能寻址)
- 目的: 重新开启DTC设置。

STP3_d: 切换默认会话

- 诊断仪发送: $10 01 (功能寻址)
- ECU响应: $10 01 00 32 (功能寻址)
- 目的: 重新进入默认会话模式。

STP3_e: 清除诊断信息

- 诊断仪发送: $14 FF FF FF (物理寻址)
- ECU响应: $54 (物理寻址)
- 目的: 清除ECU中可能存储的诊断信息。
总结:

以上流程展示了使用UDS协议和诊断服务进行软件刷写的完整过程。每个步骤都包含了UDS发送和响应的命令，以及实现的步骤。需要注意的是，实际操作中可能需要根据具体情况调整参数和步骤。

ECU安全启动流程步骤

场景：一款智能网联汽车，其 ECU 需要满足安全启动标准，防止未授权代码执行和固件篡改

1. ECU 启动前准备

BootRom：存储在 CPU 芯片内部，负责引导启动流程，并验证 Bootloader 的完整性。
Bootloader：负责加载并验证 Application，并提供安全启动接口。
Application： ECU 的主要功能程序，需要经过验证才能启动。
HSM：安全模块，提供安全存储和密钥管理功能。

2. 启动流程

阶段一：BootRom 验证 Bootloader

BootRom 上电： BootRom 代码开始执行。
BootRom 加载 Bootloader： BootRom 从 EMMC 或 Flash 中加载 Bootloader 到 RAM。
BootRom 验证 Bootloader： BootRom 使用存储在 OTP 中的根公钥 Hash 验证 Bootloader 的完整性。
Bootloader 验证通过：验证通过后，Bootloader 被加载到 RAM 并开始执行。
Bootloader 验证失败：验证失败后，启动流程终止，ECU 进入安全模式。

阶段二：Bootloader 验证 Application

Bootloader 加载 Application： Bootloader 从 EMMC 或 Flash 中加载 Application 到 RAM。
Bootloader 验证 Application： Bootloader 使用存储在 Bootloader 中的 Application 公钥 Hash 验证 Application 的完整性。
Application 验证通过：验证通过后，Application 被加载到 RAM 并开始执行。
Application 验证失败：验证失败后，启动流程终止，ECU 进入安全模式。

3. UDS 命令交互

3.1 Bootloader 阶段

UDS 请求：假设诊断工具发送 Request Download 命令 (0x34)，请求下载 Bootloader 固件。
- 参数：数据传输类型、内存地址、数据长度等。
UDS 响应： ECU 返回 Transfer Data 命令 (0x36)，传输 Bootloader 固件数据。
- 参数：数据块。
UDS 请求：诊断工具发送 Request Transfer Exit 命令 (0x37)，完成下载。
UDS 响应： ECU 返回 Transfer Exit 命令 (0x38)，确认下载完成。

3.2 Application 阶段

UDS 请求：假设诊断工具发送 Request Download 命令 (0x34)，请求下载 Application 固件。
- 参数：数据传输类型、内存地址、数据长度等。
UDS 响应： ECU 返回 Transfer Data 命令 (0x36)，传输 Application 固件数据。
- 参数：数据块。
UDS 请求：诊断工具发送 Request Transfer Exit 命令 (0x37)，完成下载。
UDS 响应： ECU 返回 Transfer Exit 命令 (0x38)，确认下载完成。

4. 安全启动失效策略

A/B 系统：如果 Bootloader 或 Application 验证失败，ECU 会尝试切换到备份系统启动。
故障上报：启动失败信息会以故障码方式上报，并记录在诊断故障码中。
制裁措施：根据配置，ECU 可能会重置或锁定 HSM 内部的密钥和校验码。

5. 启动入口安全

唯一启动入口： BootRom 只能从 Flash 启动，并启用 RDP 功能防止篡改启动位置。
恢复系统：恢复系统存储在 NOR Flash 或 EEPROM 中，并设置为只读，只有在 EMMC 完全失效时才能作为启动入口。

总结

通过以上流程，该智能网联汽车 ECU 实现了安全启动，确保了代码的完整性和合法性，有效防止了未授权代码执行和固件篡改，提高了车辆的安全性。

案例演示

OEM Boot应验证App在UDS RSASSA-PSS-ZF1-2048-$31$01$FF$01 的定义

场景: 诊断仪请求OEM Boot验证App软件的依赖性。

假设条件:

ECU硬件支持CAN通信。
ECU已安装Bootloader软件。
诊断仪支持UDS协议和所需的诊断服务。
应用程序软件已打包成HEX格式文件。

步骤:

发送“检查编程依赖性”例程控制请求:
- 诊断仪发送: $31 01 FF 01 (物理寻址)
- 目的: 请求ECU执行“检查编程依赖性”例程，验证应用程序软件与其他软件的兼容性。
ECU处理请求:
- ECU执行: 检查应用程序软件与Bootloader软件、应用数据之间的依赖关系。
- ECU判断:
  - 如果依赖关系满足，则设置例程状态为正确。
  - 如果依赖关系不满足，则设置例程状态为错误。
ECU发送响应:
- ECU发送: $71 01 FF 01 XX (物理寻址)
- XX: 例程状态 (00: 正确, 01: 错误)
- 目的: 响应诊断仪的请求，告知依赖性检查的结果。

4. 诊断仪处理响应: * 诊断仪判断: 根据响应的例程状态，决定是否继续进行软件下载。 * 如果例程状态为正确: * 继续执行软件下载流程。 * 如果例程状态为错误: * 终止软件下载流程，并通知用户依赖性检查失败，无法进行软件升级。

实现步骤:

诊断仪端:
- 使用UDS协议栈发送“检查编程依赖性”例程控制请求。
- 接收ECU的响应，并根据响应结果进行判断。
OEM Boot端:
- 接收诊断仪的请求，解析请求内容。
- 执行依赖性检查，并设置例程状态。
- 发送响应，告知诊断仪依赖性检查结果。

注意:

以上流程仅展示了“检查编程依赖性”例程控制请求的发送和响应，实际操作中可能需要根据具体情况调整参数和步骤。
“检查编程依赖性”例程的具体实现由ECU供应商定义，并需要得到江铃汽车诊断工程师的批准。

如何详细解释诊断会话控制？

ChatGLM

诊断会话控制服务是用于切换ECU的诊断会话模式的，每个诊断会话模式都使能一组特定的诊断服务。以下是诊断会话控制的详细解释：

1. 会话模式类型:

默认会话 (Default Session, 0x01): 这是ECU的默认会话模式，不需要任何诊断应用程序的超时处理，例如无需诊断工具在线服务保持此会话模式激活。如果默认会话被激活，则ECU会自动进入此模式。
编程会话 (Programming Session, 0x02): 此会话模式使能所有支持ECU内存编程的必要诊断服务。在引导程序中运行编程会话时，ECU只能通过诊断工具发起的“ECU复位”服务、诊断会话控制服务或ECU会话层超时退出此会话。
扩展诊断会话 (Extended Diagnostic Session, 0x03): 此会话模式可用来支持对ECU控制变量进行调整（如怠速、CO值等）所需的所有诊断服务，也可以用来使能一些不特定于功能调整的诊断服务。

2. 会话模式切换规则:

默认会话到扩展会话: 默认会话可以直接切换到扩展会话。
默认会话到编程会话: 默认会话不能直接切换到编程会话，必须先进入扩展会话。
编程会话到默认会话: 编程会话可以直接切换到默认会话。
扩展会话到编程会话: 扩展会话不能直接切换到编程会话，必须先进入默认会话。
ECU复位: ECU复位会导致ECU进入默认会话模式。
会话层超时: 如果ECU会话层超时，ECU会进入默认会话模式。

3. 会话模式控制服务请求格式:

plaintext

复制

DiagnosticSessionControl(10h): 50 01 [SessionType] 00 00 00 00 00 00 00 00

SessionType: 诊断会话模式类型，取值为0x01 (默认会话)、0x02 (编程会话) 或 0x03 (扩展诊断会话)。

4. 会话模式控制服务响应格式:

肯定响应:

plaintext

复制

Positive Response: 50 01 [SessionType] 00 00 00 00 00 00 00 00

否定响应:

plaintext

复制

Negative Response: 7F 10 10 12

否定响应码: 12 (子功能不支持)

5. 示例:

请求进入默认会话模式:

plaintext

复制

DiagnosticSessionControl(10h): 50 01 01 00 00 00 00 00

请求进入扩展诊断会话模式:

plaintext

复制

DiagnosticSessionControl(10h): 50 01 03 00 00 00 00 00

注意事项:

切换会话模式前，请确保当前会话模式下的诊断服务已经完成，避免出现冲突。
不同ECU可能支持不同的会话模式，请参考相应的ECU诊断设计规范。

希望以上解释能够帮助您理解诊断会话控制服务的使用方法。

要进入扩展会话（Extended Diagnostic Session）在使用统一诊断服务（Unified Diagnostic Services, UDS）的ECU中，通常需要遵循以下步骤：

建立通信连接：
- 确保物理层（如CAN总线、LIN总线、FlexRay等）已经建立通信连接。
发送诊断会话控制请求：
- 发送一个UDS诊断会话控制服务请求（Service $10）来请求切换到扩展会话。
- 请求报文格式通常如下：

复制

[服务ID] [子功能]

- 对于扩展会话，服务ID是$10（十六进制），子功能是$03（十六进制）。
示例请求报文：

复制

10 03

- 这里，10 是诊断会话控制服务ID，03 是请求进入扩展会话的子功能码。
接收响应：
- ECU应该回复一个肯定响应（Positive Response），表明已经成功切换到扩展会话。
- 肯定响应报文格式通常如下：

复制

[肯定响应服务ID] [子功能]

- 肯定响应服务ID是$50（十六进制），子功能与请求相同，即$03。
示例肯定响应报文：

复制

50 03

- 这里，50 是肯定响应的服务ID，03 表示ECU已经进入扩展会话。

以下是详细的步骤：

启动通信：
- 使用适当的通信协议和波特率启动与ECU的通信。
发送诊断会话控制请求：
- 通过发送以下UDS报文请求进入扩展会话：

复制

10 03

- 10 表示诊断会话控制服务。
- 03 表示请求进入扩展会话。
等待并检查响应：
- 等待ECU的响应。
- 检查响应是否为肯定响应：

复制

50 03

- 如果收到肯定响应，则表示ECU已经成功进入扩展会话。
- 如果收到否定响应（NRC），则需要根据否定响应代码（NRC）采取相应的措施。
执行所需诊断操作：
- 在扩展会话中，可以执行更多高级的诊断操作，如读取ECU内存、写入数据、控制DTC设置等。

请注意，上述步骤是基于ISO 14229-1（UDS）标准，实际操作可能因车辆制造商和ECU的具体实现而有所不同。