零、UDS诊断命令备忘录
一、简介
UDS（Unified Diagnostic Services，统一的诊断服务）诊断协议是在汽车电子ECU环境下的一种诊断通信协议，在ISO 14229中规定。它是从ISO 14230-3（KWP2000）和ISO 15765-3协议衍生出来的。“统一”这个词意味着它是一个“国际化的”而非”公司特定的”标准。到目前为止，这种通信协议被用在几乎所有由OEM一级供应商所制造的新ECU上面。这些ECU控制车辆的各种功能，包括电控燃油喷射系统（EFI），发动机控制系统，变速箱，防抱死制动系统(ABS)，门锁，制动器等。
诊断工具与车内的所有控制单元均有连接，且这些控制单元均启用了UDS服务。不同于仅使用OSI模型第一层、第二层的CAN协议，UDS服务使用OSI模型的第五层和第七层（会话层和应用层）。服务ID（SID）和与服务相关的参数包含在CAN数据帧的8个数据字节中，这些数据帧是从诊断工具发出的。
目前市面上的新车都具有用于车外诊断的诊断接口，这使得我们可以用电脑或诊断工具（业内称为测试器Tester）连接到车辆的总线系统上。因此，UDS中定义的消息可以发送到支持UDS服务的控制器（业内称ECU）。这样我们就可以访问各个控制单元的故障存储器或用新的固件更新ECU的程序。除此之外，UDS还用于下线检测时把一些信息（如VIN码）写入到汽车的各个零部件中。这些功能也是UDS最为核心的功能。
为什么我们要设计UDS这样的诊断协议呢？在汽车诊断协议诞生之前，修车只能靠师傅的经验，因为汽车零部件不会告诉你它哪里出了问题。但有了诊断协议之后，一旦零部件出了问题或者出过问题，它们会把故障信息保存在内存里面，维修师傅就可以通过通信总线读取这些故障信息，比如一个ECU经历欠压故障之后，它会将欠压故障代表的DTC（诊断故障码）存储起来，可选择性保存的还有发生故障时的快照信息（比如此时的车速、读到的电压值等）。快照信息有助于测试工程师和售后技师查找发生故障的原因。
除了CAN总线以外，UDS也可在不同的汽车总线（例如 LIN, Flexray, Internet 和K-line）上实现。
如下图所示，ISO 14229也就是UDS协议仅对应用层、会话层做出了定义。这里有个疑问，UDS专指ISO 14229-1吗？这种说法是不对的，UDS包含了ISO 14229下属的7个子协议，其中ISO 14229-2还是会话层的，所以UDS仅包括应用层的说法也是错误的。
说明下，我们本篇文章我们仅使用CAN来描述UDS。对于CAN来说，物理层和数据链路层遵循ISO 11898协议；网络层方面，Classical CAN仅有8个字节的数据场与应用层处理多帧数据的需求构成了矛盾，ISO 15765-2协议解决了该问题，我们用CAN的8字节数据场会腾出一到两个字节的做法，来体现网络层的控制信息。
排放相关的诊断内容，即ISO 15031-5主要针对OBD协议，为法规强制要求燃油车满足的协议，电动车是无需满足的。燃油车通常既满足UDS协议，又满足OBD协议，这两个协议不冲突。小伙伴们有没有发现UDS协议的服务ID(SID)最小的是0x10，那是因为小于0x10的服务是OBD协议中规定的。
学习UDS之前，希望您对CAN的基础知识有初步的了解，知道一个CAN帧的基本构成，熟悉至少一种CAN盒的使用方法。协议方面，应通过PPT、论文、原版英文协议重点学习ISO 15765-2和ISO 14229-1的协议内容，之后可以将Git上的开源UDS协议栈移植到你熟悉的嵌入式平台上，进行数据收发；或使用CAN盒与支持UDS诊断的设备进行数据收发，对UDS有一个大致的认识。切记知行合一，实践很重要。
摘自ISO 14229-1-2013
摘自ISO 14229-1-2013
摘自恒润科技公开资料
摘自恒润科技公开资料
二、UDS的服务
UDS本质上是一系列服务的集合。UDS的服务包含6大类，共26种。每种服务都有自己独立的ID，即SID。
SID：Service Identifier，诊断服务ID。UDS本质上是一种定向的通信，是一种交互协议（Request/Response），即诊断方(Tester)给ECU发送指定的请求数据（Request），这条数据中需要包含SID，且SID处于该应用层数据的第一个字节。如果是肯定的响应（Positive Response），首字节回复[SID+0x40]，举例子就是请求0x10，响应0x50；请求0x22，响应0x62。如果是否定的响应（Negative Response），首字节回复0x7F，第二字节回复刚才询问的SID。比如Tester请求0x10服务，我想进入编程模式，ECU给出否定响应，首字节0x7F，第二字节回复0x10，代表我否定你的0x10服务请求，第三字节是NRC(否定响应码)，代表我否定你的依据。
肯定响应和否定响应的形式一定要熟悉。
通常，在CAN总线中，Addressing information寻址信息会在CAN的帧ID中体现出来，例外是远程寻址，但不常使用。所谓的寻址信息包含了源地址(Source Address)和目标地址(Target Address)，就是这条信息是由谁发给谁的，类似于收件人和发件人。当然，ECU回信给Tester时，ECU就变成源地址了。因此源地址和目标地址在UDS中并不是一成不变的。
UDS的寻址模式分两种，一种是物理寻址（点对点、一对一），根据物理地址的不同进行访问，但只能访问单个ECU节点，Tester为SA源地址，ECU作为TA目标地址；对应的，另一种是功能寻址（广播、一对多），根据功能的不同进行访问，它能访问多个ECU节点，对于标准帧来说，通常是0x7DF。
每一个ECU都有2个CAN的诊断帧ID，分别对应物理寻址的收与发。通常由主机厂来确定不同ECU的这两个特定的诊断ID。比如0x701对应接收Tester的消息，0x709对应发给Tester的消息。
UDS的26种服务
UDS的服务分为6大类，但常用的服务是加背景色的15种。这15种服务又可粗略地划分为权限控制、读取数据/信息、写入数据/信息、通信控制、功能控制这几类（注：这几类是我自己划分的）。
ISO14229-1英文原文中大篇幅的对26种服务进行了解释，英文原文链接如下。学习时如果遇到困惑可以找标准中的相关语句进行翻译，协议是所有学习材料的根本。...
一、简介
UDS（Unified Diagnostic Services，统一的诊断服务）诊断协议是在汽车电子ECU环境下的一种诊断通信协议，在ISO 14229中规定。它是从ISO 14230-3（KWP2000）和ISO 15765-3协议衍生出来的。“统一”这个词意味着它是一个“国际化的”而非”公司特定的”标准。到目前为止，这种通信协议被用在几乎所有由OEM一级供应商所制造的新ECU上面。这些ECU控制车辆的各种功能，包括电控燃油喷射系统（EFI），发动机控制系统，变速箱，防抱死制动系统(ABS)，门锁，制动器等。
诊断工具与车内的所有控制单元均有连接，且这些控制单元均启用了UDS服务。不同于仅使用OSI模型第一层、第二层的CAN协议，UDS服务使用OSI模型的第五层和第七层（会话层和应用层）。服务ID（SID）和与服务相关的参数包含在CAN数据帧的8个数据字节中，这些数据帧是从诊断工具发出的。
目前市面上的新车都具有用于车外诊断的诊断接口，这使得我们可以用电脑或诊断工具（业内称为测试器Tester）连接到车辆的总线系统上。因此，UDS中定义的消息可以发送到支持UDS服务的控制器（业内称ECU）。这样我们就可以访问各个控制单元的故障存储器或用新的固件更新ECU的程序。除此之外，UDS还用于下线检测时把一些信息（如VIN码）写入到汽车的各个零部件中。这些功能也是UDS最为核心的功能。
为什么我们要设计UDS这样的诊断协议呢？在汽车诊断协议诞生之前，修车只能靠师傅的经验，因为汽车零部件不会告诉你它哪里出了问题。但有了诊断协议之后，一旦零部件出了问题或者出过问题，它们会把故障信息保存在内存里面，维修师傅就可以通过通信总线读取这些故障信息，比如一个ECU经历欠压故障之后，它会将欠压故障代表的DTC（诊断故障码）存储起来，可选择性保存的还有发生故障时的快照信息（比如此时的车速、读到的电压值等）。快照信息有助于测试工程师和售后技师查找发生故障的原因。
除了CAN总线以外，UDS也可在不同的汽车总线（例如 LIN, Flexray, Internet 和K-line）上实现。
如下图所示，ISO 14229也就是UDS协议仅对应用层、会话层做出了定义。这里有个疑问，UDS专指ISO 14229-1吗？这种说法是不对的，UDS包含了ISO 14229下属的7个子协议，其中ISO 14229-2还是会话层的，所以UDS仅包括应用层的说法也是错误的。
说明下，我们本篇文章我们仅使用CAN来描述UDS。对于CAN来说，物理层和数据链路层遵循ISO 11898协议；网络层方面，Classical CAN仅有8个字节的数据场与应用层处理多帧数据的需求构成了矛盾，ISO 15765-2协议解决了该问题，我们用CAN的8字节数据场会腾出一到两个字节的做法，来体现网络层的控制信息。
排放相关的诊断内容，即ISO 15031-5主要针对OBD协议，为法规强制要求燃油车满足的协议，电动车是无需满足的。燃油车通常既满足UDS协议，又满足OBD协议，这两个协议不冲突。小伙伴们有没有发现UDS协议的服务ID(SID)最小的是0x10，那是因为小于0x10的服务是OBD协议中规定的。
学习UDS之前，希望您对CAN的基础知识有初步的了解，知道一个CAN帧的基本构成，熟悉至少一种CAN盒的使用方法。协议方面，应通过PPT、论文、原版英文协议重点学习ISO 15765-2和ISO 14229-1的协议内容，之后可以将Git上的开源UDS协议栈移植到你熟悉的嵌入式平台上，进行数据收发；或使用CAN盒与支持UDS诊断的设备进行数据收发，对UDS有一个大致的认识。切记知行合一，实践很重要。
摘自ISO 14229-1-2013
摘自ISO 14229-1-2013
摘自恒润科技公开资料
摘自恒润科技公开资料
二、UDS的服务
UDS本质上是一系列服务的集合。UDS的服务包含6大类，共26种。每种服务都有自己独立的ID，即SID。
SID：Service Identifier，诊断服务ID。UDS本质上是一种定向的通信，是一种交互协议（Request/Response），即诊断方(Tester)给ECU发送指定的请求数据（Request），这条数据中需要包含SID，且SID处于该应用层数据的第一个字节。如果是肯定的响应（Positive Response），首字节回复[SID+0x40]，举例子就是请求0x10，响应0x50；请求0x22，响应0x62。如果是否定的响应（Negative Response），首字节回复0x7F，第二字节回复刚才询问的SID。比如Tester请求0x10服务，我想进入编程模式，ECU给出否定响应，首字节0x7F，第二字节回复0x10，代表我否定你的0x10服务请求，第三字节是NRC(否定响应码)，代表我否定你的依据。
肯定响应和否定响应的形式一定要熟悉。
通常，在CAN总线中，Addressing information寻址信息会在CAN的帧ID中体现出来，例外是远程寻址，但不常使用。所谓的寻址信息包含了源地址(Source Address)和目标地址(Target Address)，就是这条信息是由谁发给谁的，类似于收件人和发件人。当然，ECU回信给Tester时，ECU就变成源地址了。因此源地址和目标地址在UDS中并不是一成不变的。
UDS的寻址模式分两种，一种是物理寻址（点对点、一对一），根据物理地址的不同进行访问，但只能访问单个ECU节点，Tester为SA源地址，ECU作为TA目标地址；对应的，另一种是功能寻址（广播、一对多），根据功能的不同进行访问，它能访问多个ECU节点，对于标准帧来说，通常是0x7DF。
每一个ECU都有2个CAN的诊断帧ID，分别对应物理寻址的收与发。通常由主机厂来确定不同ECU的这两个特定的诊断ID。比如0x701对应接收Tester的消息，0x709对应发给Tester的消息。
UDS的26种服务
UDS的服务分为6大类，但常用的服务是加背景色的15种。这15种服务又可粗略地划分为权限控制、读取数据/信息、写入数据/信息、通信控制、功能控制这几类（注：这几类是我自己划分的）。
ISO14229-1英文原文中大篇幅的对26种服务进行了解释，英文原文链接如下。学习时如果遇到困惑可以找标准中的相关语句进行翻译，协议是所有学习材料的根本。...
