怎么使用CANoe手动发送功能寻址诊断请求？

今天是2022年5月22日，难得的周末，天气晴朗，可以在小区内跑几圈，出出汗！
今天也是因疫情在家办公的第60天（两个月啦！）。抛开了通勤路上的三个小时，不单工作效率提高了，工作输出也在变多。疫情带来很多可以反思的地方，比如对风险的把控，让自己有了储蓄存钱的想法，无形中改变了消费观。


Return to today‘s topic！
本文主要分享一个简单的应用——怎么使用CANoe手动发送功能寻址诊断请求。
CANoe是Vector公司一个功能齐全（通信、诊断、测试等）的上位机工具，在本文中应用场景是做诊断测试上位机（Tester角色）。
首先车载网络中诊断是直接通信方式，其典型模型是Tester发送请求，ECU基于接受到的诊断请求给与响应。
1、物理寻址和功能寻址定义
在车载诊断范畴，常见的寻址方式分如下两种：
->物理寻址方式；
->功能寻址方式。
物理寻址方式通俗讲，就是Tester与ECU一对一通信模型，如下示意图：


Tester通过连接OBD口，发送诊断请求至网关，车载CAN总线是总线类型，网关将该请求转发相应的域（如图是动力域）。发送机收到请求并基于请求给与响应。具体可以参看如下示意图：



功能寻址方式通俗讲是Tester与多个ECU一对多通信方式，具体可参考如下示意图：



Tester通过连接OBD口，发送诊断请求至网关，因为是功能寻址，（Tester一个对功能寻址组多个ECU，如图标红的两个）。Tester以CAN ID 0x 750发送诊断请求，对应的两个ECU收到请求并基于请求发送诊断响应，具体可以参看如下示意图：


在整车定义其诊断需求规范时，诊断系统工程师或者网络架构师会定义一个功能寻址组，功能寻址组（多个ECU）使用一个功能请求ID。当Tester以这个功能寻址ID发送请求时，这个组内所有ECU需要基于接受到这个请求并给予这个请求给与相应的诊断响应（Diagnostic response）。

在定义车载CAN总线诊断需求规范时，一个具体ECU会有3个CAN ID，作为诊断范畴的通信识别号：
物理请求CAN ID；

物理相应CAN ID；

功能请求CAN ID；

当Tester以功能请求ID发送请求时，这个功能寻址组内所有ECU收到请求后回复这个请求.

二、CANoe功能寻址方式发送诊断请求
在本文使用场景，是基于CANoe工具手动发送功能寻址诊断请求。
首先，基于CANoe工具，新建一个车载CAN总线工程，具体操作如下图所示：


本例中使用诊断数据库CDD(Vector工具CANdelaStudio基于OEM诊断需求规范编辑的诊断数据库格式，该工具使用办法可参看文末工具文章操作指南汇总)，当然也可以使用其他诊断数据库格式（比如ODX、PDX）。在CANoe工具中，如下图所示位置添加诊断数据库CDD文件，并勾选“Physical request”寻址方式：



因为本文操作内容是要分享的是基于功能寻址方式发送诊断请求，因此需要在CANoe如下位置复制一个诊断控制台，用于定义发送功能寻址请求：


并将基于功能寻址的诊断控制台选择功能寻址方式发送请求（设置项在如下图标注地方进行选择功能寻址方式）：


如下图所示，CANoe加载诊断数据库CDD文件，可以自动识别诊断数据库CDD文件中在ECU Interface中定义的诊断通信通信参数并将这些通信参数在CANoe的人机交互界面显示出来。如下图所示：


交互界面显示内容：
物理请求寻址CAN ID：0x A1
功能请求寻址CAN ID：0x B1
物理响应寻址CAN ID：0x E0
因为编辑诊断数据库CDD文件需要对应的CANdelaStudio License，当你待测ECU与数据库通信参数不一致时，但此时自己电脑上又没有CANdelaStudio License，可以在CANoe中选择勾选Override进行手动更改通信参数。
对应在交互界面诊断控制台也分：
对应物理寻址：ABS_ESP
对应功能寻址：ABS_ESP_1



测试工程师在物理寻址诊断控制台ABS_ESP发送 Service 10 01(默认会话模式请求)
在功能寻址诊断控制台ABS_ESP_1发送Service 10 03(扩展会话模式诊断请求)
发送完请求后，查看Trace内容如下，达到自己使用目的：
是以上分享希望有所帮助。