Autosar UDS-CAN诊断开发02-1(CAN、CANFD诊断帧格式类型详解、15765-2(CANTP层)的意义)

前言

CANTP层（15765-2协议）存在的意义

普通CAN格式诊断帧类型详解

四种诊断报文类型

单帧SingleFrame(SF)

首帧：FirstFrame(FF)

流控帧：FlowControl(FC)  

连续帧：ConsecutiveFrame(CF)

中间小结 

CANFD格式诊断帧类型详解

差异点：单帧SingleFrame(SF)

差异点：首帧FirstFrame(FF)

结束

前言
         我们先来看一下诊断报文数据Log：

上面图中，红色为诊断仪（Canoe或Canpro）发，蓝色为ECU发。

        我刚开始接触诊断的时候。

        看着这些密密麻麻的数据一脸茫然，由于经常能听到同事们在说19服务，所以我知道19服务读DTC，但Canoe发出的19 0A前面为啥还有个0x02？为什么ECU先返回了一帧然后再返回后面的多帧？为什么中间还夹这一帧Canoe发出来的？30 00 14又是啥意思？多帧的数据要怎么看啊，全部数据都是跟DTC故障有关吗？

        真的是小小的脑袋大大的问号。

        ...

        后来我才知道，这一切的由来都是15765-2协议。上面这个流程中，诊断仪和ECU间为什么是这样交互，所有数据中与诊断服务无关的其它数据分别代表什么意思，15765-2中全都有详细的定义。

CANTP层（15765-2协议）存在的意义

        先看一下在Autosar架构中，CANTP层在诊断链路中的位置：

  要理解为什么诊断报文的链路需要CANTP层（15765-2协议）。

        我们可以先看一下普通应用报文的链路：

                应用报文链路：CAN->CANIF->PDUR->COM->APP

你会发现，应用报文其实很简单。它没有什么协议，收到什么就直接解读就好了。

        比如，车企定义了0x123报文中的Byte0的8个字节为电池的温度，那么当ECU收到0x123报文的时候，直接把Byte0的8个字节读取出来就直接是电池的温度了。换句话说，应用报文的发送和接收是没有什么协议的。

        由于应用报文没有什么协议，因此，应用报文传输数据就完全受限制于物理层的CAN协议（11898），一帧CAN报文的长度最大是CANFD的64Byteÿ