UDS协议详解系列：CanTp6.docVIP

UDS协议详解系列：CanTp6 1 CanTp模块 当诊断服务基于CAN总线实现，如果请求或响应的诊断数据超过8个字节，而一帧CAN信息只能传输8个字节的数据，这就意味着诊断数据无法通过一帧CAN信息传输完。那怎么办呢？自然地，我们想到的一种方案是分割诊断数据，通过多帧CAN信息来传输；另一种方案是让一帧CAN信息传输出更多的数据。针对前者就提出了ISO15765协议，针对后者有了CAN FD。现如今CAN FD可传输64个字节长度的数据，但诊断数据超过64个字节，仍将面临上述问题。不过通过对ISO15765协议的了解，你会发现这个协议可彻底解决诊断数据过长问题。 ISO15765协议定义了两种传输机制（单帧传输和多帧传输），四种协议数据单元类型（单帧SF，首帧FF，续帧CF和流控帧FC）和相关的网络层定时参数（N_As，N_Ar，N_Bs，N_Br，N_Cs和N_Cr），如图1所示。 图1 两种传输机制，引自[1] 本文将介绍的CanTp模块是ISO15765协议的软件实施，CanTp模块的最主要作用是分割和组装超过8个字节长度的CAN I-PDUs。在基于AUTOSAR架构的通讯栈中，CanTp模块位于PDU Router和CAN Interface模块之间，如下图2所示。 图2 AUTOSAR 通讯栈，引自[2] CanTp模块提供的服务有：发送方向分割数据，接收方向组装数据和控制数据流等。在接收方向CanIf模块经CanTp_RxIndication函数通知CanTp模块；在发送方向CanTp模块调用CanIf_Transmit函数来发送数据，如下图3所示。 图3 CanTp与其上下层的交互，引自[2] 下面我们来了解下具体的接收与发送过程。 2 接收过程 当通过一帧CAN信息接收到8个字节的诊断服务数据，根据ISO15765协议可知，这个数据将是SF或FF或CF或FC。因此不难理解：CanTp模块应先识别接收数据的类型（N_PCItype）。然后再提取数据，由于网络层数据的交换支持三种寻址格式格式：正常格式(normal)，扩展格式（extended）和混合格式（mixed），因格式不同数据长度将有区别：正常格式有7个字节数据，扩展格式和混合格式有6个字节数据，如图4所示。故先根据寻址格式确定数据长度，再提取数据。最后根据不同数据类型进行相应的接收处理。 图4 不同寻址格式的定义，引自[1] 2.1 SF（单帧）接收处理 考虑到CanTp模块没有缓冲能力，CanTp将直接作用于上层（比如PduR或DCM）的存储区域。要访问这些存储区域，CanTp模块将使用PduR_CanTpCopyRxData函数。同时为了保证数据的一致性，上层必须锁定这些存储区域直到一个通知发生。这里CanTp模块将使用PduR_CanTpStartOfReception函数来通知上层的PduR模块，这样上层的模块将为接收的数据保留和锁住buffer，如下图5所示。 图5 接收buffer的锁定状态切换示意，引自[2] 针对接收到一帧SF的情况，从CanIf模块到CanTp模块的大致过程为： 1.下层接收到一帧诊断服务的数据，经CanIf调用CanTp_RxIndication函数通知CanTp模块; 2.CanTp模块先根据N_PCItype识别出是SF，在考虑了寻址格式的基础上，确定取数据长度； 3.CanTp模块由于自身没有缓冲能力，将调用PduR_CanTpStartOfReception函数向上层确认是否有足够的buffer大小来存储接收的数据； 4.上层分配和锁定所需的接收buffer。且返回BUFREQ_OK，然后CanTp模块调用PduR_CanTpCopyRxData函数让上层把接收的数据复制到接收buffer； 5.当复制成功完成，CanTp调用PduR_CanTpRxIndication函数通知上层。 这就是理想的SF接收成功的基本过程，如下图6所示。 图6 SF接收过程，引自[2] 但实际的SF接收可能会有一些原因导致接收不成功，比如： 由于错误或资源限制原因，上层不能使buffer有效。那么PduR_CanTpStartOfReception将返回buffer状态NOT_OK或溢出，这时CanTp模块将丢弃接收的数据，也不会调用PduR_CanTpRxIndication函数； 如果PduR_CanTpStartOfReception返回buffer状态OK，但有效bufferd的size比已接收数据的小，这时CanTp模块将丢弃接收的N-PDU，也将调用PduR_CanTpRxIndication，赋给结果NOT_OK信息。 在工程上，基于接收成功过程的理解，我们必须还要充分考虑会发生哪些使接收不成功的情况，以及如何