UDS诊断

1、UDS定义:

        Unified Diagnostic Services,即统一诊断服务协议,是ISO-14229标准的一部分,是一种在汽车电子诊断系统使用的标准通信协议,广泛应用于车辆的控制单元(ECU)诊断、故障排除、安全访问、控制收发以及软件刷写。

2、UDS内容:

        UDS诊断由两部分组成:ISO-14229协议和ISO-15765协议

        ISO-14229协议主要负责应用层,它负责处理具体的诊断请求和响应,像控制ECU禁止收发数据、控制ECU进入编程模式、故障码读取。

        ISO-15765协议主要负责传输层,它定义了CAN总线的诊断消息结构、消息传输速率和数据传输方式。即如何将UDS的请求和应答打包到CAN帧中,如何控制数据传输速率不要太快。

        两者结合使用,即ISO-14229提供具体的诊断功能,ISO-15765协议为USD协议的诊断服务提供传输支持,确保诊断工具与ECU之前通信稳定,保证现代汽车的诊断功能更加高效、灵活,并能应对越来越复杂的车辆电子系统和服务需求。

3、UDS地址 

        以致远电子的ZCANPRO软件为应用,需要关注UDS地址,包括物理地址、功能地址、响应地址,主要是帮助理解如何通过CAN总线进行诊断信息的交换,

        物理地址:首先每个ECU在CAN总线中都有唯一标识符,通常是一个CANID,允许CAN卡在网络中访问特定的ECU。

        举例:假设有一个发动机控制单元(ECU),它的CAN ID是0x200,即ECU的物理地址就是0x200,当诊断工具(CAN卡)想访问这个ECU,工具将向CANID为0x200发送请求,以与该ECU通信。

        功能地址:通常指的是一组具有相同功能的ECU节点,这些节点不只有一个CANID,而是通过逻辑上的功能组播地址进行访问,即一个请求广播到所有相同功能的ECU节点,这些节点会对请求做出响应。这种常见于需要同时访问多个功能类似的ECU,节省多次单独请求的开销。

        举例:假设想要发送一个诊断请求,要求所有的车身控制单元(BCM)节点响应,所有的BCM节点在网络中共享一个功能地址,比如0x500,通过组播请求,CAN卡发送一个特定消息到0x500,所有车身控制单元会收到这个请求并作出响应。

        响应地址:指ECU返回的响应消息中的CAN ID,这个地址响应消息发送到哪个诊断工具(CAN卡)。

        举例:如果诊断工具的CAN ID是0x100,当它向0x200(发动机控制单元)发送请求时,ECU(0x200)会根据请求进行处理,然后将响应消息发送到0x100,即响应地址为诊断工具的CAN ID,用于确保响应正确的返回给发起设备。

4、请求诊断(Request)

        是用于与ECU进行通信的主要形式,诊断请求的结构:

        SID + Sub-function(可选) + Parameter(可选)

        SID(Service Identifier):服务标识符,用于指明所请求的服务类型,协议共定义26个标准的服务请求SID。

        Sub-function:子功能,用于进一步细分具体的服务类型,用以描述SID中定义的服务的具体意图。

        Parameter:请求中携带的参数,具体用于服务的执行,提供与诊断过程相关的详细信息

        除正常请求诊断外,ZCANPRO的【UDS诊断】功能还允许客户添加自定义服务与子服务。

【UDS服务编辑器】则是客户根据自己ECU的自定义功能,自行添加扩展。 

5、诊断请求流程:

  • 首先发送诊断请求:

              诊断工具(CAN卡)会根据车辆的总线协议,构建一个带有SID、Sub-function和参数的诊断请求消息,该消息将通过CAN总线发送到目标ECU。

  • 其次ECU处理请求:

                目标ECU接收到诊断请求后,会解析SID、Sub-function等内容,根据请求意图执行响应的操作,若请求包含参数,ECU会根据这些参数执行相关的诊断任务。

  • 最后发送响应消息:

                一旦请求处理完,ECU会生成一个响应消息,其中包含执行结果或诊断数据,并通过总线发送回诊断工具。

