前言

之前在没有真正接触CANFD时，理解的CANFD报文只是两个主要变化点：
1.波特率可切换
2.数据位拓展为64位

这样的话，对于之前的CAN报文来说，DBC可以很好的兼容CANFD报文，只需要定义好message中的layout即可。但目前实际使用过程中，并不是简单的一个message包括一个PDU，而是通过Arxml文件引入了Container-PDU和I-signal-PDU，一个CANFD的frame中可能包含多个I-signal-PDU。

PDU类型定义

在Arxml文件中定义的有如下类型：

对于标准CAN通讯来说，比较常用的就是ISignal-I-Pdu，Container-I-Pdu。后面再详细介绍。

Autosar定义的PDU

对于普通CAN报文来说，一个message对应一个PDU，对于CANFD报文来说，引入Container PDU和contained I-PDU实现一个message对应多组PDU。

考虑这样做的优势：

不同的contained I-PDU可以映射到不同的Container PDU的不同位置。不仅提高了灵活性，而且也会降低总线负载率。

动态Container布局

Autosar引入了动态Container的layout，也就是说PDU存在的位置是不固定的，将PDU Header和I-PDU打包后可以放入不同Container PDU的不同位置中。
可以这么理解:PDU Header就是之前普通CAN报文的ID和DLC。

CANFD ContainerPDU定义

ContainerPDU并不是frame，但可以设置ContainerPDU包含frame所有的数据位。ContainerPDU是包含在frame中的。
对于一个CANFD-frame,定义如下：

注：若CANFD报文实际只有8字节，那么就和普通报文一样，定义一个I-Signal-PDU就够了，不需要引入容器PDU。

Container-I-PDU定义如下：

Header Type有三种选择:

1.ShortHeader 2.LongHeader 3.NoHeader

Autosar中定义如下：

IpduM支持两种不同的动态Container Pdu的头大小(参见ECUC_IpduM_00183: IpduMContainerHeaderSize):
IPDUM_HEADERTYPE_SHORT, 24位ID, 8位长度
IPDUM_HEADERTYPE_LONG, 32位ID, 32位长度

如果是选择的ShortHeader,那么实际数据位中会有三个byte为ID，一个byte为DLC，8个byte为数据位

在Container-PDU定义页可以选择包含的PDU及设置PDU对应的ID。

CANFD Signal-I-PDU定义

这个Signal-I-PDU就类似普通的CAN报文，里面定义了具体的信号信息，及layout信息。

CANFD实际数据解析

CANFD带Container的报文，实际数据长度为24，包含两个Signal-I-PDU（每个12个byte）

对应的Signal-I-PDU还可以继续展开解析后的信号具体信息

总结

CANFD报文若使用contained I-PDU和Container PDU，则DBC不适合再用来管理通讯矩阵，需要采用Arxml文件来管理。若没有选择使用HeaderID和DLC，则DBC还可以继续使用，对于应用来说，相对于CAN的DBC只是长度增加而已。

使用I-Signal-PDU,使得CANFD报文中的信息更加灵活，对于网关转发，信号解析更加方便。

目前主要只用到了I-Signal-PDU，若用到其他的，会持续更新本文~~
若你觉得本文对你有帮助，欢迎点赞，关注，收藏，转发~~~
你的鼓励是对小弟的最大支持~~~

建了一个WX公众号，《汽车电子学习笔记》感兴趣可以关注一下~~~文章都会同步更新~