UDS

最新推荐文章于 2025-04-11 16:21:09 发布

CiRyan

最新推荐文章于 2025-04-11 16:21:09 发布

阅读量6k

点赞数 3

分类专栏：诊断

本文链接：https://blog.youkuaiyun.com/qq_25126391/article/details/108936200

版权

诊断专栏收录该内容

1 篇文章

订阅专栏

UDS(ISO 14229-1&ISO 15765-2)

U 可以基于任何总线

VIN :车辆识别号，是主机厂对一辆车的唯一标识码，是在下线检测的时候写入到ECU当中

诊断的作用：读取软硬件版本号，故障检测，程序升级刷写，下线检测，IO控制（比如雨刮器的耐久测试）

UDS 定义了一种C/S架构的诊断响应机制

OBD: 与排放相关的，可支持CAN LIN K ，主要与法规相关

UDS是应用层协议，与底层的通讯介质不相关，所以可以在任何形式的通讯介质上实现

UDS 也是参考ISO 七层网络协议模型：每一层都有对应的标准，比如物理层是ISO11898-1/ISO11898-2；网络层和传输层中是不同通讯协议的标准，比如ISO15765-2是基于CAN的传输协议，ISO17987-2是基于LIN的协议

14229 一共有6个部分

ISO 14229-3 是基于CAN的UDS

UDS 与OBD的关系：

OBD是在15031-5中定义的排放相关的服务，UDS是14229-1中定义的通用服务
两者都依赖15765-2中定义的网络层和14229-2中定义的会话层
一个ECU中是可以共存OBD与UDS的，两者各司其职
Unified: 可以实现任何通讯方式的诊断
1. 原因：网络层，传输层和会话层之间的T_PDU（虚拟PDU）
2. T_PDU 是A_PDU与任何通讯方式PDU之间连接的接口

D 诊断通讯协议

本地客户端和本地服务器：如果Client和Server 的具有相同的本地网段，就是说CAN id 的开头一样
远程客户端和远程服务器：一般是在有网关的网络中会涉及的，通过远程地址进行标识
PDU: 是信息（PCI）和数据（data）组成，在通讯中一般都会涉及到PDU, UDS中每一层都有对应的PDU

协议控制信息PCI
data

对等实体：以软件，硬件或者软硬件的任意组合实现的每层活动部分
寻址方式：

物理寻址：比如软件刷写
功能寻址：同时连接几个ECU 进行DTC的清楚

地址：地址与报文ID 有关，诊断报文ID =基地址+节点地址，功能寻址一般为特定ID:0x7DF

源地址：
目标地址：

6种服务原语（了解即可，底层ECU开发不需要关心这部分的实现）
1. 服务请求原语（开始发送给诊断请求）
2. 服务请求确认原语（诊断请求发送完成） 内部有A_Result数据：枚举类型，表示是否正确传输
3. 服务指示原语（ECU请求消息收到，开始处理诊断请求）
4. 服务响应原语（ECU处理结束，开始向tester发送，响应报文）
5. 服务响应确认原语（ECU发送响应报文结束）内部有A_Result数据：枚举类型，表示是否正确传输
6. 服务确认原语（tester 接收响应报文成功确认）
原语格式：
1. A_MType：本地诊断还是远程诊断
2. A_TA_type: 物理还是功能
3. A_AE只是针对于远程诊断方式的
A_SDU与A_PDU的关系
1. 应用层服务A_SDU是通过服务原语进行传递到A_PDU的，原语将诊断应用程序中发出的诊断服务需求，转换成A_PDU
2. 对等实体间就是通过对应的PDU进行传递的
3. A_PDU = A_PCI +A_SDU
A_PCI （应用层协议控制信息）根据A_PCI参数的第一个字节是否为0x7F分

A_PCI (SID) ：请求服务和肯定响应，一个字节无符号整数
A_PCI （NR_SI, SI）：否定响应

SID(服务标识符)
1. 0x00-0xFF 之间，但是其中部分保留了，可以让供应商或者主机厂自定义的字节
2. 14229-1的部分，目前定义了26个服务类型
3. 对于请求服务，第六个bit为0，相对应的返回的肯定响应标识符第6个bit为1，此为他们的对应关系，即肯定响应SID =请求的SID+0x40
4. 肯定响应NR_SID =0x7F 固定
5. NRC :返回错误的原因，NRC 可以直接查询14229-1附录就是了
诊断三要素：

请求
肯定响应
否定响应

