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的具体实现而有所不同。

 

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。