UDS on CAN (DoCAN) - ISO 15765

📅 2026/7/5 20:34:06
UDS on CAN (DoCAN) - ISO 15765
定义ISO15765-2 标准主要内容是Transport protocol and network layer services即传输层和网络层的服务根据ISO7层模型此层的下一层级是数据链路层和物理层上一个层级是会话层和应用层。网络层负责在不同网络间传输数据包并处理数据的路由选择使数据能够从源地址传输到目的地址。其存在的目的是为了解决ISO 11898协议中定义的经典CAN数据链路层与ISO14229协议中定义的应用层彼此之间数据长度不统一的问题。经典CAN数据链路层最大能够支持8个字节但ISO 14229并不仅仅是为了CAN总线设计的最大容量达到4095个字节。比如VIN码是17个字节CAN总线必然需要传递3帧才能传完VIN码那么如何科学、快捷、安全地将多个字节通过经典CAN来进行传输就成了一个需要解决的问题ISO 15765-2 协议由此诞生。基于CAN的UDS诊断服务通过network protocol data unit网络协议数据单元即N_PDU来实现而别的数据传输且两个网络实体时间的通信必须遵循N_PDU的格式和定义N_PDUN_PDU的格式主要由3部分组成N_AI, N_PCI, N_Data地址信息协议控制信息数据N_AIN_PCIN_DATAN_AI表示网络地址信息即通信双方都需要知道跟谁通信地址是什么在CAN里面就表示CAN ID常规寻址对于11位CANIDN_AI映射到CANID但没有规定N_AI与CANID的具体映射关系常规固定寻址对于29位CANID与混合寻址编排方式类似完整定义了N_AI如何映射到29位CANID上扩展寻址对于11位CANIDN_AI中的N_TA映射到CAN数据帧的第一个字节N_AI中的其它域映射到CANID混合寻址11位或者29位CANID仅用于远程寻址N_PCI表示协议控制信息规定了N_PDU所携带的数据的组织形式N_Data表示网络数据即N_PDU所携带的数据内容N_AI和N_Data很容易理解就是地址信息和数据信息重点在于怎样合理的把数据发送出去也就是以什么样的形式发送这就涉及到N_PCI的定义对于CAN网络通信由于标准CAN的传输数据上限为8个字节对于需要传输数据比较大的情况往往就需要通过网络层的N_PDU来控制保证数据合理、高效、完整的传输到目标接收方那么可以将N_PUD分为4种数据帧单帧SF首帧FF连续帧CF流控帧FC其中不同帧种的N_AI, N_PCI, N_Data定义又有所不同对于一组数据需要以什么样的形式发出取决于该数据的长度单帧当数据的长度小于等于7Byte时就以单帧的形式进行发出单帧的N_PCI为0000用16进制表示就是0在第一个字节中高四位表示N_PCI低四位表示数据长度即单帧的第一个字节为0xx为单帧的数据长度首帧当数据的长短大于7Byte时就需要以首帧连续帧的形式发出首帧的N_PCI为0001用16进制表示就为1即首帧的第一二个字节为1xxxx xx为首帧的数据长度低四位第2个Byte用于表示首帧的数据长度连续帧对于连续帧跟在首帧之后的数据帧其N_PCI为0010用16进制表示就为2低四位表示连续帧的序号SNSequence Number即连续帧的第一个字节为2xx为连续帧的序号123···最长为15使用这个机制的目的就是为了让发送方按顺序发送CF并且接收方在接收CF的时候能根据 SN 来判断 数据帧 是否按照正确顺序来接收从而做出相应的判断。而对于接收方来说是否能够一次性接收大量数据取决于接收方发给发送方的流控帧流控帧流控帧的N_PCI为0011用16进制表示就为3即流控帧的第一个字节为3x其中流控帧中包含了需要告诉发送方的一些信息比如Byte1的低四位表示Frame status(FS)表示接收方对发送方的数据传输能力的反馈主要有三种0000表示继续发送(CTS)即正常接收和数据处理0001表示等待时间(WT)即接收方需要暂停数据传输通知发送方继续等待新的流控帧(N_PDU)的到来并重新设置 N_BS 定时器0002表示溢出overflow接收方的缓冲区已满无法接收更多数据Byte2的BS定义表示接收端在发送下一帧流控帧之前允许发送端连续发送的最大连续帧个数当值为00时表示发送端不用拆分数据发送端应该不停地发送剩下的数据当值为01-FF时用于指示发送方在没有接收到下一帧流控帧期间能发送的最大数目的连续帧。Byte3的Stmin定义表示发送端发送连续帧的最小间隔时间。00-7F间隔时间范围为0ms-127ms网络层时间参数S:send发送方R:receive接收方N_As: 发送方发送完首帧的时间主要取决CAN速率N_Br: 接收方接收到首帧发出流控制帧的时间Developer设计N_Cs: 发送方接收到流控制帧发出连续帧的时间Developer设计帧的传输单帧单帧的传输比较简单数据的第一个字节为数据的长度后面的字节为具体的数据内容例如22 10 20空闲位用0xFF填充填充不一定都是0xFF具体看OEM厂商定义Byte0Byte1Byte2Byte3Byte4Byte5Byte6Byte70x030x220x100x200xFF0xFF0xFF0xFF多帧多帧的情况就比较复杂接收端收到首帧后需要发送流控帧给发送端告知发送端自己在发送下一次流控帧之前能够接受的最大数量的连续帧BS告知不要发太多以及两个连续帧之间的最小间隔时间STmin告知不要发的太快发送端在收到流控帧的要求后按照要求继续发送连续帧接收端也不断接收连续帧若接收端已经收满BS数量的连续帧且与首帧中包含的数据长度对于发现还没接受满则会继续发送流控帧以此类推。物理寻址和功能寻址物理寻址可以理解为ecu设备之间点对点的通信支持网络层所有消息类型功能寻址类似于广播形式功能寻址为单帧请求ECU应该忽略所有非单帧的功能寻址信息like 首帧单帧0x0X首帧0x1X连续帧0x2X流控帧0x3X