A_PDU
1. Cvt: convention; M： mandatory, C：conditional（基于某一些标准的），S: selectonal(可选的)，U: User optional(用户自定义)
2. 子功能（SF）:带子功能（S）; 不带子功能（U）
3. SF ：一个字节；子功能参数范围0x00-0x7F： 0-127
  
  第7位决定了是否需要发送肯定响应消息
  1. A_PDU处理过程
    
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NUsTLbXy-1601947004780)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509072247357.png)]

S 服务

常用的6类服务

UDS中定义的服务一共6类26个，下面定义一些常用的服务

1. 诊断和通信管理功能单元

0x10 DiagnosticSessionControl

三种诊断会话
1. 默认诊断会话：ECU一般刚上电，冷启动，软件复位进入的状态，是比较安全的状态，通过0x10 01 让ECU进入此会话，安全锁定状态
2. 非默认诊断会话
  - 编程会话：用于重新编程即软件刷写的状态，主编程环节 0x10 02
  - 扩展诊断会话：ECU刷写的预编程环节, 0x10 03
注意：不同的诊断会话具有不同的功能和定时参数；一般来说非默认会话基本能够支持比较多的服务，默认会话能够支持的服务比较有限

注意：不能由默认会话直接跳转到编程会话的，只能有扩展会话跳转到编程会话，如果在默认会话中发送跳转到编程会话的请求是，ECU会回复NRC7E
会话超时-定时器S3
1. 在非默认会话中保持的时间是可以设置，一般默认P2=50ms, P2* = 5000ms
2. 问：P2和P2*是什么意思？
  - P2–从ECU收到请求消息到发送响应消息之间的时间
  - P2*–从ECU发送了NRC为0x78的否定响应消息到开始发送下一个响应消息
  - [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-x54XtmD6-1601947004782)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200528102453424.png)]
    
    S3server 的时间是确认从PDUR中接收到数据之后开始计时的
3. 通过0x3E服务可以请求不要断开非默认会话
4. 一般用于软件刷写中
0x10 服务
1. SF 0x00-0xFF
2. NRC
诊断描述文件（cdd）
1. 在dependency中可以看到会话切换的转换图
有时候在功能寻址过程中为了减少总线负载，如果不想所有的ECU都发送肯定响应，则需要应用SF中的一直肯定响应消息位如 0x10 83

0x27 SecurityAccess

四个步骤

请求，2n-1表示安全等级，如果请求时已经解锁，则直接返回位为全0的肯定响应，表明已经处于解锁状态
ECU返回种子，随机数，种子的字节长度由OEM自定义
Tester通过种子,再根据种子安全等级与范围，计算一个密钥key1
ECU 通过key1 计算Key2, 如果Key1 =Key2 则解锁
ECU返回解锁消息
- 0x27 可以实现不同安全等级切换，但是在任意时刻只能有一个安全等级
- 编写cdd文件时，种子字节、安全等级、密钥数据类型都可以自定义，创建好的安全等级可以在state groups中查看
- 常见8个NRC
不同安全等级之间的关系

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AaoBNnrz-1601947004785)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200529164400912.png)]
- 不同安全等级之家可以是相互独立的也可以是有依赖关系的，比如说要先解锁了安全等级1之后才能进入到安全等级3
- 从解锁状态跳转到锁定状态的几种方式：
  1. 接收了$11服务，ECU重新复位了
ECU重新上电了
1. 接收了$10会话切换功能

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BRd6QeKH-1601947004787)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200806163112407.png)]

0x28 CommunicationControl

可以打开或者关闭某些消息的发送/接收
1. 0x28 01

0x3E TesterPresent

测试工具保持连接服务
用于保持诊断仪与ECU的连接，同时将之前的服务和状态保持，,不会因为超过P2*的时间限制重新切换到Default Session
0x3E 80使ECU保持在扩展诊断会话模式

0x85 ControlDTCSetting

用于停止或者恢复单个服务器或者一组服务器中DTC状态记录
1. 0x85 01 正常记录
2. 0x85 02 停止DTC更新

以下诊断服务用得相对于上面的少一些

0x11 ECUReset

请求ECU执行复位
如果需要回复复位的肯定响应，那么肯定响应一定要在复位执行之前返回
复位之后直接进入默认会话

0x83 AccessTimingParameter

读取和修改通讯链路的实时参数
暂时不支持

0x84 SecuredDataTransmission

保护数据传输免遭第三方攻击

0x86 ResponseOnEvent

启动/停止服务器中某个特定事件触发的响应

0x87 LinkControlu

