目录
前言
为啥我要写这个点呢?
我给你们贴一张15765-2中官方标准流程图你就知道为啥我要写了
从上面这张图来看,对于初学者而言,你们能看出来Sender和Receive哪个是ECU哪个诊断仪吗?
我们假设一下:
假设①:左边是ECU,右边是诊断仪。
分析:那不对,ECU不可能发出第一帧诊断报文的,第一帧诊断报文一定是诊断仪发出来的。
假设②:左边是诊断仪,右边是ECU。
分析:
第一步:诊断仪发出第一帧,FF(首帧),嗯,挺合理的。
第二步:不对啊,ECU怎么发流控帧啊,我平时看到都是诊断仪发流控帧的
第三步:更不对啊,诊断仪怎么还发起了连续帧。
然后,看着这个破15765-2的流程图,心里一万个草泥马路过。。。
好了,抱着上面的这个疑问,我们开始讲诊断仪和ECU的交互流程中的帧类型使用情况。
诊断仪和ECU发送的诊断帧类型是否固定?
既然前面也说了,交互过程种,第一帧一定是诊断仪发出来的,然后ECU是返回数据。
那么,是不是说诊断仪发出来的第一帧的帧类型永远是固定的呢?都是诊断仪请求ECU嘛,那么诊断仪发出的第一帧的类型肯定是固定的吧?都是ECU返回数据嘛,那么ECU返回的帧类型肯定都是固定的吧?
然而...
诊断仪或ECU发送的诊断类型并不是固定不变的。
一开始我刚开始接触诊断的时候,我按照字面意思理解,首帧首帧,不就是交互开始的第一帧嘛,所以首帧一定诊断仪发的!
然而,我里个去,结果不是的,比如看回这张图。
按照我们前讲的帧类型的定义,图中第一个字节(byte0)的高4位是0,它代表是SF(单帧)的意思。所以,单单从这个图来看,交互开始的第一帧是单帧(即此时诊断仪第一帧发的是单帧)。
啊?这样啊,那这回我明白了!既然前面也说了,第一帧永远都是诊断仪先发出去请求ECU的,那么诊断仪发出来肯定永远都是单帧!我真他娘是个天才!
信誓旦旦的我过了一段时间,然而,他娘的,我又错了。
居然还有诊断仪发第一帧不是单帧的情况?(暂时没有图,下面就先文字描述了):
2E服务中诊断仪需要向ECU写入DID数据,如果DID数据超过了4个Byte,那么诊断仪发出的第一帧就是首帧,而不是单帧了。(至于为什么是超过4个byte,我们这里先不深究)
这种情况下交互流程是这样的:
①由于诊断仪需要写入的DID数据超过了4个Byte,因此诊断仪数据一帧发不完,所以诊断仪发的第一帧是首帧,②然后ECU需要发送流控帧,③最后诊断仪发连续帧。
总结来说,15765-2协议并不会定义诊断仪发的帧类型是什么、ECU发的帧类型是什么,即上面的四种帧类型,ECU和诊断仪都有可能发,交互流程不是固定的。
大多数情况的帧类型发送情况
①诊断仪第一帧发送单帧的情况:
大多数诊断服务,诊断仪发送第一帧请求ECU,都是单帧。比如10服务会话跳转、11服务复位、19服务读取DTC等等
如下图
②诊断仪第一帧发送首帧的情况(只有一种情况):
2E服务诊断仪写入DID数据超过了4个Byte。
如下图:
结束
看完之后,我们再回到文章开始的那个问题。
文章开始的那种图,它本身确实是没有问题。
但关键是那张图并不是我们经常接触到的诊断协议交互流程,这张图的流程实际在接触中很少出现,2E服务写数据DID的数据长度超过4个Byte才会出现。
而大家平时接触到是诊断仪发单帧的情况(即下面这张图),所以导致大家看官方标准看的一脸懵逼。
好了,下篇文章我会写一下关于诊断服务中诊断相关的时间参数。
返回目录: