ISO-15765 网络层
ISO15765诞生背景
TP层存在意义
-
UDS网络层,又称为TP层(Transport Protocol Layer)。
-
其存在的目的是为了解决
ISO 11898协议
中定义的经典CAN数据链路层与ISO 14229协议
中定义的应用层,彼此之间数据长度不统一的问题。- 经典CAN数据链路层最大能够支持8个字节,但ISO 14229并不仅仅是为了CAN总线设计的,最大容量达到4095个字节。
- 比如VIN码是17个字节,CAN总线必然需要传递3帧才能传完VIN码,
- 那么如何科学、快捷、安全地将多个字节通过经典CAN来进行传输,就成了一个需要解决的问题。
ISO 15765-2 协议
由此诞生。 ISO 15765-2
作为车辆诊断通信的一个组成部分,规范了“传输协议和网络层服务”。
网络层协议数据单元 N_PDU
网络层协议数据单元(N_PDU,Network_Protocol Data Unit)包含N_AI,N_PCI,N_Data,即地址信息,协议控制信息和数据
参数名称 | 缩写 | 描述 |
---|---|---|
寻址信息 | N_AI | 隐含源地址、目标地址和寻址方式信息 |
协议控制信息 | N_PCI | 标识网络层帧类型 |
数据 | N_Data | 包含应用层协议控制信息和数据 |
网络层协议控制信息N_PCI
N_PCI全称为Protocol Control Information
N_PDU名 | N_PCI(Network_ProtocalControlinformation) | 数据区域 | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Byte 0 | 1 | 2 | 3-7 | ||||||||||||||||
bit 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ||||
单帧(SF) SingleFrame | N_PCItype=0 | DataLength(SF_DL) | N/A | N/A | N/A | ||||||||||||||
首帧(FF) FirstFrame | N_PCItype=1 | DataLength(FF_DL) 12位,最大发送4096个字节 | DATA | ||||||||||||||||
流控制帧(FC) FlowControl | N_PCItype=3 | Flow State(FS) 0:继续发送 1:等待 2:溢出 | BlockSize(BS) *BlockSize=0再无流控制帧 | STmin[ms] | N/A | ||||||||||||||
连续帧(FC) ConsecutiveFrame | N_PCItype=2 | SN 0x01-0x0F->0x00-0x0F | N/A | N/A | N/A |
网络层时间控制分析
网络层定时参数定义了N_As N_Ar N_Bs N_Br N_Cs N_Cr六个参数。
网络层定制参数值及它们相应的给予数据链路服务的开始结束时间
Network layer custom parameter values and the beginning and end time and their corresponding to data link services
定时参数 | 描述 | 数据链路服务 | 超时 (ms) | 运行需求 (ms) | |
---|---|---|---|---|---|
开始 | 结束 | ||||
N_As | 发送方CAN帧发送时间(任何N_PDU) | L_Data.request | L_Data.confirm | 1000 | N/A |
N_Ar | 接收方CAN帧发送时间(任何N_PDU) | L_Data.request | L.Data.confirm | 1000 | N/A |
N_Bs | 直到下一个流控制帧(FC)接收的时间 | L_Data.confirm(FF) L_Data.confirm(FC) L_Data.indicate(FC) | L.Data.indicate(FC) | 1000 | N/A |
N_Br | 直到下一个流控制帧发送的时间 | L_Data.indicate(FF) L_Data.confirm(FC) | L_Data.request(FC) | N/A | |
N_Cs | 直到下一个连续帧(CF)发送的时间 | L_Data.confirm(FC) L_Data.indication(CF) | L_Data.request(CF) | N/A | |
N_Cr | 直到下一个连续帧接收的时间 | L_Data.confirm(FC) L_Data.indication(CF) | L.Data.indicate(CF) | 1000 | / |
S 发送者 R 接收者 |
网络层在检测到错误的时候应传递何时的服务项至服务的使用者
- 当
N_As
超时时,即发送方没有及时发送N_PDU
,系统将放弃信息的接收并传递<N_Result>=N_TIMEOUT_A
的N_USData.confirm
指示 - 当
N_Ar
超时时,即接收方没有及时发送N_PDU
,放弃信息的接收并传递<N_Result>=N_TIMEOUT_A
的N_USData.confirm
指示 - 当
N_Bs
超时时,即发送方没有接收到流控制帧或在首帧前收到,或连续帧没有被接收方收到,放弃信息的接收并传递<N_Result>=N_TIMEOUT_Bs
的N_USData.confirm
指示 - 当
N_Cr
超时时,即接收方没有收到连续帧或之前流控制帧未被发送方收到,放弃信息的接收并传递<N_Result>=N_TIMEOUT_Cr
的N_USData.confirm
指示
在网络层传输的过程中,涉及到的具体时间超时参数见上表,以保证系统工作,定义超时的值应比运行要求的值大。
对上述信息总结归纳
N_As 超时:发送方没有及时发送N_PDU
N_Ar 超时:接收方没有及时发送N_PDU
N_Bs 超时:发送方没有收到流控制帧
N_Br 超时:接收方没有发出流控制帧
N_Cs 超时:即STmin,发送两个连续帧需要等待的最短时间
N_Cr 超时:接收方没有收到连续帧
定时参数 | 方向 | 解释 |
---|---|---|
N_As | 发送方→接收方 | 首帧和连续帧在数据链路层传播的时间 |
N_Ar | 接收方→发送方 | 流控制帧在数据链路层传播的时间 |
N_Bs | 发送方→接收方 | 接收方收到首帧时发出的ACK响应,与自己(发送方)收到流控制帧的间隔时间 |
N_Br | 接收方→发送方 | 自己(接收方)收到首帧,与自己开始发出流控制帧的间隔时间 |
N_Cs | 发送方→接收方 | 自己(发送方)收到流控制帧,或是连续帧送达时产生的ACK响应,与自己开始发出新连续帧的间隔时间 |
N_Cr | 接收方→发送方 | 自己(接收方)收到连续帧,到下一次自己收到连续帧的间隔时间 |
s 代表发送者的定时参数,r 代表接收者的定时参数 |