接口/总线/驱动
工程中,随着CAN FD的使用越来越普及,随之而来的问题,也越来越多。本文讨论一个问题:CAN总线既支持Classical CAN格式报文,也支持CAN FD格式报文,诊断的过程中,可以混合使用Classical CAN格式和CAN FD格式的诊断报文吗?
1、N_AI定义
找到这个问题的答案之前,我们先理解一下N_AI(Network Address Information)的概念。
15765-2的规范中,这样解释N_AI,如下所示:
解释:意思是说,N_AI这个参数用于识别诊断通信过程中的源地址和目标地址。
解释:N_AI的另一种作用解释就是标识网络层的对等实体(peer entities)。什么是对等实体?
答:个人理解,特定的信息只有到达指定的模块,才能被解析。也可以将其看作特定协议的解析者,比如:15765,CanTp层才能解析,如下所示:
2、N_AI在CAN报文中的位置
一个N_PDU包含三个部分:N_AI、N_PCI、N_Data。N_AI位于N_PDU中,具体位置如下所示:
具体到CAN Frame,N_AI位置示意如下所示:
这里可以看出:Classical CAN和CAN FD的不同,意味着N_AI的不同。N_AI信息会映射到网络传输层(CanTp),N_AI的不同,意味着寻址方式的不同,即使Classical CAN和CAN FD的CANID相同,CanTp层建立的Connection也不同。
3、相同CAN ID(不同N_AI)的非预期帧处理策略
之前我们聊过:诊断处理过程中,收到非预期诊断报文(Unexpected PDU)的处理方式,可以回顾前文Uds诊断:Unexpected N_PDU处理策略。这个策略适用于相同CANID,但是N_AI不同的诊断报文吗?看一下15765给出的解释,如下所示:
解释:Unexpected N_PDU的处理只适用于相同N_AI的诊断报文。Classical CAN和CAN FD的N_AI本就不同,所以,互不干扰,可以并行处理;单个Message中不要混用Classical CAN和CAN FD。
提示:工程开发中,即使CAN ID相同,也可以既支持Classical CAN,也支持CAN FD。
综上,Classical CAN和CAN FD的CAN ID相同,但是Format不同,构成的N_AI不同,所以,在CanTp层建立的peer entity不同,工程使用过程中,可以并行使用,但是不能交叉混用。
(一)完整的诊断请求时序中,独立使用Classical CAN或者CAN FD均可,示意如下:
(二)完整的诊断请求时序中,不能混用Classical CAN、CAN FD,示意如下:
审核编辑:刘清
全部0条评论
快来发表一下你的评论吧 !