诊断通讯模块Dcm的数据传输概述

最新推荐文章于 2024-07-07 16:07:56 发布

SOA开发者

最新推荐文章于 2024-07-07 16:07:56 发布

阅读量2.1k

点赞数

文章标签：网络

原文链接：https://bbs.z-onesoft.com/omp/community/front/api/page/mainTz?articleId=7713

版权

本文将介绍诊断通讯模块Dcm的数据传输问题--基于CAN总线的传输层通讯机制。

1 基于CAN总线的诊断通讯

故障一旦确认将被存入非易失性存储器，这时通过外部测试设备去读取这个故障的话，都需要基于某个总线通信协议才能实现。比如在ISO14229-1协议中就列举了多种通讯总线，包括：K-line，LIN，CAN，FlexRay和IP等。针对ECU软件研发，一般最常用是基于CAN总线进行诊断通讯开发。

根据ISO15765-3协议，在OSI模型架构上，基于CAN总线的诊断通讯需要一系列的协议标准来支持，如下图所示。本文将不会对每一层协议进行介绍和解释，将侧重于概述CAN的网络传输层，意在重点说明诊断通讯的传输机制。不过在进行这个主题前，对于CAN总线这块的知识可先参考本人知乎的系列文章：CAN通讯系列。

2 诊断通讯的传输机制介绍

当对CAN总线通讯机制有所了解之后可知，每帧帧报文可传输8个字节的数据，诊断信息就可以通过这8个字节进行传输。不过诊断信息也有超过8个字节的情况，比如车架识别码。也就是说诊断数据超过8个字节，而一帧CAN信息只能传输8个字节的数据，这就意味着诊断数据无法通过一帧CAN信息传输完。那怎么办呢？

自然地，我们想到的一种方案是分割诊断数据，通过多帧CAN信息来传输；另一种方案是让一帧CAN信息传输出更多的数据。针对前者就提出了ISO15765协议，针对后者有了CAN FD。现如今CAN FD可传输64个字节长度的数据，但诊断数据超过64个字节，仍将面临上述问题。不过通过对ISO15765协议的了解，你会发现这个协议可以彻底解决诊断数据过长问题。在ISO15765协议定义了两种传输机制，即单帧传输和多帧传输，包含四种协议数据单元类型，其中单帧SF对应单帧传输，首帧FF，续帧CF和流控帧FC对应多帧传输。

下面详细解释下多帧传输，当通过一帧CAN信息接收到8个字节的诊断服务数据，根据ISO15765-2协议可知，这个数据将是单帧SF或首帧FF或连续帧CF或流控帧FC，即需要CanTp模块应先识别此时接收数据的类型（N_PCItype）；然后再根据寻址格式来提取数据，由于网络层数据的交换支持三种寻址格式，包括正常格式(normal)，扩展格式（extended）和混合格式（mixed），因格式不同数据长度将有所区别。正常格式有7个字节数据，扩展格式和混合格式有6个字节数据，如下图所示。正常格式的CAN帧数据场由数据单元类型和数据组成，数据单元类型占用1到3个字节，数据占用剩余字节；而扩展格式需要提供一个字节供目标地址使用。因此要先根据寻址格式确定数据单元类型和数据的长度，再提取数据单元类型，最后提取出相应的数据。

假设接收到为正常格式的诊断数据，则对于单帧SF数据，则从第2到8个字节提取诊断服务数据；对于首帧FF数据，则从第3到8个字节提取诊断服务数据，根据协议可知，这些数据代表首帧数据长度信息；对于流控帧CF数据，则从第3到8个字节提取诊断服务数据，根据协议可知，这些数据包括流控状态FS, 块大小BS和分开时间STmin，后两个量的定义见上面的多帧传输图，而流控状态定义了3种类型，分别为0-连续发送，1-等待，2-溢出。对于连续帧CF数据来说，则从第2到8个字节提取诊断服务数据，而第1个字节的前四位代表序列号，即代表第几条连续帧，以便能识别出后组装回数据。

3 传输机制的应用实例

下面先以一个接收例子进行说明，假设接收的诊断服务数据长度有49个字节，上层报告接收的buffer有25个字节可用，那么具体的接收过程将按如下进行:

Dcm被通知新接收到了一帧数据（首帧），Dcm将反馈可用的buffer大小有多少个字节，比如本例为25个字节，然后由CAN网路传输层模块CanTp发送一帧流控状态为继续发送的流控帧给发送方；CanTp提供每帧接收帧的数据给Dcm，并监控剩余的buffer大小。当接收了两帧续帧后，剩余buffer大小不够存下一个块的数据（接下来的两帧续帧）；CanTp请求Dcm的剩余buffer大小，并发送一帧流控状态为等待的流控帧给发送方，直到有充足buffer大小来接收下一个块才停止；当buffer大小够了后，CanTp发送一帧流控状态为继续发送的流控帧给发送方，继续接收下一个块；在存好了一个块的最后一帧续帧后，又出现buffer大小不够时，重复上图的4，5；当buffer空间能接收最后一个块，CanTp继续接收；当数据接收完，CanTp通知Dcm接收完毕。注意：接收的buffer只有25个字节空间可用，不足以一次性全部接收这49个字节的诊断服务数据，所以CanTp模块分几个块来接收，当接收完一个块后，buffer空间不够接收下一个块，那么，接收方将会发送一帧流控状态为等待的流控帧给发送方，当最后buffer大小够了的话，接收方将会发送一帧流控状态为继续发送的流控帧给发送方，让其继续发送。

下面再以一个发送过程为例进行说明：

首先，看一个单帧发送处理的例子，假设采用正常寻址格式,通过测试设备请求了扩展会话模式，即请求的服务为10 03，一帧CAN帧数据 02 10 03 00 00 00 00 00 00 发送给诊断通讯模块Dcm，这里假设5个字节0x00为填充数据，对请求处理无作用，也就是Dcm只是收到切换到扩展会话模式的命令。

然后看一个多帧发送处理的例子，假设DCM模块进行请求处理后正响应有50个字节数据，显然这时需多帧传输才能把响应数据发送给接收方，发送方先会发送FF给接收方，告诉接收方整个信息的数据长度。发送FF的大致过程与基本SF一样，只是第1步中，会根据整个信息的数据长度大于单帧的数据长度来确定与FF发送相关配置参数，处理FF发送请求；

当CanTp接收到FC时，将会更新STmin，然后发送CF，注意已通过首帧发送几个字节的数据，这时CanTp会按照续帧的顺序号逐帧地发送剩余的数据，上层每次将复制6或7个字节数据给每帧续帧，数据发送成功，与SF,FF一样，向上确认发送成功，如下图所示。当CanTp接收到FF时，接收方将发送FC，以表明可继续发送续帧；当接收方出现buffer溢出或者需要等待的情况时，也需要通过设置对应的流控状态来通知发送方。与SF，FF的发送一样，FC的基本步骤一致，这里不再展开。