控制客户端和服务器之间的通信，以便获取诊断目的的总线带宽

问题：怎么编写CDD文件

2. 数据传输功能单元

读取ECU内的数值，如软件版本号，VIN, 车型配置等

读写数据的个数规定上限为4095

0x22 ReadDataByIdentifier

根据DID读取数据
1. 模拟量输入输出
2. 内部数据
3. 系统状态信息
DID规范见14229附录，一次请求可以发送多个DID，每一个DID都是双字节无符号数
1. 比如读取VIN的DID就是0xF190，VIN号一共是17个字节
2. 比如DID=0x010A 返回发动机冷却液温度、节气门位置、发动机转速、歧管进气压力、怠速控制等等
3. 比如DID=0x0110 包含电池正电压
4. ISO对于DID的取值范围做了划分，具体DID代表了什么/多少数据、格式就需要OEM/Supplier制定
5. 不同的DID需要不同的服务支持

0x2E WriteDataByIdentifier

和读取消息类似，只是过程相反
写入的一般都是
- 非易失存储器中的数据
- 可标定的参数
- 车辆的配置信息
否定NRC
示例
1. 通过F190写入VIN号，同上相反

3. 传输储存的数据功能单元

0x19 ReadDTCInformation

一共28种子功能，常用的有4种
1. 0x02 最常用 SM（StatusMask）表示掩码; SAM（StatusAvailabilityMask）表示返回的可用掩码
  
  注意:SAM是通过SM与ECU内部的现有的DTC的状态进行&计算，筛选出非0的所有的DTC
  
  所以一般状态掩码与DTC的状态码的定义类似
2. 0x04 快照数据，也就是故障发生时候的环境数据
  - ECU每发生一次故障，记录一次DTC，都会记录一次snapshotData，主要作用是帮助分析发生故障的主要原因
  - 分为
    1. 全局快照（必须）
      
      一般包括：
      
      供电电压
      
      里程数
      
      电源模式
      
      日期
      
      时间
      
      冷却液温度
    2. 局部快照（可选）：全局快照信息的补充
  - 比如：
    
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ugkblX6K-1601947004789)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509103311366.png)]
3. 0x06 扩展数据—服务执行时的环境数据
  - 扩展数据信息是一组提供诊断故障代码相关扩展状态信息的数据组，一般包括
    1. 包括故障出现计数器-记录的次数
    2. 故障待定计数器-记录的次数
    3. 已老去计数器-记录的此时
  1. 老化计数器-记录的次数
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5bOTVFus-1601947004789)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509103655505.png)]
4. 0x0A 读取所有的DTC，返回ECU内目前记录的所有DTC

0x14 ClearDiagnosticInformation

3个字节的DTC组是用于选择DTC组的掩码，group对应着车身、动力总成、车身、地盘等
清除完成之后，返回肯定响应，即使没有DTC，同样发送肯定响应
清除所有DTC
清除某一个DTC: 后面直接跟DTC的具体数值就行了

4. 输入/输出控制功能单元（I/O控制）

0x2F InputOutputControlByIdentifier

替换服务器输入信号的值或者内部功能
控制电子系统的某个输出（某个执行器）

5. 远程激活例程功能单元

远程控制，让ECU启动、停止或者执行一段特定的序列，并返回其结果

又同步和异步两种方式

例程：执行特定序列并或者相关的输出结果，比如，ECU上电的自检、ECU存储器擦除、调整电机的零位角度,可以把例程视为一段比较复杂的逻辑程序。

0x31 RoutineControl

三个步骤
1. 开始例程 0x31 01
2. 请求例程结果 0x31 03
3. 停止例程 0x31 02
  
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-a5ezRdCS-1601947004792)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509105520277.png)]

6. 上传/下载功能单元

上传用得比较少，多用下载功能（也就是软件刷写）

有关软件刷写需要注意的几点

烧录的时候，为了降低总线的负载率，需要控制车上各个ECU的收发信息开关
烧写时不能开启故障存储

0x34 RequestDownload

请求下载一段程序/数据

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0DrEsAOH-1601947004792)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509110208006.png)]

肯定响应

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-k8quQRAU-1601947004793)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509110335965.png)]

0x35 RequestUpload

用于请求上传一段程序/数据

0x36 TransferData

用于传输需要刷写的程序/数据
比如需要传输6000个字节，但是由于通信波特率决定了一次只能传输4000个字节，这个时候就需要0x36 01 请求之后再有 0x36 02 传输

0x37 RequestTransferExit

