UDS学习1

1.UDS在ISO体系下的协议体系2.UDS 诊断是请求响应模式的否定响应码Tester 发出一个代表某项服务的请求报文给 ECUECU 进行处理后会返回一个代表反馈信息的响应报文给 TesterTester诊断仪—— 就是安装了 CAN 工具的上位机例如CANoe、CANTest、CANpro、BUSMASTER、TSMaster、……每一个请求有一个唯一的、代表一项服务的服务标识SID每一个响应有一个唯一的代表反馈结果的服务标识肯定响应Positive Response—— 服务标识为【请求的 SID 40】例0x10 请求 → 0x50 肯定响应否定响应Negative Response—— 服务标识固定为【7F】否定响应报文结构7F 原请求SID NRC错误码NRC否定响应码代表本次响应失败的原因NRC 为 78 比较特殊代表 ECU 正在处理中会稍晚一些返回响应可以在 Trace 窗口中查看发送的 UDS 请求和 ECU 返回的 UDS 响应的报文信息3.UDS中的寻址方式物理寻址功能寻址物理寻址和功能寻址指的是发送的诊断请求的ID到底是面向一对一的单个ECU的请求ID还是面向网络中的一对多的所有ECU的请求ID每一个ECU都有一个唯一的物理寻址的请求ID例如700 是 BCM 物理寻址的请求 ID、701 是仪表的物理寻址的请求 ID、706 是车机物理寻址的请求 ID当我们发送的诊断请求的 ID就是 CAN 报文的 ID为 701 时只有仪表会进行处理和发回响应网络中的所有 ECU 也会有一个相同的功能寻址的请求 ID例如主机厂设定 CAN 网络中所有 ECU 的功能寻址的请求 ID 为 7DF几乎所有主机厂设定的功能寻址的请求 ID 都为 7DF当我们发送的诊断请求的 ID就是 CAN 报文的 ID为 7DF 时这个网络中的所有的 ECU 都会进行处理和返回响应4.基于CAN总线的UDS诊断通信的网络传输层协议协议内容是规定在[ISO 15765-2]中的UDS的诊断服务报文应用层ISO 14229-1可以多达4095个字节当然也可能只有23个字节。那么一个UDS服务的请求或响应的报文转换位CAN发送的时候一帧CAN报文装得下也可能装不下。一帧CAN报文装得下的时候发送方程序就采用【单帧】模式发送一帧CAN报文装不下的时候发送方程序就采用【多帧】模式发送单帧发送的过程示意图多帧发送的过程示意图多帧发送的步骤i. Sender 发送 FF首帧到 Receiverii. Recevier 向 Sender 发出 FC流控帧流控帧用于指示 Sender 接下来该如何发送后续的连续帧包含以下三个字段FS流状态Continue To Send、Wait、OverflowBS块大小0 代表不限制发送块大小STmin发送连续帧之间的最小间隔时间ms、usiii. Sender 向 Receiver 发出后续的 CF连续帧CF 有递增的顺序号FF 后的第 1 个 CF 的顺序号从 1 开始递增递增到 F 后又从 0 开始下一轮递增如此循环往多帧的通信过程实例5.UDS报文的四种帧型的区分和格式● 基于 CAN 的 UDS 的一帧报文的组成如下○【协议数据单元】【协议控制信息】【数据】○PDU PCI DATA○【数据】的部分才是真正的14229-1协议中的 UDS 的服务数据UDS 诊断的请求和响应的数据【0】单帧Single Frame—— SF■协议规定单帧的第1个字节中的前半个字节固定为0● 例如03 22 F1 89 00 00 00 00 报文中第1个字节为03前半个字节为0所以是单帧■协议规定单帧报文中的前1个字节是协议控制信息PCI● 单帧报文的PCI中的后半个字节代表这个单帧中的数据DATA的长度字节数● 例如03 22 F1 89 00 00 00 00 报文中第1个字节03就是PCIPCI中的后半个字节是3代表这个单帧中的数据的长度为3个字节也就是PCI后面的22 F1 89数据DATA之后的任何字节都无意义算作补白经常使用00、AA、55作补白。【1】首帧First Frame—— FF■协议规定首帧的第1个字节中的前半个字节固定为1例如10 10 62 F1 89 44 65 76 报文中第1个字节10前半个字节为1所以是首帧。■协议规定首帧报文中的前2个字节是协议控制信息PCI●首帧报文的 PCI 中的后 3 个十六进制数字后 12 个 bit代表这次多帧传输过程中的数据DATA的总长度字节数例如10 10 62 F1 89 44 65 76 报文中前 2 个字节 10 10 就是 PCIPCI 中的后 3 个数字是 0 10代表这次多帧传输的数据的总长度为 16 个字节将 0 10 转为十进制算出来的。【3】流控帧Flow Control—— FC■ 流控帧是 Receiver接收方发送给 Sender发送方■协议规定流控帧的第 1 个字节中的前半个字节固定为 3例如30 00 14 00 00 00 00 00 报文中的第 1 个字节 30前半个字节为 3所以是流控帧■协议规定流控帧报文中的前 3 个字节是协议控制信息PCI其它的字节的都是补白■流控帧用于指示Sender接下来该如何发送后续的连续帧包含以下三个字段● FS流状态—— 流控帧中 PCI 的第 1 个字节中的后半个字节也就是上例中 30 00 14 中第 1 个字节 30 中的 0○ 0 —— Continue To SendReceiver 允许 Sender 发送后续的连续帧○ 1 —— WaitReceiver 要求 Sender 等一会等 Receiver 再发流控帧进一步的指示○ 2 —— OverflowReceiver 表示自己溢出了无法接收连续帧了不要再给 Receiver 发送后面的连续帧了● BS块大小—— 流控帧中 PCI 的第 2 个字节也就是上例中 30 00 14 中的 00○ 00 代表不限制发送块大小允许 Sender 将后续的所有连续帧全部发送出来○ 01~FF 代表允许 Sender 发送指定个数的连续帧如果没有发完就要继续等待 Receiver 再发流控帧。●STmin最小间隔时间—— 流控帧中PCI的第3个字节也就是上例中 30 00 14 中的 14○ 限制Sender接下来发送连续帧之间的最小间隔时间单位可能是ms或us○ STmin的值在 00 ~ 7F 之间表示 0127ms○ STmin的值在 F1 ~ F9 之间表示 100900us○ 其它的字节没有意义【2】连续帧Consecutive Frame—— CF■协议规定连续帧的第1个字节中的前半个字节固定为 2例如21 65 6C 6F 70 65 72 20 报文中第1个字节 21前半个字节为 2所以是连续帧。■ 协议规定连续帧报文中的前1个字节是协议控制信息PCI●连续帧报文的PCI中的后半个字节代表这个连续帧的顺序号例如21 65 6C 6F 70 65 72 20 报文中前1个字节21就是PCI后半个字节1代表这个连续帧的顺序号为1■连续帧的顺序号首帧后的第1个连续帧的顺序号从1开始然后递增到F后如果还有连续帧要发又从0开始递增。6.基于 CAN 总线的 UDS 报文的多帧通信的网络层的 6 个时间参数As、Ar、Bs、Br、Cs、Cr以上 6 个时间参数是网络传输层的多帧通信过程中的 6 个时间参数执行过程入下图.reqRequest —— 请求方向上层 → 下层主动发起.indIndication —— 指示方向下层 → 上层被动上报.conConfirm —— 确认方向下层 → 上层针对请求的回应一个数据帧发送流程.req发起请求组织一帧数据----.ind接收方收到指示----.con同时发送方监听总线确认消息被收到N_Br N_Ar就像你约朋友见面朋友说“我下楼走到地铁口需要 8 分钟”预期耗时。N_Bs就像你定的闹钟“我等 10 分钟还见不到人我就走”超时阈值。如果闹钟也定 8 分钟朋友稍微被电梯耽搁 10 秒你们就错过了。所以闹钟必须大于 8 分钟即留有 10% 余量这套系统才能在实际车上有干扰、有延时稳定跑起来。