本文主要是介绍Autosar UDS-CAN诊断开发02-2(诊断仪和ECU的交互流程中的帧类型使用情况)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目录
前言
诊断仪和ECU发送的诊断帧类型是否固定？
诊断仪或ECU发送的诊断类型并不是固定不变的。
大多数情况的帧类型发送情况
①诊断仪第一帧发送单帧的情况：
②诊断仪第一帧发送首帧的情况(只有一种情况)：
前言
为啥我要写这个点呢？
我给你们贴一张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才会出现。
而大家平时接触到是诊断仪发单帧的情况（即下面这张图），所以导致大家看官方标准看的一脸懵逼。
好了，下篇文章我会写一下关于诊断服务中诊断相关的时间参数。
返回目录：
Autosar BSW 开发笔记（目录）-CSDN博客
这篇关于Autosar UDS-CAN诊断开发02-2(诊断仪和ECU的交互流程中的帧类型使用情况)的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