请求停止程序/数据的传送
对0x36 数据传输的数据校验，常见的校验和是CRC8 ，CRC16
UDS诊断服务的几种形式
1. 只有SID 如0x3E
2. 带SF ，SID+SF
3. 带数据标识符DID ，SID+DID, 如0x22 和0x21
4. 其他 SID+SF+RID(历程标识符) 如 0x3E
CAN总线的UDS实现，ISO15765-2
- 三种寻址方式：
  
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-egjrUo4r-1601947004794)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509111945059.png)]
  1. 正常寻址
  2. 扩展寻址
  3. 混合寻址
CAN总线一次最多只能发送8个字节

常用的NRC

1. NRC22

1. NRC31

请求超出范围

比如NRC31在三个会话中都是支持的，但是不是所有的DID在所有的会话中都是支持的，当读取某一个DID信息时，如果该DID在当前会话下不支持就会返回NRC31

DCM(Diagnostic Communication Manager)

DCM模块主要是实现UDS和OBD诊断服务的实现，但是DCM跟其他模块的交互比较频繁，需要了解诊断服务的机制需要其他模块配合，比如BswM、DEM、EcuM以及SWC等。

功能

接收并响应诊断仪的数据请求，负责诊断数据流以及诊断状态的管理
检查请求的服务是否在当前的会话和安全等级中支持
DCM支持UDS（14229-1）和OBD-II(15765-4)的全部服务

全局工作流程

内部工作流程

DSL(Diagnostic Session layer)

DSL用于处理诊断数据请求和响应的数据流；监控和确保诊断请求和响应的时序。

功能

1. 处理诊断请求

当收到诊断请求时，PDUR调用Dcm_StartOfReception()和Dcm_CopyRxData()函数将收到的诊断请求数据放置在DCM模块的Buffer中，然后PDUR调用Dcm_TpTxConfirmation()函数通知Dcm模块接收到了新的诊断请求。

2. 处理诊断响应

当需要响应诊断请求时，DSL模块通过调用PduR_DcmTransimit()和Dcm_CopyTxData()将数据传递至PDUR模块，其中PduR_DcmTransimit()函数只是传递长度信息、地址信息，数据是通过Dcm_CopyTxData()函数传递至PDUR模块，当数据传输成功后，PDUR模块通过Dcm_TpTxConfirmation()函数告知DCM数据接收成功。

3. 管理安全等级

DSL提供Dcm_GetSecurityLevel()、DslInternal_SetSecurityLevel()两个函数分别用于获取当前的安全等级和设置安全等级。

配置

对于配置层面而言，DSL菜单主要是：

配置诊断帧，包括物理寻址和功能寻址，单次通信的最大Buffer，以及时间参数，
包括回复0x78的时间
为了防止诊断服务异常，允许0x78的最大次数等。

DSD(Diagnostic Service Dispatcher)

功能

DSD模块负责检查诊断请求的有效性（诊断会话、安全访问级别、应用程序权限的验证），并跟踪服务请求执行的进度。

1. 检查诊断服务

当DSL接收到新的诊断请求，DSL通过内部接口通知DSD，如图3所示。DSD调用Dcm_GetSesCtrlType()、Dcm_GetSecurityLevel()获取当前的Session和安全等级，DSD模块会在当前Session的“Service Identifier Table”检查诊断请求SID是否在其中，如果不在table中，DSD会发送NRC 0x7F，如果诊断服务支持，但当前Session不支持该子服务，DSD会发送NRC 0x7E；然后检查当前安全等级是否满足条件，如果当前安全等级不支持该诊断请求，DSD会发送NRC 0x33。最后检查数据的长度。

图3 DSL与DSD的交互

2. 汇总响应数据

当DSP模块完成诊断请求处理后，DSD负责将整理响应数据。并发送至DSL。

DSD模块将服务标识符(SID)(如果是负反馈，则为0x7F)和响应的数据流添加至“Dcm_MsgContextType”。然后DSD将其传送至缓冲区，并在缓冲区的第一个字节添加SID。

配置

对于配置而言，DSD主要是配置：

所需要实现的服务
服务所支持的session
服务执行的安全等级

DSP(Diagnostic Service Processing)

功能

DSP用于实现不同服务的处理，当接收到DSD请求处理诊断服务，DSP的处理过程如下：

1. 分析接收的请求信息，调用不同的诊断服务实现函数

2. 检查格式以及是否支持所寻址的子功能

3. 获取数据或者调用DEM、SWC或者其他BSW模块的接口

