精华内容
下载资源
问答
  • UDS

    千次阅读 2020-10-06 09:19:09
    UDS(ISO 14229-1&ISO 15765-2) U 可以基于任何总线 VIN :车辆识别号,是主机厂对一辆车的唯一标识码,是在下线检测的时候写入到ECU当中 诊断的作用:读取软硬件版本号,故障检测,程序升级刷写,下线检测,IO...

    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之间连接的接口
      3. image-20200508202957812
    1. image-20200508203056430

    D 诊断通讯协议

    • 本地客户端和本地服务器:如果Client和Server 的具有相同的本地网段,就是说CAN id 的开头一样
    • 远程客户端和远程服务器:一般是在有网关的网络中会涉及的,通过远程地址进行标识
    • PDU: 是信息(PCI)和数据(data)组成,在通讯中一般都会涉及到PDU, UDS中每一层都有对应的PDU
    1. 协议控制信息PCI
    2. data
    • 对等实体:以软件,硬件或者软硬件的任意组合实现的每层活动部分
    • 寻址方式:
    1. 物理寻址:比如软件刷写
    2. 功能寻址:同时连接几个ECU 进行DTC的清楚
    • 地址:地址与报文ID 有关,诊断报文ID =基地址+节点地址,功能寻址一般为特定ID:0x7DF
    1. 源地址:
    2. 目标地址:
    • 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分

    1. A_PCI (SID) :请求服务和肯定响应,一个字节无符号整数
    2. 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附录就是了
      image-20200509070705500
    • 诊断三要素:

    1. 请求
    2. 肯定响应
    3. 否定响应
    • A_PDU

      1. Cvt: convention; M: mandatory, C:conditional(基于某一些标准的),S: selectonal(可选的),U: User optional(用户自定义)

      2. 子功能(SF):带子功能(S); 不带子功能(U)

      3. SF :一个字节;子功能参数范围0x00-0x7F: 0-127

        image-20200509071647778

        第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
    • 四个步骤

      image-20200509080128185
    1. 请求,2n-1表示安全等级,如果请求时已经解锁,则直接返回位为全0的肯定响应,表明已经处于解锁状态

    2. ECU返回种子,随机数,种子的字节长度由OEM自定义

    3. Tester通过种子,再根据种子安全等级与范围,计算一个密钥key1

    4. ECU 通过key1 计算Key2, 如果Key1 =Key2 则解锁

    5. ECU返回解锁消息

      • 0x27 可以实现不同安全等级切换,但是在任意时刻只能有一个安全等级
      • 编写cdd文件时,种子字节、安全等级、密钥数据类型都可以自定义,创建好的安全等级可以在state groups中查看
      • 常见8个NRC
    6. 不同安全等级之间的关系

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

      • 不同安全等级之家可以是相互独立的也可以是有依赖关系的,比如说要先解锁了安全等级1之后才能进入到安全等级3

      • 从解锁状态跳转到锁定状态的几种方式:

        1. 接收了$11服务,ECU重新复位了
    7. 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需要不同的服务支持
    • image-20200509094523018
    0x2E WriteDataByIdentifier
    • 和读取消息类似,只是过程相反image-20200509095444880
    • 写入的一般都是
      • 非易失存储器中的数据
      • 可标定的参数
      • 车辆的配置信息
    • 否定NRC
    • 示例
      1. 通过F190写入VIN号,同上相反

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

    0x19 ReadDTCInformation
    • 一共28种子功能,常用的有4种

      image-20200509101220348
      1. 0x02 最常用 SM(StatusMask)表示掩码; SAM(StatusAvailabilityMask)表示返回的可用掩码

        注意:SAM是通过SM与ECU内部的现有的DTC的状态进行&计算,筛选出非0的所有的DTC

        所以一般状态掩码与DTC的状态码的定义类似

        image-20200509101446767
      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

        image-20200509101555180
    0x14 ClearDiagnosticInformation
    • image-20200509103924718
    • 3个字节的DTC组是用于选择DTC组的掩码,group对应着车身、动力总成、车身、地盘等

      image-20200529170436690
    • 清除完成之后,返回肯定响应,即使没有DTC,同样发送肯定响应

      image-20200509104301628
    • 清除所有DTC

      image-20200529170347077
    • 清除某一个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

    image-20200529163734244

    DCM(Diagnostic Communication Manager)

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

    功能

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

    全局工作流程

    img

    内部工作流程

    https://img-blog.csdnimg.cn/20200211160056932.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI1OTIwMDkx,size_16,color_FFFFFF,t_70

    img

    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菜单主要是:

    1. 配置诊断帧,包括物理寻址和功能寻址,单次通信的最大Buffer,以及时间参数,
    2. 包括回复0x78的时间
    3. 为了防止诊断服务异常,允许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。最后检查数据的长度。

    img

    图3 DSL与DSD的交互

    2. 汇总响应数据

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

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

    配置

    对于配置而言,DSD主要是配置:

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

    DSP(Diagnostic Service Processing)

    功能

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

    1. 分析接收的请求信息,调用不同的诊断服务实现函数
    2. 检查格式以及是否支持所寻址的子功能
    3. 获取数据或者调用DEM、SWC或者其他BSW模块的接口

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

    4. 汇总响应数据
    配置

    对于配置而言,DSP模块配置项比较杂,比如:

    1. DID的实现,包括DcmDspData用于配置DID的数据类型,数据长度,以及接口类型;DcmDspDidInfo用于配置DID的读写功能;DcmDspDids用于汇总DcmDspDidInfo和DcmDspData,并且添加DID value。

    2. 安全等级的实现,包括种子和秘钥的位数、最大的错误访问次数,以及时间参数。

    3. 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的状态图如下图所示:
    img

    DTC

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

    三种常见的DTC格式

    1. 5位SAE标准故障码

    2. UDS

      image-20200509100523334

    DTC属性

    1. 代码值
    2. 检测方式
    3. DTC状态
    4. 附加信息

    DTC状态

    详情可看14229-D附录

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

    • BIT0 : testFailed。表示发生了TestFailed

    img

    • BIT1:testFailedThisOperationCycle。表示当前Cycle发生了TestFailed

      img

    • BIT2:pendingDTC。表示当前发生了testFailed

      img

    • BIT3: confirmedDTC,表示已经检测到多次testfailed,并且能确认故障发生,需要去存储相关的数据。

    img

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

    img

    • BIT5:testFailedSinceLastClear,表示自执行14服务起,发生了testFailed事件。

      img

    • BIT 6:testNotCompletedThisOperationCycle,表示当前OperationCycle还未完成测试

    img

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

      img

    Debounce

    1. DEM提供接口函数Dem_SetEventStatus设置DTC的Status

      img

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

      连续测试中:

      • 如果一直测试通过,达到Pass界限,BIT4由1置位0,BIT6由1置位0
      • 如果侦测到testFiled,那么TripCounter就直接从大于0开始计数
      • 当TripCounter连续计数累计超过Failed时,BIT2与BIT3置位
    3. AgingCounter&Agecounter

      • 当一个OpreationCycle没有检测到testFailed,AgingCounter就会自加1,同时DTC Status的BIT就会清0
      • 当AgingCounter计数达到一定的阈值后,此故障已经完成了老化,可以自愈。同时DTC Status的BIT3清0
      • 14229-1附录D提供了关于AgingCounter的演示
    4. SnapShot

      • SnapShot是一群DID数据的集合
      • 每个DTC在Confirm时可以生成快照,将当时的一些关键数据存储在NVM中
      • 通过19服务读取SnapShot的具体数据

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

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

      连续测试中:

      • 如果一直测试通过,达到Pass界限,BIT4由1置位0,BIT6由1置位0
      • 如果侦测到testFiled,那么TripCounter就直接从大于0开始计数
      • 当TripCounter连续计数累计超过Failed时,BIT2与BIT3置位
    2. AgingCounter&Agecounter

      • 当一个OpreationCycle没有检测到testFailed,AgingCounter就会自加1,同时DTC Status的BIT就会清0
      • 当AgingCounter计数达到一定的阈值后,此故障已经完成了老化,可以自愈。同时DTC Status的BIT3清0
      • 14229-1附录D提供了关于AgingCounter的演示
    3. SnapShot

      • SnapShot是一群DID数据的集合
      • 每个DTC在Confirm时可以生成快照,将当时的一些关键数据存储在NVM中
      • 通过19服务读取SnapShot的具体数据
    展开全文
  • UDS_uds诊断_uds_源码

    2021-10-03 13:36:10
    文件中包含UDS诊断协议详解与14229标准与部分demo
  • 【图解UDSUDS汽车诊断标准协议(ISO 14229)带你入门到精通 目录 0 前言 1 诊断的基本概念 2 UDS诊断诊断协议 2.1 诊断服务的概念 2.2 诊断会话控制0x10服务 2.3 会话访问0x27服务 2.4 用于读/写的DID的0x...

                                      【图解UDS】UDS汽车诊断标准协议(ISO 14229)带你入门到精通

    目录

    为了便于学习ISO 14229 UDS诊断协议,提供三个资源链接:

    0 前言

    1 诊断的基本概念

    2 UDS诊断诊断协议

    2.1 诊断服务的概念

    2.2 诊断会话控制0x10服务

    2.3 会话访问0x27服务

    2.4 用于读/写的DID的0x22/0x2E服务

    2.5 故障存储相关的0x19和0x14服务

    3 结尾


    总目录链接:

    《UDS/OBD诊断&诊断描述文件CDD》总目录icon-default.png?t=L892https://blog.csdn.net/qfmzhu/article/details/120425660

    为了便于学习ISO 14229 UDS诊断协议,提供三个资源链接:

    a)【图解UDS】UDS汽车诊断开发流程及Vector解决方案工具链介绍

    b)ISO 14229 -Part1,2,3,4,5,6,7 UDS最新标准文件获取路径

    c)ISO 14229 Road vehicles — Unified diagnostic services (UDS)标准各Part部分修订和发布状态汇总

    0 前言

    诊断的概念来源于医学,医生通过询问、观察病人,或者通过仪器检测,利用数据对病症做出判断。

    而车辆诊断的目的也有类似的地方,为了能够快速准确的判断车辆或者某个控制器的故障以及故障原因,从而为维修提供可靠的依据。

    内容大致分为三个部分,首先介绍诊断的基本概念,再为大家讲解UDS诊断协议,以及协议中常用到的诊断服务,最后对今天的内容做一个小结。

    1 诊断的基本概念

    车辆的诊断需要有Tester端和ECU端,Tester端和ECU端通过一问一答的形式进行通信,因而Tester端和ECU端都需要遵循同样的诊断通信协议,常用的诊断协议有ISO 14230,ISO 15031,ISO 15765,还有我们熟悉的ISO 14229就是UDS协议,在协议里面定义了诊断的请求,诊断响应的报文格式,以及ECU怎样处理诊断请求报文,以及诊断服务的应用。

    UDS是Unified Diagnostic Services的缩写,在国际标准ISO 14229-1中定义,UDS标准中除了定义服务的用法,以及服务的格式以外,还定义了一些标准化的数据,而到OEM要使用UDS协议时,除了要使用标准定义的服务以及标准数据以外,还要依据自身的情况,定义属于OEM的特定数据,比如说,定义所要遵循的服务,需要支持的DID,需要支持的DTC等这些内容,这样形成的符合某OEM的诊断规范才能用于ECU诊断功能的开发以及验证。

    随着车辆ECU的增多,车辆网络拓扑结构也越来越负责,比如说一辆车需要有多种总线(CAN总线,LIN,以太网,FlexRay),

    所以在2013年释放的UDS协议中,除了对通用诊断服务的定义以外,还增加了关于UDS在各个总线中应用的定义

    这张图就描述了UDS在OSI七层模型中的应用,OSI七层模型,第一层第二层分别定义了物理层和数据链路层,第三层第四层定义了网络层和传输层,第七层是应用层。

    比如说我们熟悉CAN总线,物理层和数据链路层遵循的是ISO 11898,而它的传输层遵循的是ISO 15765-2,在ISO 14229-3中定义了UDS基于CAN总线的应用,而现在比较火的以太网,它的物理层和数据链路层遵循的是ISO 13400-3,它的传输层也就是DoIP遵循的是ISO 13400-2, 它的UDS基于以太网的应用是ISO 14229-5

    下面我们来看下,关于诊断服务的一些知识,

    2 UDS诊断诊断协议

    2.1 诊断服务的概念

    首先来看服务请求和响应格式,“请求”由Tester端发送给ECU,请求报文里带有SID,根据具体的服务内容后面加具体的数据。肯定响应格式由“SID+40+具体的数据”。否定响应格式是一个固定的格式“7F+请求报文里的SID+一个字节的NRC”

    看两个名词,一个叫做Subfunction,一个叫做ID,UDS服务支持Subfunction的请求和响应格式,“请求”为“SID+一个字节Subfunction+具体的数据”,肯定响应为“SID+40+Subfunction+具体的数据”,而有的UDS服务里面是不支持Subfunction,是支持DID的,DID是“数据ID”的意思,那么它的请求格式为“SID+具体的DID+数据内容”,肯定响应“SID+40+DID+具体的数据”,这里举出两个例子,一个是 “31例程控制服务”,还有一个是“2F IO控制服务”,31就是它的请求报文里面,带一个字节的Subfunction和两个字节的Routine ID,后面的这个数据是跟具体的数据内容,也可以没有具体的数据。2F是它的SID+两个字节的DID+一个字节的输入输出控制参数(这里注意这一个字节的数据类似于Subfunction,但是他不是Subfunction)+后面加具体的数据内容。

    下面为大家介绍一个概念,为肯定响应抑制位。肯定响应抑制位是在Subfunction里的这个字节的最高位,我们把它叫做肯定响应抑制位。只有这个服务支持Subfunction的时候,才有可能支持肯定响应抑制位,当肯定响应抑制位置1的时候,要求所有的肯定响应的抑制将不再发送。当肯定响应抑制位为0的时候,肯定响应是不被抑制的。这里要注意的是它只是抑制肯定响应,而否定响应是不被抑制的。

    Tester发送的请求报文格式错误,或者请求发送的条件处于错误,ECU将发送否定响应,否定响应的格式是“7F+SID+NRC”,常用到的NRC在这里罗列了。

    11表示服务不支持;

    12 subfunction不支持;

    13 请求的长度不正确,或者格式不正确

    31 是请求超出范围;

    7E 是在当前会话下subfunction不支持

    7F 是在当前会话下服务不支持

    来看两个时间参数,一个是叫做P2Sever,一个是叫做P2Sever*。当Tester给ECU发送请求过后,ECU需要在P2Sever时间内给出相应的响应,如果ECU当前正在处理别的任务,处理别的事情,而不能在P2Sever的时间内给出相应的响应,那么它先在P2Sever时间内给出一个NRC为78的Pending报文,告诉Tester“ECU正在忙”,之后会在P2Sever*的时间内给出其它的响应报文,如果P2Sever*的时间内还是不能给出相应的肯定响应和否定响应,将继续给出Pending报文,直到能够正确处理请求报文之后,会给出正确的响应报文。

    今天会着重介绍26个UDS服务里的6个,分别是10诊断会话控制,14清除诊断信息,19读取诊断信息,22由DID读取数据,27安全解锁服务,2E由DID写入数据。

    下面我们来看诊断会话控制就是10服务

    2.2 诊断会话控制0x10服务

    ECU会有不同的会话控制,所以ECU在不同的阶段,比如说开发,生产,售后阶段也会用到不同的会话模式,因为每个服务功能的不同,也会在诊断规范里定义这些服务所支持的诊断会话模式

    这张表是14229里面,对各个诊断服务,对会话控制的支持情况,比如说通信控制28服务,要求在默认会话下不支持;27安全解锁服务,在默认会话模式下不支持;和刷写相关的34,36,37服务,在默认会话下也是不支持的。

    我们来看更会话控制有关的3个NRC,首先来看NRC 7F:NRC 7F是指在当前会话下服务不支持。28通信控制服务,要求在默认会话下是不支持的,在扩展会话下能支持。而当ECU处于默认会话的时候,我们上位机发送了28这个服务,ECU收到之后,会回复7F NRC的否定响应。

    NRC 7E和NRC 7F 不同的是:NRC 7E是在当前会话下Subfunction不支持。一个用的比较多的用法是,编程会话是不能够由默认会话跳转到编程会话的,只能由扩展会话跳转到编程会话。但ECU处于默认会话的时候,执行了10 02 编程会话的请求,ECU会回复7E NRC的否定响应。

    再来看NRC 31,NRC 31常用的用法是请求超出范围,比如说22服务,发送的DID,是ECU不支持的,比如说发送的请求22 01 01 ,因为ECU不支持01 01这个DID,会发送NRC 31的否定响应,还有一个用法是:22在3个会话(默认,编程,扩展下都是支持的),22后面所跟的DID来读取数据的DID对各个会话等级是有要求的,比如说读取硬件版本号在编程会话模式下是支持的,读取车速在编程会话下是不支持的,当ECU处于编程会话的时候,来通过 C0 01来读取车速,那么ECU会回复NRC 31的否定响应。

    这个是会话状态的一个状态机,状态机之间可以互相跳转,状态机自身也能跳转,我们把除了默认会话之外的会话状态,都叫做非默认会话状态。当ECU一上电的时候是处于默认会话的,我们通过10,比如说10 03,10 02来将会话状态由默认会话跳转到非默认会话。由非默认会话执行10 01跳转至默认会话。当ECU处于非默认会话的时候,S3 time这个时间超时,ECU也会从非默认会话跳转到默认会话。为了防止ECU从非默认会话跳转至默认会话,我们要求Tester端周期发送3E服务Tester present,让ECU一直维持在非默认会话。那么S3 time这个时间怎么用呢?我们来看下面这张图

    Tester端会利用S3Client周期发送Tester present给ECU,ECU收到Tester present比如说3E 00,3E 80的服务请求,会让ECU维持在非默认会话,如果Tester端S3server这个时间内,比如说5000毫秒时间内,都没有给ECU发送任何诊断请求报文,那么ECU就会从非默认会话跳转到默认会话;如果ECU处于解锁状态,也会从解锁状态跳转到锁定状态。通常S3cleint时间小于S3server的时间,比如说网关延时的一些情况。

    这个是10服务的请求和响应格式。SID+一个字节的Subfunction(常用的有01默认会话,02编程会话,03扩展会话),它的肯定响应格式是50(就是10+40)+一个字节的Subfunction(就是诊断会话类型)+4个字节的会话参数。

    支持的NRC有3个,12 subfunction不支持;13请求格式或者长度错误;22条件不支持。

    下面我们来看下,安全解锁27服务。

    2.3 会话访问0x27服务

    常用到的服务:2E服务通过DID来写入数据;2F通过DID来控制输入输出端口的数值;还有ECU刷写有关的编程服务。这些服务都会改变和影响一些内存里的数据,或者输入输出端口的一些值,所以这些服务是一个被保护的服务。这些服务只有ECU处于解锁状态下才能够执行,而ECU一上电处于锁定状态,那么ECU如何从锁定状态跳转到解锁状态呢?

    是要求Tester端和ECU端进行27解锁服务之后,ECU才能够处于解锁状态,那么这个解锁的过程是一个固定的:首先由Tester端给ECU发送请求报文来请求种子,ECU收到这个报文后,回复肯定响应,肯定响应里带有种子数;Tester端收到这个种子数,根据自己安全算法算出来一个K1发送给ECU,ECU也有自己对应的安全算法,他由这个Seed算出来一个密钥K2,当ECU收到这个K1后和自身计算的K2进行比较,如果两者是一致的,那么ECU发送肯定响应给Tester端,告诉Tester端ECU已经解锁。

    我们刚才也提到了ECU一上电处于锁定状态,只有执行了安全解锁的流程后才能跳转到解锁状态,一个ECU可以同时拥有多个安全等级,多个安全等级之间可以是相互独立的,也可以是有依赖关系的,比如说要求先解锁安全等级1才能解锁安全等级2,那么当ECU处于解锁状态的时候,会有几种情况会使ECU由解锁状态跳转至锁定状态,比如说执行了11复位服务,比如说有了重新上下电,还比如说有了执行10会话切换,也会让ECU由解锁状态跳转到锁定状态。

    当ECU处于解锁状态的时候Tester端再去请求种子的时候,回复的种子全为0。

    这个是请求种子的请求报文和肯定响应报文。请求报文为“27+01”;肯定响应“67+01+四个字节的种子”。

    当Tester端计算得到了一个密钥,它会发送“27+02+4个字节的密钥”给ECU。当ECU将两者密钥比较后,它认为比较的结果是一致的,ECU会给Tester端发送“67+02”,认为ECU已经处于解锁状态。

    那么当ECU已经处于解锁状态的时候,Tester端又一次请求了种子,发送了请求种子的请求报文给ECU,那么ECU就会回复“种子数全为0的肯定响应”报文给Tester端。表明ECU现在处于解锁状态。

    这个是27服务支持的所有NRC是在14229-1里定义,比如说我们常用的12;13;这里注意24是一个请求顺序错误,比如说我们要求的安全解锁状态过程必须是先请求Seed再发送key,如果你没有执行请求seed的请求报文,直接发送了key,就会回复24 NRC;比如说35是非法Key,如果Tester发送了非法的密钥给ECU,ECU就会回复35 NRC;36是尝试次数超限,比如说这是要看具体的诊断规范定义,有的定义请求尝试次数不能超过3次,那么Tester端发送给ECU的Key连续3次错误的时候,ECU就会回复36 NRC;37指延时还没有到,因为在有的诊断规范里定义请求的尝试次数达到最大值的时候,ECU会锁定一段的时间,在这个时间之内,你的Tester端是不能够再次请求种子的,所以在这个时间之内,比如说有的整车厂用到10秒延时,Tester端再一次发送了请求种子的请求报文给ECU,那么ECU就会回复37 NRC的否定响应报文。

    下面我们来看通过DID来读取和写入数据,就是22和2E服务

    2.4 用于读/写的DID的0x22/0x2E服务

    首先来看22服务的请求和响应格式,请求格式“22+两个字节的DID”;它的肯定响应“62+DID+所读取的数据”。这里举出了一个例子,比如说现在的DID是F1 86来读取当前的诊断会话状态,它的肯定响应格式“62+ F1 86+02”读取当前处于编程会话状态。

    在14229-1 2013版附录C里面列出一些推荐使用的DID和这些DID的功能,大家也可以去看一下这个附录C

    22服务支持的NRC。13是请求格式不正确;14读取的数据已经超过了传输的最大值,就是超限了;31我们刚才也已经提到过了,比如说请求的DID不支持,请求的DID在当前会话下不支持;33要求在解锁状态下,而现在没有处于解锁状态执行了响应的请求。

    看一下由DID写入数据:2E服务。他的请求格式“2E+2个字节的DID+需要写入的数值”;肯定响应的格式“6E + DID”。这里举出来一个例子,由F1 90来写入VIN码,写入一个17字节的VIN码,这里简化,就打了省略号。当写入成功后,ECU回复肯定响应“6E +F1 90”

    2E服务支持的NRC。31;3E;33;72和编程有关的,比如说在Bootloader刷写的过程中,需要对Flash进行操作,而写入数据没有写成功的时候,会回复72 NRC

    下面我们来看和故障存储有关的服务。

    2.5 故障存储相关的0x19和0x14服务

    什么是故障呢?当系统检测到了一个错误或者是一个故障发生的时候,会将相对应的数值故障码进行存储,那么这个对应的数值故障码,我们称之为故障码,就是DTC。

    一个DTC可以反应出一个故障发生的具体位置,和这个故障发生原因和类型,我们通过读取的DTC信息,可以为维修提供一些依据。除此以外还有与法律有关的故障,比如说排放有关的,在未来还会有安全相关的故障

    通过这个故障可以反应出在ECU具体的哪一个位置,和产生的故障类型,在很多国际标准里面都定义了DTC的格式。比如说UDS里定义DTC由3个字节组成,而ISO 15031-6里定义了DTC格式由“两个字节根基+一个字节的故障类型”组成。那么我们常用的UDS服务里面DTC格式用的是哪一种呢?有95%用到的DTC格式都是ISO 15031-6里定义的DTC的故障类型和格式

    ISO 15031-6定义的DTC格式什么样的呢?

    两个字节的根字节来定义DTC,

    左边前两位能反应DTC到底是哪一个系统:

    00表示Powertrain;

    01表示底盘;

    10表示车身;

    11是网络相关的。

    左边第3~4位反应的是,DTC到底是由ISO,SAE,这些标准组织所定义的故障,还是由整车厂来定义命名的故障;

    左边第5~8反应的是车辆系统的区域;

    右边8位,这个字节具体的编码,就是DTC的编码。

    在14229-1中定义的19服务读取DTC信息里,定义28个Subfunction,根据不同的Subfunction来获取不同的诊断信息,在这里我们介绍4个不同的Subfunction,这4个Subfunction也是在规范中常用的,他们分别是02;04;06;0A。

    • 19 02由DTC的状态码获取DTC;
    • 19 04读取DTC的快照数据。在14229里定义的数据叫做快照数据;在Autosar里定义的数据叫做冻结帧,其实他们指的是一类数据。快照数据是指当这个错误发生,或者当这个DTC存储的时候,记录的一些环境数据,比如说车速,水温,发动机转数等这些数据,从而我们读取这些数据之后,能够更好的判断DTC产生的原因以及发生故障原因。
    • 19 06是来获取DTC存储的时候一些扩展数据,这个数据常用的比如说有一些计数器,比如说老化计数器,这样的数据。
    • 19 0A是来读取这个ECU所支持的全部的DTC,ECU支持的哪些DTC是在ECU诊断规范的时候已经定义好的,所以我们通过19 0A读取的DTC是这个ECU应该支持的所有的DTC,即使这个DTC没有产生,也能够被读取的

    刚才我们提到了DTC状态字节,这个DTC状态由8个位组成的一个字节。这8个位分别代表不同的含义,具体这8个位代表的含义,包括这8个位初始值是什么,它什么时候被置1,什么时候又被清0,它在什么情况下用,怎样用,在14229-1 2013版附录D有详细的定义。大家如果想具体了解这8个位的定义,可以参看附录D。

    这里要提醒大家的是除了Bit4和Bit6以外,其它所有位的初始值都应该为0,而Bit4和Bit6的初始值位1。

    常用的有比如说Bit0和Bit3.

    Bit0当检测到这个故障,发生错误的时候被置1;

    Bit3 ConfirmedDTC根据具体DTC的应用逻辑,这个DTC被检测到了多次,这个次数由具体的ECU规范定义,那么这一位也应该被置1。

    我们通过19 02读取DTC的时候,会用到3个不同类型的DTC Status,那么这3个不同的DTC有什么区别呢:

    • 在请求报文里有一个字节的DTC Status Mask,这个是被Test用来读取DTC数据的,这个值可以是00到FF之间的任意值,根据所要读取的DTC内容决定。如果你想读取这个ECU产生的所有DTC,你可以用 0xFF.
    • 在肯定响应中,也有一个字节DTC Status Availability Mask,这个字节的DTC Status,是ECU诊断规范里定义的
    • 在肯定响应中,读取的DTC后面还有一个字节,是反应的这个DTC,所产生时,对应的状态信息。

    我们来看具体的请求和响应格式,首先看19 02。19 02后面跟一个字节的Status Mask,第0位和第3位被置1,而这一个字节Mask,是在ECU诊断规范定义的,所以 59 02 +一个字节的Mask+具体的DTC+DTC后面的跟的DTC Status。

    如果有多个DTC,后面会重复DTC的格式:3个字节的DTC+DTC Status。

    通过19 0A读取ECU支持的所有DTC,请求格式是两个字节“19 + 0A”;肯定响应格式“59 + 0A+一个字节的Mask+后面跟ECU支持的所有DTC”

    当诊断故障信息被存储了以后,我还需要,问题我们已经通过维修的方式解决了,我们用什么样的方法将这个DTC清除呢?

    用到14服务清除诊断信息,14服务格式很简单,请求格式是“14 + 3个字节数值”,这3个字节的数值可以是针对单个DTC清除,也可以是按组来清除DTC,也可以是清除全部DTC。当3个字节都为FF时,表示将ECU里产生的所有DTC清除。

    那我能不能按照组来清除DTC,比如说清除和车身有关的DTC,就按照车身这个组的数值,将它添加到请求报文格式里;

    那我能不能单独清除,只针对某一个DTC,清除这个DTC,也是可以的。只需将这个DTC的具体数值放在请求报文,那么的肯定响应格式是一个字节54。

    这个表格在14229中也有描述,大家可以具体参看。

    3 结尾

    欢迎大家给我留言,如果觉得好,动动你的手指,“点赞”+“收藏

    获取更多汽车行业资讯,以及工具链的使用,可以关注微信公众号“汽车电子助手

    或者扫描下方二维码进行关注

    在这里插入图片描述

    END

    展开全文
  • UDS诊断入门

    万次阅读 多人点赞 2018-10-15 20:05:36
    UDS(Unified Diagnostic Services,统一的诊断服务)诊断协议是ISO 15765 和ISO 14229 定义的一种汽车通用诊断协议,位于OSI模型中的应用层,它可在不同的汽车总线(例如CAN, LIN, Flexray, Internet 和K-line)上...

    UDS(Unified Diagnostic Services,统一的诊断服务)诊断协议是ISO 15765 和ISO 14229 定义的一种汽车通用诊断协议,位于OSI模型中的应用层,它可在不同的汽车总线(例如CAN, LIN, Flexray, Internet 和K-line)上实现。UDS协议的应用层定义是ISO 14229-1,目前大部分汽车厂商均采用UDS on CAN的诊断协议。

    如下图所示,ISO 14229-1也就是UDS协议仅对应用层做出了定义,物理层有双绞线和光纤供用户选择,数据链路层采用CAN总线的ISO 11898-1协议,针对Classical CAN仅有8个字节的数据场与应用层可处理多帧数据的矛盾,ISO 15765-2对网络层进行了定义。CAN的8字节数据场会腾出一帧来表示网络层的信息。下图右侧是排放相关的协议,ISO 15031-5主要针对OBD协议,为法规强制要求车厂满足的协议。学习时,我们应在了解CAN总线基本知识的前提下,着重学习ISO 15765-2和ISO 11898-1的协议内容,并通过BootLoader作为例子,对UDS有一个大致的了解。

    UDS本质上是一系列的服务,共包含6大类26种。每种服务都有自己独立的ID,即SID。

    SID:Service Identifier,诊断服务ID。UDS本质上是一种定向的通信,是一种交互协议(Request/Response),即诊断方给ECU发送指定的请求数据(Request),这条数据中需要包含SID。如果是肯定的响应(Positive Response),回复[SID+0x40],就是请求10,响应50;请求22,响应62,回复的是一组数据。如果是否定的响应(Negative Response),回复7F+SID+NRC,回复的是一个声明。

    肯定响应和否定响应的形式一定要熟记。

    UDS的26种服务中,有7种很重要。它们分别是:$10 Diagnostic Session Control(诊断会话),$14 Clear Diagnostic Information(清除诊断信息),$19 Read DTC Information,$22 Read Data By Identifier(通过ID读数据),$27 Security Access(安全访问),$2EWrite Data By Identifier(通过ID写数据),$3E Tester Present(待机握手)。下面对这7个服务进行解读。

    $10诊断会话

    $10包含3个子功能,01 Default,02 Programming,03 Extended,ECU上电时,进入的是默认会话(Default)。如果您进入了一个非默认会话的状态,一个定时器会运转,如果一段时间内没有请求,那么到时间后,诊断退回到默认会话01。当然,我们有一个$3E的服务,可以使诊断保持在非默认的状态。

    UDS包含4种类型,即SID,SID+SF(Sub-function),SID+DID(Data Identifier)(读写用),SID+SF+DID。

    NRC:Negative Response Code(否定响应码)。如果ECU拒绝了一个请求,它会回应一个NRC。不同的NRC有不同的含义。

    14229-1协议第329页

    单词:Consult(查阅) Session(会话) DTC (diagnostic trouble code)故障码Handling(处理) Conditions(条件) restricted(受限的) Concept(概念)SA(source address 源地址) TA(目标地址)

    例子:以CAN总线网络举例。八个帧数据字节,第一字节被网络层占用。

    请求(Request):02 10 02 xx xx xx xx xx ; 02是网络层单帧SF,数据域有2个字节,10是SID,02是子功能。

    肯定响应:02 50 02 xx xx xx xx xx;02同上,10+40表示对SID的肯定回复,02是子功能。

    否定响应:03 7F 10 22 xx xx xx xx;03同上,7F表示否定响应,10是SID,22是NRC。

    $3E待机握手

    $3E服务用于向服务器指示诊断仪仍然连接在网络上,之前已经激活的诊断服务功能可以仍然保持激活状态。

    例子:02 3E 80 00 00 00 00 00,发送一个3E服务的报文,保持非默认会话状态。80表示无需回复。

    $27安全访问

    $27安全访问:ECU当中有很多数据是整车厂独有的,并不希望开放给所有客户,它需要做一个保密的设定。我们在读取一些特殊数据的时候,要先进行一个安全解锁ECU上电之后是一个锁定的状态(Locked),我们通过$27服务,加上一个子服务,再加上一个钥匙,这样的服务请求可以进行解锁。比如下面的例子,2n-1是一个子服务,通过首轮种子的请求,首轮ECU会返回67+01+AA+BB+CC+DD,AA~DD就是种子了。之后第二轮,诊断端会利用种子进行运算(利用整车厂的算法),生成k1(不一定是1个字节),那么发送请求,27+02+[k1]。ECU同样也会通过种子算出k2。当k1和k2匹配时,解锁(Unlocked)成功。

    $27安全访问服务的否定响应服务ID也是7F。还记得刚才否定响应的格式吗?7F+27+NRC(否定响应码)。

    例子:

    Rx: 02 27 05 00 00 00 00 00 安全访问,05子功能

    Tx: 07 67 05 08 27 11 F0 77 肯定响应,回复了对应安全级别的种子

    Rx: 06 27 06 FF FF FF FF 00 发送密钥,4个FF。注意06是与05成对使用的。

    Tx: 03 7F 27 78 00 00 00 00 否定响应,7F+27+NRC

    Tx: 02 67 06 00 00 00 00 00 肯定响应,通过安全校验

    $22读数据

    $22读数据,Request(请求):22+DID(Data Identifier,通常是两个字节)

    Response(响应):62+DID+Data

    DID有一部分已经被ISO 14229-1规定了。比如0xF186就是当前诊断会话数据标识符,0xF187就是车厂备件号数据标识符,0xF188就是车厂ECU软件号码数据ID,0xF189就是车厂ECU软件版本号数据标识符。

    14229-1协议第339页

    $2E写数据

    $22写数据,Request(请求):2E+DID+Data

    Response(响应):6E+DID

    注意,比如0xF186这个DID不支持直接写入数据,需要用$10来进行会话转换。也就是说,对于写数据的请求,一般来说需要在一个非默认会话,和解锁的状态下才能进行。

    $19 读DTC

    DTC(diagnostic trouble code):如果系统检测到了一个错误,它将存储为DTC。DTC可表现为:一个显而易见的故障;通讯信号的丢失(不会使故障灯亮起);排放相关的故障;安全相关的错误等。DTC可以揭示错误的位置和错误类型。通常DTC占用3个字节,OBD II占用两个字节。图中FTB为Fault Type Byte。

    故障码包括四个大类,分别是PCBU,P是powertrain动力系统,C是Chassis底盘,B是Body车身,U是network通信系统。一个DTC信息占用4个字节。最后一个字节是DTC的状态。前两个字节是我们熟知的类似P0047的故障码。LowByte暂不清楚。

    $19拥有28个子服务(Sub-Function)。常用的子服务有02(通过DTC状态掩码读取DTC),04(读取快照信息),06(读取扩展信息),0A(读ECU支持的所有DTC数据)。

    刚才提到,一个DTC除了它自己的3个字节,还有一个字节专门用于表达DTC的状态。这个状态字节每个位的含义可以查询ISO 14229-1。注意,并不是所有的DTC状态都是支持的。下图是Request/Response。括号标识循环,可以读出很多DTC。

    $14清除DTC

    清除(复位)DTC格式,它可以改变DTC的状态。3个FF代表清除所有DTC。

    Request:14+FF+FF+FF;

    Response:54 。

     

    我们刚才学完了7种重要的服务,SID。除此之外,在CAN总线中,Addressing information寻址信息通过CAN帧ID体现出来。

    通讯的模式分两种,一种是物理寻址点对点),根据物理地址的不同进行访问,但只能访问单个ECU节点,Test为SA源地址,ECUX作为TA目标地址;对应的,另一种是功能寻址广播),根据功能的不同进行访问,它能访问多个ECU节点。

    每一个ECU都有2个CAN帧ID,分别对应收和发的物理寻址

    以上只是一些粗浅的理解。对26种服务更详细的解读请拉到屏幕下方参考张老师的8篇文章。张老师也开通了微信公众号,可以了解一下。

    UDS应用的设备

    在UDS 诊断产品中知名度最高,应用最广泛的是德国Vector公司的CAN case 配合其CANoe 软件,Vector 产品功能齐全,适合系统级汽车总线开发,被大部分汽车厂商采用。Vector 产品因不开放API,不能做二次开发且价格昂贵,不适用于硬件开发团队和生产线的自动化测试。目前市面上有很多CAN 厂商(如Kvaser, ZLG 等)能提供低成本、体积小、驱动简单、开放API 的设备,很适合进行二次开发。

    杂记

    变速器控制单元TCU和防抱死系统ABS是CAN车载网络上的两大电子控制单元, 这2个ECU要通过CAN网络进行大量的信息交互。但是由于电磁干扰、串扰、静电等外界干扰或电控单元本身控制策略引起的通信停止等原因, 2个控制单元之间可能会出现通信丢失的现象。控制系统需要将故障信息(例如通信丢失故障信息) 诊断出来, 以处理通信被破坏时出现丢失帧的故障现象, 并记录为DTC (diagnostic trouble code)。

    ECU的输入信号主要有4种形式: ①模拟信号(水温、油压、蓄电池电压等); ②数字信号(各种开关信号等); ③PWM信号(脉冲信号、频率信号等); ④网络信号(CAN、LIN上传输的信号)。微控制器可以通过监测这些信号来判别输入电路的工作状况。输出的信号往往用作控制电磁阀、指示灯、步进电机等, 大多数为数字信号。

     

     

    学习资料:

    1.统一诊断服务 (Unified diagnostic services , UDS) (一)

    2.统一诊断服务 (Unified diagnostic services , UDS) (二)

    3.统一诊断服务 (Unified diagnostic services , UDS) (三)

    4.统一诊断服务 (Unified diagnostic services , UDS) (四)

    5.统一诊断服务 (Unified diagnostic services , UDS) (五)

    6.统一诊断服务 (Unified diagnostic services , UDS) (六)

    7.统一诊断服务 (Unified diagnostic services , UDS) (七)

    8.基于CAN总线实现的UDS诊断(DoCAN)

    9.【图文】UDS诊断服务_百度文库

    10.CAN诊断基础-上部分_图文_百度文库

    11.CAN诊断-下_已读_图文_百度文库

    12.ISO 14229+统一诊断服务

    13.FlashBootloader_图文_百度文库

    14.帐号登录

    15.ISO 15031-5-2015

    16.ISO 15765-3车载诊断标准-详细中文版

    17.吉利汽车基于CAN线诊断技术规范_百度文库

     

    代码参考:

    1.SAE J1939 协议源代码分析(一)-程序结构框架

    2.基于CAN总线的汽车诊断协议UDS(上位机开发网络层及错误代码解析) - CSDN博客

    3.基于CAN总线的汽车诊断协议UDS(ECU底层模块移植开发) - CSDN博客

    4.基于CAN总线的汽车诊断协议UDS (网络层 ISO 15765)

    展开全文
  • fluent中uds案例实践操作,uds入门案例
  • UDS协议C语言,有需要的可以自行下载!
  • UDS (2)_UDSC语言_uds.zip

    2021-10-11 23:46:33
    UDS (2)_UDSC语言_uds.zip
  • UDS 14229 介绍

    2018-12-27 08:56:12
    汽车电子UDS诊断服务介绍,详细介绍了UDS诊断服务,加深理解UDS,很多插图比较容易理解,恒润科技的培训文档。
  • UDS诊断协议

    2018-10-29 15:47:10
    UDS诊断协议。
  • UDS培训.pptx

    2020-09-21 09:30:06
    目录:CAN消息示例;CAN总线回顾;UDS - Description;UDS - Response;UDS – 服务;UDS – 负响应; ;
  • udf的一步一步教学,手把手教学,案例简单经典,uds自定义标量传输方程
  • iso14229 UDS

    2018-04-03 10:04:25
    UDS诊断协议;Road vehicles — Unified diagnostic services (UDS) — Specification and requirements
  • UDS诊断服务

    2018-12-28 14:01:15
    UDS诊断服务 形象的说:就是使用一套仪器,对当前汽车出现的问题进行分析。而这套仪器与汽车交谈所使用的语言就是UDS(不是唯一的方法)
  • ISO14229 UDS

    2017-09-02 16:29:12
    ISO14229 UDS 诊断协议 Road vehicles — Unified diagnostic services (UDS) — Specification and requirements
  • UDS (2)_UDSC语言_uds_源码.zip
  • uds-proxy 用go编写的示例UDS代理
  • DoIP和UDS协议

    2020-09-24 11:33:03
    ISO 14229-1-2013 UDS Specification and requirements.pdf ISO 14229-2-2013 UDS Session layer services.pdf ISO 14229-3-2012 UDS on CAN.pdf ISO 14229-5-2013 UDS on IP.pdf ISO 13400-2-2012 DoIP Part 2 ...
  • uds经典教程,uds刷写,C,C++源码
  • 凯龙UDS协议规范

    2018-05-18 23:51:19
    凯龙UDS协议 介绍UDS所有相关服务 整车UDS协议开发指南
  • UDS指令.xlsx

    2020-11-28 21:45:28
    个人通过阅读ISO14229统一诊断服务的标准后,个人通过EXCEL整理了UDS的指令结构,适合学习UDS的人查看并完善。
  • can总线UDS非常棒的例子,希望对can 开发的有帮助,网络诊断学习神器.
  • UDS 培训资料

    2018-09-21 14:05:59
    资料是公司找的培训机构,培训UDS这部分时的资料和课件
  • UDS汽车协议

    2016-06-30 15:25:58
    UDS 汽车协议 can bus
  • UDS培训资料.ppt

    2021-07-21 14:36:45
    UDS培训资料 北京恒润
  • UDS诊断入门.pdf

    2021-07-21 08:57:21
    UDS诊断入门.pdf
  • 汽车UDS诊断demo程序

    热门讨论 2018-10-19 09:09:49
    关于汽车完整的UDS的demo程序,对刚入门UDS有很大帮助,架构清晰,很容易理解
  • UDS入门

    千次阅读 2020-06-05 11:26:48
    一、UDS是什么? UDS全称是Unified Diagnostic Services,即统一诊断服务。从字面“诊断”的意思理解就可以知道,它主要作用就是用来诊断汽车的故障的。当然啦,UDS的作用不仅限于此。它还可以用来进行汽车的下线...

    UDS系列讲解总目录

    一、UDS是什么?

    UDS全称是Unified Diagnostic Services,即统一诊断服务。从字面“诊断”的意思理解就可以知道,它主要作用就是用来诊断汽车的故障的。当然啦,UDS的作用不仅限于此。它还可以用来进行汽车的下线检测,汽车下线时把VIN码、软硬件版本号、生产日期等信息写入汽车中的各个零部件中(ECU),以及一些其他的功能等等。

    二、为什么要做UDS?

    有人可能会问了,如果是要实现上面的那些功能,那自己定义一个接口就可以实现故障查询呀,写入就更简单了,为什么还要搞这么复杂。这就要解释一下UDS中的“U”了,统一的意思就是我们把怎么定故障、怎么查询故障、怎样写入VIN码等功能做了一个统一的规定。比如说有些软件车企把VIN码定义为001,有些车企定义为002,这样就对我们在查询的时候造成了很大的麻烦,现在我们规定好VIN码只能用F187表示,其他的可以以此类推。所以,UDS就是一个诊断服务的统一规范的做法,它依据的标准就是ISO 14229。

    三、UDS是怎么实现的?

    UDS作为标准诊断服务,其核心是“服务”技术、售后人员对车辆进行故障诊断,问题排查。如果车辆发生故障就好比人生病就医一样,医生需要询问病人有何症状才能对症下药,诊断工程师同样需要“询问”车辆有什么“不舒服”的地方。询问方式就是采用上位机或者诊断仪(CANtest CANoe等工具皆可以)作为媒介对车辆进行询问,询问开始前首先要知道“病人”的名字、年龄、当然还有性别,对应在汽车ECU上就是其相应的ID号。确定好要检查的病人后,医生询问有其固定的路数,“哪里不舒服”,“喉咙疼不疼”,诊断工程师也有对应的诊断方法,也就是常说的各个“服务”,如$10 、$11 等等,这里的$10/$11就是服务号(Service ID,简称SID,通常我们说某某服务的时候都会用SID代替,这个不用专门记,用多了就记住了),SID后续紧跟的报文内容就是我们询问的内容。我们发送服务报文的时候,网络层会根据ID地址把报文发送到对应的ECU上。这时候ECU就会做出相应的回答,而这个回答也是根据ISO 14229规定好了的,有肯定响应和否定响应两大类,诊断工程师根据回复的报文就能够知道ECU出了什么问题了。

    四、学习UDS需要掌握哪些东西?

    UDS对应的标准是ISO 14229 ,这是肯定要看的。汽车上最常用的通讯网络是CAN,我们的报文也是基于CAN发送和接收的,因此CAN的简单知识也是需要学习的,ISO 15765一定要好好看一下,掌握报文的发送和接收方法。主要针对“单帧”、“首帧”、“连续帧”、“流控帧”等内容有一个大致了解方便后续的软件测试及报文分析。

    UDS系列讲解总目录​​​​​​​​​​​​​​​​​​​​​

    展开全文
  • UDS服务

    2020-08-06 11:43:24
    UDS服务 SID:Service Identifier,诊断服务ID。 UDS的26种服务 UDS的服务分为6大类,但常用的服务是加背景色的15种。这15种服务又可粗略地划分为权限控制、读取数据/信息、写入数据/信息、通信控制、功能控制这几类...
  • PCAN-UDS.ZIP

    2020-08-17 15:13:12
    PCAN-UDS.ZIP

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 4,102
精华内容 1,640
关键字:

UDS