6、诊断响应(response)

        是ECU对收到的诊断请求的回应。响应通常可以分为两种类型:积极响应和消极响应,分别对应于请求是否成功或者遇到错误。

        积极响应(Positive Response):表示请求已经成功处理,ECU正常执行了诊断任务,并返回了相应的数据或操作结果。在协议中,积极响应消息的格式为:在请求的SID上加上0x40,也就是说ECU的响应消息中的SID值会在请求SID的基础上增加0x40.

        举例:请求的SID=0x10(诊断会话控制请求)时,ECU的响应会是SID=0x50(表示诊断会话控制请求的成功响应)

                请求的SID=0x22(读取数据)时,ECU的响应会是SID=0x62(表示读取数据请求的成功响应)

        消极响应(Negative Response):表示请求存在问题,ECU未能成功处理请求,通常是由于错误SID、无效参数或ECU无法执行请求的操作等原因,在协议中,消极响应消息的格式:[0x7f+SID][负响应代码],消极响应还会包含一个额外的负响应代码,用来指示出错的类型或原因。

        常见的负响应代码:

  • 0x11:服务不支持
  • 0x12:子功能不支持
  • 0x22:参数不合法
  • 0x31:请求超时

        举例:如果发出了一个请求SID=0x10(诊断会话控制请求),并且子服务超出了协议定义范围,例如子服务=0x0A,ECU会返回一个消极响应。即:请求:0x10 0x0A,那么响应为:0x7F 0x10 0x22。

7、响应超时

在ISO-14229诊断协议中,响应超时是指在规定的超时时间内,诊断工具没有收到对应的ECU响应,这个超时机制是确保诊断系统及时得到反馈的关键。

具体流程:

        CAN卡发出请求,例如 0x10(诊断会话控制)到指定的ECU地址(0x7B2),正常期望的响应是在超时时间内收到来自0x7B2的响应,并且该响应必须是对应请求的0x10的响应,响应可以是积极或消极,如果CAN卡在超时窗口内没有收到来自0x7B2地址的响应报文,无论积极或消极,都认为是发生了响应超时,当超时发生时,CAN卡会标记该请求为超时,并可以采取响应错误处理措施,比如重试请求或报告超时错误。

        举例:CAN卡发出请求:0x10 0x01(请求诊断会话控制服务)

                   目标地址:0x7B2

                    超时时间:500ms

        那么如果0x7B2在500ms内没有响应或返回错误的响应,CAN卡会判定请求超时

此外,除了响应超时,还有一种请求与响应的报错,就是“传输错误”

即CAN卡发出某个SID请求,ZCANPRO 界面回直接弹出日志“传输错误,请检查链路”

这种错误分为两种情况:

1、CAN卡发送失败

2、多帧情况下未收到流控帧

3、响应地址错误

排查方法:

1、CAN,CANFD节点之间的协议兼容

2、波特率

3、接线

4、CAN卡是否处于正常打开状态

5、接收设备是否回ACK应答

6、终端电阻

7、是否有干扰

8、UDS中的多帧传输(ISO-15765)

        对于大于CAN帧最大传输数据的PDU,需要使用多帧传输来处理,UDS协议中的多帧传输使用的是ISO-15765-2标准,它规定了如何将大的PDU分为多个帧传输。

PDU:就是在诊断通信中携带诊断信息的单元,对于CAN协议,PDU通常会被限制在8字节以内(标准CAN帧)。PDU包含了通信中的地址信息和诊断消息。

地址信息:用于标识ECU的地址,在CAN网络中,地址可以是节点的标识符(CAN ID)

诊断消息(数据字段):通常包括命令、响应、故障码、参数等

        那么多帧传输,是通过数据段首字节的第一个数字判断报文在传输过程中的角色以保持帧的顺序和正确性:

        首帧:数据段首字节的第一个数字为1,先发首帧试探接收方,并且包含总数据长度。

        连续帧:数据段首字节的第一个数字为2,发送方按接收方的流控要求进行多帧传输,如果没有发完内容,继续等待流控帧出现,直到全部发完为止。

        如果是单帧:数据段首字节的第一个数字为0。

        流控帧:数据段首字节的第一个数是3,是接收方回复当前每段可以发多少帧,每帧以什么间隔发送。

 单帧响应举例:

        06 50 01 00 32 00 C8 AA

        06:0表示单帧,6表示只有6个有效字节

        50:是响应服务的SID,表示这是一个积极响应

        01:是子服务号,表示具体的服务子类型

        00 32 00 C8:这部分即诊断的结果或数据字段

        C8 AA:表示填充字节,用来展位,确保帧长度对齐。