比如0x22和0x2E服务需要调用SWC的数据接口进行读写；0x28需要调用BswM的逻辑实现关闭不同的CAN报文；0x19服务需要调用DEM模块获取快照数据和扩展数据。

4. 汇总响应数据

配置

对于配置而言，DSP模块配置项比较杂，比如：

DID的实现，包括DcmDspData用于配置DID的数据类型，数据长度，以及接口类型；DcmDspDidInfo用于配置DID的读写功能；DcmDspDids用于汇总DcmDspDidInfo和DcmDspData，并且添加DID value。
安全等级的实现，包括种子和秘钥的位数、最大的错误访问次数，以及时间参数。
Session的配置，包括Session的等级，Session是否支持跳转至Boot，以及时间参数P2 ServeMax和P2* ServeMax。

DEM(Diagnostic Event Manager)

功能

用于处理诊断事件的信息和相关的数据，DCM模块通过服务请求可以获得这些数据。

DEM模块主要是处理的DTC相关的数据。

DCM模块遵循的标准与DCM相同，负责直接处理与DTC相关的服务，如UDS中的0x19服务(响应报文由DCM发送出去)。当软件构件中的Monitor Function检测到故障或BSW模块检测到故障时，将通知DEM模块处理和储存“诊断事件”(由Event ID进行标识)。如果故障确诊，呼叫NVRAM Manager(非挥发性内存管理器)提供的接口将其存取到非挥发性内存中，同时通知应用层进行故障指示。DEM的状态图如下图所示：

DTC

DTC信息= DTC（高3bytes）+DTC状态(低1byte)

三种常见的DTC格式

5位SAE标准故障码
UDS

DTC属性

代码值
检测方式
DTC状态
附加信息

DTC状态

详情可看14229-D附录

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ij9xuYra-1601947004797)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509100644731.png)]

BIT0 : testFailed。表示发生了TestFailed

BIT1:testFailedThisOperationCycle。表示当前Cycle发生了TestFailed
BIT2:pendingDTC。表示当前发生了testFailed
BIT3: confirmedDTC,表示已经检测到多次testfailed，并且能确认故障发生，需要去存储相关的数据。

BIT4:testNotCompletedSinceLastClear, 表示自执行14服务起，还没有完成完成测试，也就是没有testPass或者testFailed。

BIT5:testFailedSinceLastClear，表示自执行14服务起，发生了testFailed事件。
BIT 6:testNotCompletedThisOperationCycle,表示当前OperationCycle还未完成测试

BIT7: warningIndicationRequested,表示特定的DTC需要置告警，车身故障灯亮起

Debounce

DEM提供接口函数Dem_SetEventStatus设置DTC的Status
Debounce方式也就定义了DTC状态变化的形式

连续测试中：
- 如果一直测试通过，达到Pass界限，BIT4由1置位0，BIT6由1置位0
- 如果侦测到testFiled，那么TripCounter就直接从大于0开始计数
- 当TripCounter连续计数累计超过Failed时，BIT2与BIT3置位
AgingCounter&Agecounter
- 当一个OpreationCycle没有检测到testFailed,AgingCounter就会自加1，同时DTC Status的BIT就会清0
- 当AgingCounter计数达到一定的阈值后，此故障已经完成了老化，可以自愈。同时DTC Status的BIT3清0
- 14229-1附录D提供了关于AgingCounter的演示
SnapShot
- SnapShot是一群DID数据的集合
- 每个DTC在Confirm时可以生成快照，将当时的一些关键数据存储在NVM中
- 通过19服务读取SnapShot的具体数据

cess=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI1OTIwMDkx,size_16,color_FFFFFF,t_70)

Debounce方式也就定义了DTC状态变化的形式

连续测试中：
- 如果一直测试通过，达到Pass界限，BIT4由1置位0，BIT6由1置位0
- 如果侦测到testFiled，那么TripCounter就直接从大于0开始计数
- 当TripCounter连续计数累计超过Failed时，BIT2与BIT3置位
AgingCounter&Agecounter
- 当一个OpreationCycle没有检测到testFailed,AgingCounter就会自加1，同时DTC Status的BIT就会清0
- 当AgingCounter计数达到一定的阈值后，此故障已经完成了老化，可以自愈。同时DTC Status的BIT3清0
- 14229-1附录D提供了关于AgingCounter的演示
SnapShot
- SnapShot是一群DID数据的集合
- 每个DTC在Confirm时可以生成快照，将当时的一些关键数据存储在NVM中
- 通过19服务读取SnapShot的具体数据