大家好，我是嵌入式老林，从事嵌入式软件开发多年，今天分享的内容是UDS网络层SF_DL错误处理介绍，希望能对你有所帮助
一、问题背景
最近在遇到一个诊断服务的问题，一开始也是一头雾水。
正常情况下，测试诊断一般都是测支持的会话模式，寻址方式，回复的NRC，回复的内容是否正确等等，例如测试0X10服务：
通常都是，测试一下10服务支持的子功能， 以及 各个子功能在哪个会话模式在支持，是否支持功能寻址，支持的NRC等等。
举个例子：
TX 02 10 03 00 00 00 00 00 // 02: 0表示单帧，2表示后面的数据有2个字节；10：10服务是诊断会话控制服务；03：表示子功能是扩展诊断会话；后面的0是填充位
RX 06 50 03 00 32 01 F4 AA // 06：0表示单帧，6表示后面的数据有6个字节；50表示肯定响应码，值为服务请求的值加0X40；03表示子功能；00 32表示P2server_max，转换成十进制就是50，那么P2server_max就是50ms
01 F4表示P2*server_max，转换成十进制就是500，再乘以单位10ms，即P2*server_max为5000ms
但是你见过这种测试的case吗？
也就是： TX 00 10 01 CC CC CC CC CC
告诉下位机发送的单帧数据长度为0，但是后面还是跟了2 byte，后面的5 byte是填充位。解释一下，为啥会回复成：7F 01 11，因为把第二个字节10当成数据长度了，把01当成service ID了，所以回复0X11服务不支持
一开始见到这个测试case的时候，心里一直在骂客户，这测的啥玩意，甚至差点就要跟客户说这个测试case不合理了，直到后来自己翻阅了一下ISO-15765的协议，查到相关的规范说明后，发现小丑竟是我自己。实际上这个case的用意就是测试一下UDS的网络层协议是否符合规范。
一般情况下如果客户没有给企标就参考UDS的标准规范，应用层就参考ISO-14229，网络层就参考ISO-15765的协议
二、网络层SF_DL的错误处理
先来介绍一下网络层的数据格式：
具体的组成如下图所示，第一个字节的高4bit，用来表示帧类型，
单帧SF：0，首帧：1， 连续帧：2， 流控帧：3
单帧的第一个字节的低四位表示要传输的数据长度，如果不是标准帧的话，CAN_DL 会大于8 byte，那么 第一个字节的 低 四位就置零，用byte 2表示单帧要传输的数据长度
看一下网络层的 单帧 长度错误的处理规范
2.1 CAN_DL <= 8
如果接收到的CAN _DL <= 8，以下4种情况都要忽略收到的这一帧内容
1）如果网络层接收到的单帧长度为0，则网络层要忽略接收到的单帧内容。像下面这种情况，就需要忽略这一帧，不做任何回复
2） 如果是标准地址时，且收到的单帧数据比(CAN_DL – 1)大，则网络层要忽略收到的这一帧数据。
如果是扩展或混合地址时，且收到的单帧数据比(CAN_DL – 2)大，则网络层要忽略收到的这一帧数据
例如，像下面这种情况
3） 在CAN帧数据填充的情况下：如果网络层收到一个CAN_DL不等于8的SF，则网络层忽略收到的SF N PDU;
4） 在CAN帧数据优化的情况下：如果网络层收到的SF DL值不符合表12所示的有效值，则网络层忽略收到的SF N PDU。其实就是，在没有填充位的情况下，CAN_DL和SF_DL需要满足下图表12的关系，如果不满足则忽略这一帧
2.2 CAN_DL > 8
接 收到的CAN_DL > 8，如下2种情况需要忽略
1）如果网络层接收到的SF第一字节的低4位不等于0，则 网络层要 忽略收到的这一帧数据
2） 如果 网络层接收到的SF中的SF_DL和上面的表13符合，则 网络层要 忽略收到的这一帧数据。
所以当发送的单帧报文，长度为8字节，但单帧的长度为0时，则不响应
