UDS——概述

目录

一、前言

二、诊断模型

三、诊断流程

四、诊断服务SI


一、前言

之前有篇博文刨根问底VS浅尝而止,本着了解知识由浅入深,先宏观再深究,先应用再具体的原则来总结UDS的内容。UDS(Unified Diagnostic Services,统一的诊断服务)诊断协议是在汽车电子ECU环境下的一种诊断通信协议。

二、诊断模型

应用层:诊断服务的具体实现,用于tester/client发出诊断请求,server(MCU)根据请求做出不同响应

网络层:中间层,是数据转换的桥梁,包括多帧数据传输,进行数据的打包、拆包,协调上下层工作;还包括对等实体间的通信,数据同步,时间管理,错误管理。

数据链路层:CAN 总线(ISO 11898-1)最初指定的链路层协议仅包括对物理层的抽象需求,ISO11898-1-2015指定了经典CAN帧格式和新引入CAN-FD帧格式。 高速物理层关于电气方面的(电压,电流,数量导体)规定来自于 ISO 11898-2,该协议目前被广泛接受;低速则在 ISO 11898-3 中。但是,物理层关于机械方面的(接头种类和数量、颜色、标签、标准输出)并没有标准文档来正式指定。

物理层:传输所需要的硬件条件,包括收发器,终端电阻,双绞线,距离限制,尺寸;哪些传感器的CANH和CANL连接到网络上,不同速率网络通信需要网关等。

三、诊断流程

客户端(client)/诊断仪(tester):发送诊断请求者(读写数据,启动例程)

服务器(server/ECU):诊断响应的提供者-ECU发送诊断响应(正响应、负响应)

远程诊断(Remote diagnosis):客户端和服务器不在同一个网段

服务函数:

请求request:诊断仪对ECU发送请求

请求_确认req_confirm:当请求被成功收到之后,诊断仪会调用req_confirm表示“请求已经正确的发送成功”

指示indication:ECU收到请求后会有一个指示(回调)告诉ECU上层“收到一个诊断请求”

响应response:ECU对请求处理完之后,会有返回一个响应

响应_确认rsp_confirm:诊断仪收到响应之后,ECU会触发rsp_confirm,表示响应发送成功

确认confirm:当响应发到网络被诊断仪接收到之后,诊断仪会有一个确认confirm(回调),表示已经处理完请求

服务分为两类有确认服务和无确认服务:

有确认服务:

无确认服务:

诊断的流程:

UDS应用层服务原语格式描述:

service_name.type (
parameter A, parameter B, parameter C
[,parameter 1, …]
)

  • “service_name” is the name of the diagnostic service (e.g. DiagnosticSessionControl),
  • “type” indicates the type of the service primitive (e.g. request, indication,response, confirm, req_confirm and rsp_confirm),
  • “parameter A, …” is the A_SDU (Application layer Service Data Unit) as a list of values passed by the service primitive (addressing information),
  • “parameter A, parameter B, parameter C” are mandatory parameters that shall be included in all service calls,
  • “[,parameter 1, …]” are parameters that depend on the specific service (e.g. parameter 1 can be the diagnosticSession for the DiagnosticSessionControl service). The brackets indicate that this part of the parameter list may be empty.

四、诊断服务SI

(1)首先看下具体有哪些服务

(2)在默认会话和非默认会话支持的服务

五、总结

        ISO 11898是CAN总线的规范,对应于OSI是层一和层二,即物理层和数据链路层。对于物理层来说,定义了CAN总线信号在双绞线上的电压形式,对于数据链路层来说,定义了CAN帧的各个域的用途。

        ISO 15765-2是诊断服务在CAN总线上传输的实现方式,对应于OSI是层4,传输层。对于classical CAN总线来说,它一帧只能承载8个字节,而上层的诊断服务却可能超过8个字节,这时候就需要传输层对数据进行分包重组流控制。ISO 15765-2还定义了应用层、传输层、数据链路层之间的编程接口,其实就是request, confirm, indication这几个原语的定义。ISO 15765-3和ISO 14229-3的内容是一样的,后者取代了前者。ISO 15765-4定义了基于CAN总线实现OBD通信的方式。

        ISO 14229-1 对应于OSI的层7,即应用层,它定义了诊断服务的格式。ISO 14229-2定义了诊断会话中的各种时间参数,比如ECU的响应时间等。ISO 14229-3 一直到ISO 14229-7 分别定义了UDS在CAN,FlexRay, Internet Protocol ,K-Line ,LIN上的实现要求 。

        这三部分协议一起使用,就可以实现完整的诊断功能了。总结来说,ISO 14229-1生成诊断服务,ISO 15765-2对诊断服务进行分包并把分包后的数据交给ISO 11898,ISO 11898给收到的数据加上CAN总线特有的包头和包尾,然后通过双绞线以电压差的形式发送出去。

参考:

UDS入门:UDS诊断 入门学习备忘录_JawSoW的博客-CSDN博客

CAN 总线 之三 CAN 国际标准 ISO 11898 解读:CAN 总线 之三 CAN 国际标准 ISO 11898 解读_ZC·Shou的博客-CSDN博客_iso11898

https://www.zhihu.com/question/303256393/answer/542832019

UDS应用层服务原语格式描述_microcosmv的博客-CSDN博客_uds服务原语

  • 7
    点赞
  • 48
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值