车载ECU是汽车中负责控制的核心组件，随着汽车行业向智能化和网络化的快速发展，智能部件在现代汽车中的作用越来越重要,它们不仅提供了更高级的车辆控制能力，还为车辆带来了更好的互联性和用户交互体验。本篇文章将详细介绍智能部件和传统部件的区别和优点，以及如何在CANoe软件中实现智能部件仿真测试。
什么是智能部件
智能部件是指在车辆中具有独立操作系统和文件系统的电子控制单元（ECU），这类部件通常包括微处理器单元（MPU）和微控制器单元（MCU）。它们具备处理和存储能力，能够执行复杂的软件任务，例如车身域控制器负责整车控制，实时性安全性要求高；智能驾驶域控制器负责自动驾驶相关感知、规划、决策相关功能；智能座舱域控制器负责HMI交互和智能座舱相关功能。这类控制器通常需要较高的计算能力和实时处理能力，所以必须要有微处理器单元（MPU）。微处理器（MPU）是构成微型计算机机的核心部件，也可以说是微型计算机的心脏，它起到控制整个微型计算机工作的作用，产生控制信号对相应的部件进行控制，并执行相应的操作。目前MPU主流的芯片有NXP S32G、高通8155、高通8255、英伟达 ORIN等。而传统部件不需要很高的计算能力，所以不需要微处理器单元（MPU），只用微控制器单元（MCU）就能满足需求，成本会比智能部件更低。汽车制造商在设计车辆系统时，要根据需求选择合适的部件和技术。基于上述智能部件的特点，在OBD和OTA升级中必须引入新的刷写方式，采用基于ISO 14229-1中规定的0x38服务完成刷写，传统部件使用的0x34服务不能满足需求。
如何实现智能部件的刷写
智能部件刷写和传统部件刷写流程
上图表明了智能部件和传统部件的刷写过程和差异点，在主编程中使用ISO 14229-1协议中的0x34、0x38、0x36、0x37、0x31、0x22等服务。智能部件使用0x38服务（请求文件传输）进行文件下载，并且智能部件必须支持安装版本和获取安装进度和结果两个步骤，下面进行详细的介绍。
文件的下载
0x38服务请求和响应格式见表1，0x34服务请求和响应格式见表2：
表1 0x38服务请求和响应消息格式
|-----------|--------|-----|-------------------------------------|
| 方向 | Tester->ECU ，Request |||
| 服务 | RequestFileTransfer |||
| 序号 | 值 | Cvt | 说明 |
| #1 | 38h | M | 服务ID |
| #2 | 03h | M | 工作模式：取代文件 |
| #3 | 00-FFh | M | 文件路径和名称长度Byte#1(MSB) |
| #4 | 00-FFh | M | 文件路径和名称长度Byte#2 |
| #5 | 00-FFh | M | 文件路径和名称Byte#1(MSB) |
| ... | 00-FFh | C | |
| #5+n-1 | 00-FFh | C | 文件路径和名称Byte#n |
| #5+n | 00h | M | 数据格式： 00h=未压缩，未加密 |
| #5+n+1 | 00-FFh | M | 文件大小参数长度 |
| #5+n+2 | 00-FFh | M | 文件未压缩大小Byte#1 （MSB） |
| ... | 00-FFh | C | |
| #5+n+1+k | 00-FFh | C | 文件未压缩大小Byte#k |
| #5+n+2+k | 00-FFh | M | 文件压缩大小Byte#1 （MSB） |
| ... | 00-FFh | C | |
| #5+n+1+2k | 00-FFh | C | 文件压缩大小Byte#k |
| ||||
| 方向 | ECU->Tester，Response |||
| 服务 | RequestFileTransfer |||
| 序号 | 值 | Cvt | 说明 |
| #1 | 78h | M | 服务ID |
| #2 | 03h | M | 工作模式：取代文件 |
| #3 | 00-FFh | M | 长度格式标识符 |
| #4 | 00-FFh | M | maxNumberOfBlockLength Byte#1 （MSB） |
| ... | 00-FFh | C | |
| #4+m-1 | 00-FFh | C | maxNumberOfBlockLength Byte#m |
| #4+m | 00h | M | 数据格式： 00h=未压缩，未加密 |
表2 0x34服务请求消息和响应消息格式
|-----|---------|-----|------------------------------------------------------------------|
| 方向 | Tester->ECU ，Request |||
| 服务 | RequestFileTransfer |||
| 序号 | 值 | Cvt | 说明 |
| #1 | 34h | M | 服务ID |
| #2 | 00h/10h | M | 00h=不压缩不加密 10h=压缩不加密 |
| #3 | 44h | M | addressAndLengthFormatIdentifier bit7-bit4 数据长度 bit3-bit0 数据起始地址 |
| #4 | 00-FFh | M | memoryAddress Byte#1 （MSB） |
| #5 | 00-FFh | M | memoryAddress Byte#2 |
| #6 | 00-FFh | M | memoryAddress Byte#3 |
| #7 | 00-FFh | M | memoryAddress Byte#4 |
| #8 | 00-FFh | M | memorySize Byte#1 （MSB） |
| #9 | 00-FFh | M | memorySize Byte#2 |
| #10 | 00-FFh | M | memorySize Byte#3 |
| #11 | 00-FFh | M | memorySize Byte#4 |
| ||||
| 方向 | ECU->Tester，Response |||
| 服务 | RequestFileTransfer |||
| 序号 | 值 | Cvt | 说明 |
| #1 | 74h | M | 服务ID |
| #2 | 40h | M | 长度格式标识符 |
| #3 | 00-FFh | M | maxNumberOfBlockLength Byte#1 （MSB） |
| #4 | 00-FFh | M | maxNumberOfBlockLength Byte#2 |
| #5 | 00-FFh | M | maxNumberOfBlockLength Byte#3 |
| #6 | 00-FFh | M | maxNumberOfBlockLength Byte#4 |
在0x38服务中需要注意的是，文件路径和名称指的是ECU内部下载到文件系统的路径，并不是BIN或者ZIP刷写文件存放的位置。
开始安装版本 ( RoutineControl**)**
只有智能部件刷写需要执行开始安装版本步骤，传统部件刷写不需要执行。Tester通过发送RoutineControl服务的StartRoutine子功能请求，指示ECU开始执行版本安装例程。这个请求通常包含一个例程标识符（RoutineIdentifier），用于指定要执行的具体例程。在安装版本过程中，需要注意以下几点：
1.在启动版本安装之前，ECU必须先将需要更新的程序区域设置为无效。这是为了防止在更新过程中发生中断或错误，导致部分更新的程序被执行，可能会引起系统不稳定或安全问题。
2.一旦版本安装流程开始，UDS协议不支持通过诊断命令来停止安装过程。Tester必须等待ECU完成安装，无论结果是成功、失败还是超时。
3.在执行版本安装流程之前，ECU必须先对StartRoutine请求给出响应。这个响应可以是肯定响应，表明ECU已经准备好执行例程；也可以是否定响应，表明由于某些原因（如安全检查未通过、资源不可用等），ECU无法执行请求的例程。
4.等待结果：Tester在发送StartRoutine请求并收到ECU的响应后，需要等待ECU完成版本安装流程。如果安装成功，ECU可能会发送一个完成通知。如果安装失败或超时，Tester需要根据ECU的指示或预设的超时逻辑来处理这些情况。
5.安装完成后，Tester可能需要发送其他诊断命令来验证新版本的程序是否正确安装，或者执行其他后续步骤，如重启ECU。
在整个过程中，Tester需要根据车辆制造商提供的诊断工具和指导手册来操作，以确保更新过程的正确性和车辆的安全。
获取安装进度和结果 (ReadDataByIdentifier $22 xxxx)
智能部件必须支持获取安装进度和结果步骤，传统部件则不具备这种查询能力。Tester通过调用$22(ReadDataByIdentifier)服务查询安装进度和结果。在查询过程中需要注意以下几点：
1.Tester调用$22服务查询进度和结果需按照指定的周期，一般每隔1秒(或是其它周期)查询一次安装进度和结果。
2.如果ECU在查询时超时未响应，Tester不应将此视为错误。Tester应继续定期查询，直到收到安装成功且进度达到100%或者ECU明确响应安装或校验失败。
3.如果ECU在30分钟内（超时时间）未能完成安装或给出结束响应，Tester应终止本次重编程流程。
4.如果ECU由于故障原因一直无法完成安装，Tester需要根据车辆制造商的指导手册来处理这种情况，可能包括记录错误代码、尝试故障诊断或安排维修。
5.一旦收到ECU的响应，Tester需要验证响应中的数据，确保安装进度和结果符合预期。
在整个过程中，Tester需要确保使用正确的诊断工具和遵循制造商的指导手册来操作，以确保软件安装过程的正确性和车辆的安全。如果安装失败，可能需要进一步的诊断来确定失败的原因，并采取相应的措施来解决问题。
仿真测试
环境搭建
我们采用Vector的CANoe软件作为搭建测试环境的工具，实现CAN网络的仿真与测试，基于CAPL编程语言模拟实现诊断仪的诊断功能。硬件选用Vector的VN1640，通过Channel2连接控制器，如图所示：
连接示意图
软件仿真
使用CANoe创建CAN工程BT Test，配置软硬件通道、波特率等相关参数后，使用panel面板制作可视化勾选及参数配置界面。
测试环境示意图
刷写时需要获取刷写文件内容，根据不同文件格式使用不同的封装函数，目前东信创智支持Hex、S19、Bin、Zip等格式的刷写文件的测试，其中Hex、S19使用fileGetString函数，Bin、Zip等使用fileGetBinaryBlock函数。在使用0x38服务时需要将字符串转换为十六进制，使用EncodeString函数。
获取文件函数
字符串转换函数
除上文提到的函数，脚本中还大量使用CAPL提供的封装函数，有兴趣的可以查看CANoe的帮助文件。
案例分析
下图为实现智能部件刷写的数据，以刷写过程中的0x38服务文件下载、开始安装版本和获取安装进度和结果为例。
0x38服务请求下载测试数据
开始安装和获取安装进度测试数据
以上就是有关基于CANoe的智能部件刷写的所有内容，希望能对大家使用CANoe进行测试仿真有所帮助。
如果在后续使用过程中出现其他问题，欢迎随时联系我们的支持邮箱support@dotrustech.com，我们会尽快帮您解决~