多帧响应举例:

    

 首帧:10 0D    1开头(前4位0001)是首诊,后面12位(00D)表示数据长度,即数据总长度为13个字节即后面将跟随13个字节的数据内容。首帧也会包含一部分数据即(2E F1 84 11 20 07),剩余数据会继续在后续的连续帧中发送。

连续帧:2开头,连续帧第一个为0x21开头,依次到0x2F之后,下一次又会从0x20开始循环,直到将所有的PDU内容全部发完,则填充无效字节,并停止发送。数据即(14 FF FF FF FF FF FF)

流控帧:3(4bit)开头+流状态(FS,4bit)+块大小(BS,8bit)+最小间隔时间(stmin,8bit),总共是三个字节有效内容。其他字节填充,30 08 14表示流控帧、继续发、最大连续发8帧,帧间隔时间20ms。

                FS流状态:0为继续发送,1等待,2过载溢出

                BS块大小:一次能传输的帧数,00表示无限制传输大小

                最小时间间隔:

 9、ECU刷新

ECU刷新功能主要是基于UDS诊断的”文件下载“服务实现的“固件升级”或“软件升级”或“软件刷写”功能,所以ZCANPRO中的ECU刷新可以理解为增强、细化了文件下载功能的UDS诊断。

且ECU刷新功能仅对CANFD型号的CAN卡开放,普通CAN卡不提供ECU刷新。

ECU刷新包括预编程、编程、后编程

预编程的环节需要操作的步骤:

1、0x10 0x03服务进入扩展会话模式

UDS的会话由默认会话、编程会话、扩展会话三种模式组成,各个会话下支持的服务不一致

默认会话模式通常用于诊断目的,而扩展会话模式则提供更高的权限,允许执行如编程、更新等高级操作,进入扩展会话,某些服务才会被启用。

2、0x31 服务器检查编程前提条件,检查系统是否满足进行编程或刷写的条件。

3、0x28服务 的0x03子服务关闭非诊断通讯,禁止与车辆之外的设备进行其他非诊断相关通讯。

4、0x85服务 的0x02关闭DTC(故障诊断)设置,在刷写之前清楚DTC是为了确保刷写过程不受已存的故障码影响,并确保车辆处于清洁状态,如果刷写过程中发生问题,也有助于避免产生误报。

上述消息即为了确保车处于安全可升级状态,也是为了优化当前通讯环境,确保升级不受干扰。 

编程环节步骤如下

1、0x10 0x02进入编程模式,作为初始化刷写过程的第一步,进入编程模式后,ECU的状态会变为允许进行编程操作,编程模式允许对ECU进行固件更新、数据擦除、存储区写入。

编程模式与编程会话的区别:

编程模式是ECU的一种特殊状态,启动方式是发送特定的(0x10 0x02),开启后会对来自刷写工具的编程请求做出响应,并在刷写操作结束后关闭,ECU会恢复到正常工作模式。

编程会话是指在编程模式下,实际的刷写过程,包括从开始刷写、数据传输到刷写完成整个过程。编程会话会在刷写操作完成后结束,并且通常有一个退出操作(0x31退出传输会话),ECU恢复到正常工作状态。

2、ECU解锁,加载安全访问算法DLL

ECU解锁:是指ECU必须接收来自外部的编程请求,通常需要通过安全访问算法来完成

此时客户端需要加载一个DLL(动态链接库)以确保安全的访问过程。,通过加载正确的安全访问算法DLL,确保刷写过程安全性,防止未经授权的程序访问或修改ECU数据。

3、0x2E服务 进行数据写入。该步骤可以按标识符写入数据到ECU,并记录刷写者身份

4、0x31 + 0x34 + 0x36 + 0x37服务进行擦除内存或下载文件

0x31:诊断服务,用于对ECU进行访问

0x34:擦除内存。通常是为了清空ECU旧的数据或固件,准备好接收新的数据

0x36:下载文件,此步骤涉及将新的固件或配置文件下载到ECU

0x37:编程,该操作将新的数据写入ECU的特定内存区域

5、0x31服务进行CRC校验,是为了确保数据的完整性,检查传输的数据是否有错误,确保刷写数据没有在传输过程中发生损坏。

6、0x31服务退出传输,意味着刷写操作已经完成,ECU编程操作结束。关闭ECU编程会话,确保ECU回到正常工作模式。刷写数据已经生效。

 后编程环节

        只需要让ECU复位,观察ECU状态即可

        0x11 0x01:复位ECU

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值