本文主要是介绍UDS（Unified Diagnostic Services，统一的诊断服务）诊断协议服务，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
UDS（Unified Diagnostic Services，统一的诊断服务）诊断协议服务
UDS本质上是一系列服务的集合。UDS的服务包含6大类，共26种。每种服务都有自己独立的ID，即SID。
SID：Service Identifier，诊断服务ID。UDS本质上是一种定向的通信，是一种交互协，即诊断方(Tester)给ECU发送指定的请求数据（Request），这条数据中需要包含SID，且SID处于该应用层数据的第一个字节。如果是肯定的响应（PositiveResponse），首字节回复
[SID+0x40]，举例子就是请求0x10，响应0x50；请求0x22，响应0x62。如果是否定的响应（Negative Response），首字节回复0x7F，第二字节回复刚才询问的SID。比如Tester请求0x10服务，我想进入编程模式，ECU给出否定响应，首字节0x7F，第二字节回复0x10，代表我否定你的0x10服务请求，第三字节是NRC(否定响应码)，代表我否定你的依据。
通常，在CAN总线中，Addressing information寻址信息会在CAN的帧ID中体现出来，例外是远程寻址，但不常使用。所谓的寻址信息包含了源地址(Source Address)和目标地址(TargetAddress)，就是这条信息是由谁发给谁的，类似于收件人和发件人。当然，ECU回信给Tester时，ECU就变成源地址了。因此源地址和目标地址在UDS中并不是一成不变的。
每一个ECU都有2个CAN的诊断帧ID，分别对应物理寻址的收与发。通常由主机厂来确定不同ECU的这两个特定的诊断ID。比如0x701对应接收Tester的消息，0x709对应发给Tester的消息。
UDS的26种服务
UDS的服务分为6大类，但常用的服务是加背景色的15种。这15种服务又可粗略地划分为权限控制、读取数据/信息、写入数据/信息、通信控制、功能控制这几类（注：这几类是我自己划分的）。
ISO14229-1英文原文中大篇幅的对26种服务进行了解释，英文原文链接如下。学习时如果遇到困惑可以找标准中的相关语句进行翻译，协议是所有学习材料的根本。
本文重点介绍以下几个服务：$10 Diagnostic Session Control（诊断会话），$14 ClearDiagnostic Information（清除诊断信息），$19 Read DTC Information，$22 Read Data ByIdentifier（通过ID读数据），$27 Security Access（安全访问），$2E Write Data ByIdentifier（通过ID写数据），$3E Tester Present（待机握手）。其他的服务楼主有时间会补齐，敬请期待。
UDS应用的设备
在UDS诊断产品中知名度最高，应用最广泛的是德国Vector公司的CAN卡 VN1630/1640 配合其CANoe软件，Vector 产品功能齐全，适合系统级汽车总线开发，被大部分汽车厂商采用。通常工程师先用Vector的CANdela进行cdd文件的开发，之后将该cdd文件导入CANoe.diva中进行功能测试。下面的链接是Vector提供的全套解决方案，里面的CANdesc是UDS代码生成软件。
Vector 产品很好用，节省开发时间，但价格昂贵，不适用于小厂或规模性采购。目前市面上有很多CAN 厂商（如Kvaser, ZLG 等）能提供低成本、体积小、驱动简单、开放API 的设备，很适合进行UDS相关的二次开发。
这篇关于UDS（Unified Diagnostic Services，统一的诊断服务）诊断协议服务的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
