本文是对 ISO 15765-2-2011 协议的一些解读。
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 协议由此诞生。
15765-2作为车辆诊断通信的一个组成部分，规范了“传输协议和网络层服务”。
看下目录：
0 前言与简介
1 适用范围
2 规范性参考文献
3 术语、定义和缩写术语
4 约定
5 文档概述
6 网络层概述
7 网络层服务
8 传输层协议
0 前言与简介
ISO 15765-2的第一版为ISO 15765-2：2004。ISO 15765的中文含义为道路车辆 - 基于CAN网络的诊断通信（DoCAN），整套协议由以下部分组成：
- 第一部分：一般信息和用例定义
- 第2部分：传输协议和网络层服务
- 第3部分：统一诊断服务的实施（CAN上的UDS ）
- 第4部分：与排放有关的系统的要求
1 适用范围
ISO15765-2 可以但不限于与ISO 14229-1和ISO 15031-5一起使用，它与车载网络的大多数其他通信需求相兼容。
2 规范性参考文献
ISO / IEC 7498-1，信息技术 - 开放系统互连 - 基本参考模型：基本模型
ISO 11898-1，道路车辆 - 控制器局域网（CAN） - 第1部分：数据链路层和物理信令
3 术语，定义和缩写术语
6 网络层概述
网络层最主要的目的就是把数据转换成能适应CAN总线规范的单一数据帧，从而进行传输。如果将要传输的报文长度超过了CAN数据帧的长度，则需要将报文信息进行拆分后传输，每次至多可以传输4095个字节长度的报文。
所有的网络层服务都具有相同的通用结构。为了定义这种服务，需要定义三种类型的服务原语：
A. 请求服务（Request）：用于向网络层传递控制报文信息及要发送的数据，应用于更高层或应用层。如tester向ECU发出数据。
B. 指示服务（Indication）：用于向更高层或应用层传递状态信息及接收到的数据，应用于网络层。如ECU收到了tester的数据，传至应用层。
具体说来，Indication前端应该执行的是底层传入数据的处理函数，即读取PDU信息，这一帧具体是SF、FC、CF还是FF。若满足条件，继续向上，即应用层传递。
C. 确认服务（Confirm）：被网络层使用，用于向更高层或应用层传递状态信息。如tester收到了ECU方面的数据。
具体说来，Confirm和Indication很像的是都是从网络层向应用层传递信息，有何区别呢？
在代码的处理中，Confirm的前端应向底层外发Tx数据或超时处理函数，反馈的信息不需要包含数据。而Indication传递的信息则分为两种，一种包含真实数据，另一种不包含。
7 网络层服务
这一章要注意一个知识点，7.3.2.4中提到，对于物理寻址（Physical addressing）需要被所有的报文类型所支持；而对于功能寻址（Functional addressing），只能被单帧所支持。
8 传输层协议
这一章一开始就重申了TP层的意义之所在：
使收发的数据帧所包含的字节总数，扩容到4095个字节。
不管发送或接收是成功或是出错，都需要上报给应用层。
8.4 网络层协议数据单元 N_PDU
网络层协议数据单元（N_PDU，Network_Protocol Data Unit）包含N_AI，N_PCI，N_Data。即地址信息，协议控制信息和数据。
注：这里的N_PCI全称为Protocol Control Information。
网络层协议数据单元（N_PDU）有四种类型，即单帧（SF）、首帧（FF）、连续帧（CF）、流控制帧（FC），用于建立对等实体间的通信。
8.5 N_PCI
网络层对于这四种类型的数据单元是通过协议控制信息（N_PCI，Protocol Control Information）进行区分的。每一个N_PDU都只有一个N_PCI。
也就是说，对于CAN诊断来说，我们完全可以通过识别每条CAN帧数据域的首个字节来确定它属于四种类型中的哪类。
N_PCI是TP层最为核心的信息，是TP层区别于其他CAN总线抽象协议的、最为显著的特征。
以下说明仅以乘用车常用的常规寻址举例。
对于TP层来说，我们可以把报文分为单帧和多帧，单帧只有一种N_PCI，即单帧；多帧有三种N_PCI，即首帧、流控制帧、连续帧。代码实现中，主要的工作其实就在多帧的处理和对超时错误（Timeout）的处理上。
0X 单帧（SF，Single Frame）：首个字节为0（4bit）+ Data Length(4bit)，控制信息占用1个字节
举例：Data 02 10 02 55 55 55 55 55，02表示接收方应知晓，这一个单帧只有2个有效字节。后续的字节是自动填充的无效字节。
单帧PCI通常仅占用1个字节，其他是数据，所以可以后面可以跟着最多7个字节的数据1X XX 首帧（FF，First Frame）：前两个字节为1（4bit）+ Data Length(12bit)，控制信息共占用2个字节。
举例：Data 10 14 2E F1 90 01 02 03，0x014表示，接收方应知晓，这一个多帧组合共有20个字节。
首帧可以携带一个多帧报文的头部6个字节数据3X 流控制帧（简称流控帧，FC，Flow Control）：前三个字节为3（4bit）+流状态（FS，4bit）+块大小（BS，8bit）+最小间隔时间（STmin，8bit），控制信息共占用三个字节。
举例：Data 30 00 14 AA AA AA AA AA，多帧发送方应知晓，这是一个流控帧，允许你方继续发送，CF数量无限制，上一个连续帧的确认接收（ACK）到新的连续帧开始发出的最小间隔时间为20ms。
Flow State 流状态：0为继续发送，Continue To Send（CTS），1为Wait（WT），2为Overflow（OVFLW）。
流控帧仅有3个字节的控制信息，无数据字节
STmin含义的解读间隔最短时长（STmin）值的含义如下。
2X 连续帧（CF，Consecutive Frame）：第一个字节为2+SN（最多16个SN，溢出后从0开始重新计数），控制信息占用1个字节。
我们通常记首帧为0x20，之后的第一个连续帧自然是0x21，之后一直到0x2F，下一个是0x20，循环。
一个连续帧最多可携带7个数据字节下图是一个传输规则的例子。可以看出，这首先是一个多帧传输，下列CAN帧依次代表的含义是首帧、流控、连续帧、连续帧。
FF-FC-CF-CF
实际截取到的多帧报文下图是N_PCI字节的概要。N_PCI在不同的类型下占用的字节数是不同的。记忆时可以按照单帧、首帧、连续帧、流控的顺序，与0、1、2、3建立映射关系。这四种类型所占用的字节大小依次是1个、2个、1个、3个。
网络层内部传输服务
网络层的主要任务是传递一帧或大于一帧的数据信息。以下是一个被拆分的信息传送的例子。
帧的发送主要有单帧发送和多帧发送两种，在标准地址情况下，单帧SF按照N_PDU格式最多发送和接收7个字节数据（因第一个字节为N_PCI）。
而发送长报文信息时，拆分后的报文信息会通过多个N_PDU进行发送，接收到多个N_PDU信息后进行重组。这些N_PDU包括首帧和连续帧。报文信息接收者可通过流控机制按照自己的接收能力调整传输流量。在正常地址的情况下，一个首帧PDU包括6个字节，一个连续帧PDU包括6或7个字节。当然最后一个连续帧可以少于6或7个字节。
8.7 网络层时间控制分析
网络层定时参数定义了N_As、N_Ar、N_Bs、N_Br、N_Cs、N_Cr六个参数。
多帧传输时序表，划重点
我们对上述信息进行归纳：
N_As超时：发送方自己没有及时发出首帧或者连续帧。
N_Ar超时：接收方没有及时回复流控帧。
N_Bs超时：发送方没有接收到流控帧。
N_Cr超时：接收方没有收到连续帧。
N_Br超时：接收方没有发出流控帧。
N_Cs：即STmin，发送两个连续帧需要等待的最短时间。
与外卖的对比（按时间先后顺序排序，并不完全准确，请意会）
N_As：外卖小哥拨出电话到外卖小哥听到第一声“嘟”的时间。（虽然短，但的确有这个时间）
N_Br：你听到手机铃声，直到你说完“放在301门口”这句话。（注意包含了你大脑处理信息的时间）
N_Bs：外卖小哥听到第一声“嘟”到外卖小哥听到你说的“放在301门口”这个信息的时间。
N_Ar：你说出“放在301门口”这句话到外卖小哥听到“放在301门口”这个信息的时间。（虽然短，但存在）
N_Cs：外卖小哥听到“放在301门口”这个信息到外卖小哥说完“疫情期间进不了小区！”的时间。（包含了外卖小哥思考的时间）
N_Cr：你说完“放在301门口”这句话以后咽了口吐沫，到你听到了外卖小哥说“疫情期间进不了小区！”的时间。（咽吐沫的时间是N_Ar，想说明N_Cr不含N_Ar）
N_As：外卖小哥说完“疫情期间进不了小区！”这句话到你听到“疫情期间进不了小区！”这句话的时间。（虽然短，但存在）
由此我们可以看出，N_Bs近似等于N_Br+N_Ar；N_Cr近似等于N_Cs+N_As。
8.7.2 网络层超时处理
版权声明：本文为知乎「心机之花」的原创文章，已获作者发表许可。
推荐阅读
CAN设计与应用指南
汽车软件需求是如何变成用户功能？
电子电气架构设计需要考虑哪些方面？
汽车E/E架构的网络安全分析
电子电气架构设计需要考虑哪些方面？
一文搞懂AUTOSAR的DEM模块深度解读汽车域控制器分享不易，恳请点个【👍】和【在看】
