本笔记来自于ISO15765-3中文版2004，ISO14229-2,3英文版2012，恒润科技的CAN诊断基础。感谢以上资源！本笔记仅用于自己学习，供大家参考。如有错误及不足，请大家指正！
目录
15765-3协议基于14229-1，可以说是UDS在CAN网络中的实现。
后面发布的14229-3可以替代15765-3？是的，按14229-3里的网络模型里，应用层中已经不存在15765-3了，用的是14229-3。
14229-2定义了时间参数和具体的传输过程
14229-3定义了UDSonCAN的具体实现
15765-3中的OSI模型：
14229-3中的OSI模型：
14229-2将会话层单独出来，这个之前应该是在15765-3中，所以准确的说应该是15765-3被14229-2加14229-3所替代。
下述的几种通信会话方式需区别开：
a) 物理的通信在如下期间
1） 默认会话方式
2） 非默认的会话方式（扩展会话，编程会话）——需进行会话处理(保持在非默认模式时都需要进行处理，否则会跳回默认模式)
b) 功能的通信在如下期间
1） 默认的会话方式
2） 非默认的会话方式（扩展会话，编程会话）——需进行会话处理(保持在非默认模式时都需要进行处理，否则会跳回默认模式)
所有的情况下，都应考虑服务器通过否定响应消息（包括响应代码78 hex）请求增强响应时间窗口的可能性
定义在 ISO 15765-2 的网络层服务用于在客户端和服务器中执行应用层和诊断会话时序管理。
应用层定时参数定义
用于默认的诊断会话的应用层定时参数值应按照如下表 2 设置
P2can_server:对ECU接收到诊断请求报文后，发出响应报文的时间要求，最大值为50ms
P2*can_server:当ECU发送负响应代码为0x78的负响应后，到ECU发出响应报文的时间要求，最大值为5000ms（有的厂家自定义比这个值要小，可能是2000ms）
P2*Server_max 这个时间参数是在 ECU 给出 NRC 0X78 之后生效的，ECU返回 NRC 0X78，说明 ECU 当前处理能量不足，所以需要更长的反 时间，即 P2*Server_max。所以 P2*Server_max 通常比 P2Server_max 大很多。
🔺P 2CAN
参数被认为是所有系统网络设计参考延时，该延时通过网关及总线带宽加上安全系数（例如最坏情况的 50％）。最坏情况（客户机-服务器-客户机信息传输一个来回的必须得传送时间），基于系统的设计，并受以下因素的影响：
a) 包含网关的数量
b) CAN 帧发送的时间（波特率）
c) CAN 总线的使用情况
d) CAN 设备驱动使用方法（轮询方式还是中断方式）及网络层的处理时间
🔺P 2CAN
分为两个时间，一是客户机发送请求至服务器的时间，一是服务器发送应答至客户机的时间。
🔺P 2CAN = 🔺P2CAN_Req + 🔺P2CAN_Rsp
图 2 展示的是🔺P 2CAN组成的一个例子。
注意：为了简单描述定时参数，在以下所有的图中，假定客户机到服务器在同一个网络中。 所有的说明及附图按照时间顺序表述。
当诊断会话而不是默认的会话启动的时，需要按如下表3的会话层定时参数进行会话的操作
S3server的意思也就是说，在非默认会话模式中，ECU最多能保持5000ms，若收不到任何请求，就会跳转回默认会话模式，S3client是针对客户端的，在UDS诊断中也可以称为诊断仪，诊断仪需要在S3client时间内发送诊断仪在线（0x3E）
此外，当转换到非默认会话时，服务器可能会更改它的应用层计时P2CAN_Server和P2*CAN_Server，以达到一定的性能或补偿非默认诊断会话期间可能应用的限制。 非默认的诊断会话适用的定时参数在诊断会话控制应答信息中报告 。 当客户端在功能上启动一个非默认会话时，它将适应响应服务器的定时参数。
表4定义了客户机和服务器启动/重启其S3Client/S3Server计时器的条件。对于客户端来说，定期传输的功能性寻址 TesterPresent(3E hex)请求消息应该与循序传输的物理寻址TesterPresent(3E hex)请求消息区别开来，后者只在没有任何其他诊断请求消息的情况下传输。对于服务器，不需要区分不同TesterPresent (3E hex)的处理。此外，表4显示，S3Server定时器处理基于网络层服务原语，这意味着在接收到服务器不支持的诊断请求消息时，S3Server定时器也将重新启动。
在默认会话和任何非默认会话期间，客户端和服务器满足上述给定的时序要求所需的计时器资源应符合表5和表6的列表。在非默认会话期间，表6中给出的额外计时器资源需求适用于客户端和服务器。
客户机在功能寻址时可能是一对多的，所以功能寻址时可以只用一个定时器，但如果是物理寻址，则是一对一的通讯，每个通道都需要单独的定时器
服务器即ECU，只可能工作在一种会话模式，所以定时器只需要一个单独的。
详细定时参数说明
6.3.5.1 物理通信
6.3.5.1.1 默认会话下物理通信
图 3 描述了客户机和服务器在默认会话下物理地址请求信息定时的操作。
a 客户端上的诊断应用开始请求消息的传输，通过向网络层发送一个N_USData.req。网络层传输此请求到服务器。请求消息可以是单帧或多帧。
b 多帧消息的情况下，服务器端被指示请求的开始是通过网络层传来的N_USDataFF.ind。
c 请求信息的完成通过客户机 N_USData.con指示。当接收到N_USData.con，客户端启动它的P2CAN_Client计时器，使用默认重载值P2CAN_Client。P2CAN_Client计时器的值要考虑有车辆网络设计引起的延迟（跨网关通信、总线带宽等）。为简单起见，该图假设客户端和服务器位于同一网络上。
d 服务器通过 N_USData.ind 指示请求信息的完成。P2CAN_Server计时器启动。
e 服务器收到N_USData.ind后，要在P2CAN_Server 内开始响应消息。这意味着，在多帧响应的情况下首帧要在P2CAN_Server内发送，单帧响应的情况下单帧要在P2CAN_Server内发送。
f 在多帧响应的情况下，第一帧的接收在客户端中通过网络层的N_USDataFF.ind指示。当接收到首帧的指示，客户端停止它的 P2CAN_Client计时器。
g 如果完整的信息接收到，或者在接收过程中出现了错误，网络层最后都产生一个 N_USData.ind。在 单帧响应信息，通过单个的 N_USData.ind 指示单帧的接收。当接收到单帧的指示，客户端停止它的P2CAN_Client 计时器。
h 服务器通过 N_USData.con 指示响应信息的完成。
会话过程中，计时器的值大于预设值时，会引起额外操作。如：增强响应时序窗口、报超时错误
6.3.5.1.2 默认会话期间扩展了应答定时的物理通信
图 4 描述了默认会话期间客户机和服务器物理地址请求信息定时操作，及服务器请求扩展的响应定时（否定应答码 0x78 的处理）。
a) 客户端诊断应用层通过发送 N_USData.req 到网络层开始发送请求信息。网络层传递该请求信息至服务器。该请求信息要么以单诊的形式或多帧的形式。
b) 在多帧信息情况下，请求开始于网络层发送的 N_USDataFF.ind 通知服务器。
c) 请求信息的完成通过客户机 N_USData.con 指示。当接收到 N_USData.con 时，客户端使用默认重载值为P 2CAN_Client ，启动 P2CAN _ Client 定时器，该定时器的值应当考虑到车载网络设计上（通信网关， 总线带宽，等）所有的延时。为了简单化，该图假定客户机和服务器在一条总线上。
d) 服务器通过 N_USData.ind 指示请求信息的完成。 此时开启P2CAN_Server计时器
e) 服务器在接收到 N_USData.ind 指示时，要求在 P2CAN_Server 时间内开始回复信息。也就是说，在多帧回复信息条件下，首帧必须在 P2CAN _ Server时间内发送，对于单帧回复信息，该单帧必须在 P 2CAN _ Server时间内回复。
f) 服务器在给定的P2CAN _ Server时间内无法提供请求的信息时，它可以通过发送应答码为0x78 的否定应答信息请求扩展的定时窗。客户端接收到否定应答信息时，客户端网络层产生一个 N_USData.ind。 接收到应答码为 0x78的否定应答信息，客户端重置它的P2CAN_Client定时器，但使用的是扩展的重载的 P2*CAN_Client定时值。（定时时间延长）
g) 服务器在发送否定应答信息N_USData.con之后，要求在给定的扩展的 P2CAN _ Server （ P2* CAN_Server ） 时间内应答信息。如果在给定的扩展的 P2*CAN _ Server 时间内仍无法提供请求的信息，服务器则继续发 送应答码为 0x78 的否定应答。客户端使用的是扩展的重载的 P2* CAN_Client 定时值重置它的 P2CAN_Client 定时器。为了简单起见，图中只显示了一个应答码为 0x78 的否定应答信息。
h) 一旦服务器可以提供请求的信息（肯定的否定的应答，而不是应答码 0x78 的应答），它就启动最后结果的应答信息。
i) 在多帧应答信息情况下，客户机通过网络层N_USDataFF.ind指示首帧的接收。当接收到首帧时，客户机停止P 2CAN_Client定时器。
j) 如果完整的信息接收到，或者在接收过程中出现了错误，网络层最后都产生一个 N_USData.ind。在单帧响应信息，通过单个的 N_USData.ind 指示单帧的接收。当接收该单帧指示时，客户端停止P2CAN_Client 定时器。
k) 服务器通过 N_USData.con 指示响应信息的完成。
对于非默认会话模式，多了S3定时，客户端需要在通讯中间断发送诊断仪在线0x3E请求，服务器需要在进入非默认会话模式后开始计时，若没有合理的客户端请求，到达S3server时间后，退出非默认会话模式。具体的通讯图不再叙述。
出错处理
应用层以及客户机和服务器在物理通信、功能通信期间的会话管理出错的处理应当按照表 7、表 8。假定客户机和服务器都按照该部分15765协议进行应用层及会话层的定时处理。
7 网络层接口
7.1 概述
该部分的 ISO 15765 协议使用 ISO 15765-2 定义的网络层服务进行诊断信息的收发。本节定义应用层协议数据单元（A_PDU）到网络层协议数据单元（N_PDU）的映射。
注：网络层服务用于执行应用层和诊断会话管理定时(参见6.3)。
7.2 流控 N_PCI 参数定义
客户机Stmin参数不应该使用 0xF1-0xF9 的值。如果汽车制造商要求，这些Stmin参数值应由服务器支持。
7.3 信息发送的 A_PDU 到 N_PDU 的映射
应用层协议数据单元的参数按照下表 9 所示映射到网络层协议数据单元。它用于定义客户机/服务器诊断服务信息的请求/应答。
成功传输消息（N_USData.con）的网络层确认被转发到应用程序，因为应用程序需要它来启动这些操作，这些操作应在传输请求/响应消息（ECUReset、波特率更改等）后立即执行。
7.4 信息接收的 N_PDU 到 A_PDU 的映射
网络层协议数据单元的参数按照下表 9 所示映射到应用层协议数据单元。用于定义接收到 的诊断请求/应答的确认/指示。
网络层对接收到首帧 N_PDU (N_USDataFirstFrame.ind)时指示不直接到应用层，因为它仅仅用于应用层定时。因此没有 N_USDataFirstFrame.in N_PDU到 A_PDU 的映射的定义。
8 标准的诊断 CAN 标识
8.1 法规 OBD 的 11 位 CAN 标识
法规 OBD 的11位CAN标识也用于扩展的CAN诊断（例如功能请求CAN ID能用于功能地址
（0x3E）请求信息保持非默认会话处于激活状态。）
如果ISO 15765-4中指定的11位CAN标识符用于扩展的诊断，则适用以下要求:
a) ISO 15765-4 协议的网络层定时参数同样适用于扩展的诊断；
b) DLC（CAN 数据长度码）应当设置为 8 并且 CAN 帧应当包含 8 字节（未使用的字节也应
当填充）；
注意：ISO 15765-4 允许最大 8OBD 相关服务器，为 8 个服务器定义了 11 位 CAN 标识。
8.2 法规29位OBD的CAN标识
法规的29位CAN标识应按照 ISO 15765-2 说明的标准固定的地址格式，同样能用于扩展的诊断。
如果 ISO 15765-4 说明的29位的CAN标识在扩展的诊断中重新使用，适用如下要求：
a) ISO 15765-4 协议的网络层定时参数同样适用于扩展的诊断；
b) DLC（CAN 数据长度码）应当设置为 8 并且 CAN 帧应当包含 8 字节（未使用的字节也应
当填充）；
注：表中给出CAN标识符按照 ISO 15765-2 协议优先级信息使用默认的值(110)。见15765-2中的标准固定地址
8.3 扩展的诊断29位CAN标识
8.3.1 概述
本部分说明使用 29 位 CAN 标识的标准地址及路由的概念。主要使用了最流行的网络协议（IP）的握手机制。因此地址及路由的算法可用于不同子网位置的节点的通信及路由。
地址及路由的概念遵循如下的特征：
——网络结构最灵活的设计操作
——完全定制的网络及节点地址
——CAN 控制器硬件过滤特征通过分配合适的网络及节点地址优化。
——网关需要知道与它连接的子网的网络地址，而不需要所有子网成员的地址。
下面描述了 CAN 标识符结构的技术细节，包括地址，子网掩码。也包括了对路由及广播的算法的详细描述。
8.3.2 29 位 CAN 标识符结构
本文档描述的 29 位 CAN 标识符结构与如下协议是兼容的。有 ISO 15765-2, ISO 15765-3,ISO 15765-4 及 SAE J1939-21.因此 SAE J1939-21 定义的 29 位 CAN 标识结构中 25 位的编码（保留/扩展数据页）和 24 位编码（数据页）应当确定该 CAN 标识或 CAN 帧是 J1939 的还是 ISO 15765 的。这对汽车网络设计者根据他的需求及对 SAE J1939 和 ISO 15765 协议的使用，定制非诊断的信息及相关 CAN 标识是重要的。
8.3.2.1 SAE J1939 的 29 位 CAN 标识符结构
关于 SAE J1939 29 位 CAN 标识符格式见如下表 11
8.3.2.2 ISO 15765 的 29 位 CAN 标识符结构
表 12 显示了 ISO 15765 的 CAN 标识符结构与 SAE J1939 格式的区别。
25 位——SAE J1939 保留/扩展数据页，ISO 15765 使用扩展数据页
24 位——SAE J1939 数据页 ，ISO 15765 数据页
因此，ISO 15765 格式与 SAE J1939 格式的 29 位 CAN 标识能在同一个 CAN 总线上互不影响的共存。
8.3.2.3 优先级域
SAE J1939 定义的优先级域用于 CAN 总线的仲裁机制。由于 CAN 标识符不再能自由分配（源
地址和目的地址包含在 CAN 标识符中），CAN 信息优先级由发送者分配并间接由接收者分配。
存在８(000-111)种不同的优先级。
优先级６(110)分配至诊断请求信息／帧。
8.3.2.４ 扩展的数据页及数据页域
扩展的数据页及数据页位决定了使用哪一种29位的CAN标识。见表13编码的说明
8.3.2.5 服务类型（TOS）域
服务类型域用于表述一个节点不需要分配不同地址的情况下，分配不同项服务。因此，8种不同的服务类型能同时分配给单个的目标地址。不同服务类型的定义见表14
8.3.2.6 源地址
源地址包含发送实体地址。该信息保证了正确仲裁以及被接收者用于回复信息。源地址结构见 8.3.3 描述。
8.3.2.7 目标地址
目标地址包含接收实体的地址信息。这应是一单独节点，广播地址或通用广播。网关使用目标地址决定 CAN 帧是否应当路由到另外一条 CAN 总线上。该目标地址结构见 8.3.3 所述。
8.3.3 地址结构
8.3.3.1 概述
目标地址及源地址都编码在 29 位 CAN 标识符中，并且每个长度为 11 位。如下所示，字母 “X”和“Y”代表可变参数。
8.3.3.2 地址的定义
一个地址包含两个部分
a) 网络地址
网络地址部分包含第一个连续的位“X”地址并且决定了一个节点所在的网络。同一物理总线上的节点应当分配同一个网络地址。网络地址部分不应当将所有的位置为1.因此，最小的网络地址长度应为 2 个位。最大长度应为 9 个位因为因为至少需要 2 个位提供固定节点地址。最大的子网数量可根据如下计算：
2 ^x- 1（X 代表使用到网络地址的位的个数）
b) 节点地址
节点地址部分包含了地址中剩下的连续的位“Y”（Y=11-X），并决定了子网中具体的节点。在子网中应当是独有的。所有的位都置位 0 或 1 是不允许的。所以最小节点地址长度为 2 个位，最大为 9 个位。子网中最多节点个数根据如下公式计算：
2 ^x- 2（Y 代表使用到节点地址的位的个数）
分配给节点独有的地址应当存储在节点的内部存储器中。一个节点接收目标地址域为该节点地址的的信息。
表 15 展示了源地址和目标地址的一个例子。发送及接收节点不在同一个子网中
8.3.3.3 子网掩码
子网掩码为网络地址及节点地址分配。
子网掩码长度为 11 位（与地址长度一致）。子网掩码的值通过设置开始连续的位“X”为 1分配。将网络地址部分设置为 1，将节点地址的部分设置为 0.（见表 16 和表 17 发送与接收者的子网掩码的例子）
由于固定的子网掩码长度及一开始的连续的位“X”设置为 1，只有这些位置位 1 而不是所有位。因此需要一个短记号定义子网掩码。
每一个分配子网掩码的节点都应当存储在它内部存储器内。相同子网的节点分配相同的子网掩码
8.3.3.4 网络地址
节点的网络地址现在可以通过分配地址及子网掩码计算出来。见表 18 和19发送者和接收者的例子决定了网络地址。
为了描述子网掩码，网络地址及子网掩码按如下形式记录：
<网络层地址>/<短的子网掩码记录>
实例：
发送端子网：0x2C0/5
接收端子网：0x320/6
该信息被网关用来路由。
8.3.3.5 广播地址
8.3.3.5.1 通用广播地址（0x7FF）
通用广播地址允许在网络上所有节点广播信息。为了发送一个广播信息到整个网络，目标地址必须为 0x7FF(所有的位都设置为 1)。包含该目标地址的信息将会被所有网关路由。所有的网络节点都应当接收并处理地址为 0x7FF 的信息。
8.3.3.5.2 子网广播地址
子网的广播用于广播信息到特定子网上的节点。为了发送一条广播信息到某一特定子网上，该子网广播地址应当计算出来。通过将目标子网信息（网络地址及子网掩码）可实现。即将所有节点地址的部分设置为 1。见表 20 对于接收子网的子网广播的例子
子网广播消息通常由网关路由。
所有节点都必须接收到网络地址部分等于自己的网络地址部分的消息，并且在目标地址域节点地址部分的所有位都设置为“1”。
8.3.4 信息接收
每一个子网的节点都将 CAN 帧中目标地址与它自己的地址相比较。如果匹配的话，包含的信息就传递至 OSI 模型相邻的上层进一步处理。
网络路由暂时用不到，不看了。
8万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
