目录
回顾接触UDS的过程
自21年毕业后，我一直干了2年的Autosar CAN通讯开发。
开发的主要内容简单概括就是：应用报文开发、网管报文开发、休眠唤醒开发，及CAN网络相关故障开发，并没有涉及UDS开发，但虽然没有涉及开发，但多多少少都听过一点（特别是后来跑路的时候，恶补了学习了一手，嘿嘿）。
我刚开始接触诊断相关内容的时候，对诊断没有任何概念。所以听到同事们讨论什么SID啦、DID啦，DTC啦，什么27啦。
不能说听得不太懂，只能说一脸懵逼。
小小的脑瓜大大的问号，SID？SID是什么？怎么还有DID，DTC？它们是什么关系，他们是一个类别的东西吧？长得这么像！
所以就百度，好了，假设你是一个对UDS诊断没有任何概念的小白。你看看百度出来的东西。
你看看上面这图，我就问你，你说这是小白能看懂的东西吗？？什么每种服务都有自己独立的ID，我连服务是什么鬼都不知道，我看得懂才怪了。
所以，我连SID的概念都花了好久才搞明白。
于是，我问同事，有没有什么资料能够学习UDS，然后，他们都告诉我，让我看14229-1和15765-2这两个标准文档。
然而，一个文档三四百页，内容这么多，怎么看啊，主要是，对小白来说，如此多内容的文档，是很难捉住重点的，这样就很费劲了。
有一次，领导把我派去了测试部支援3天，让我跟着一个测试部的同事测UDS的内容，想起来也挺不好意思，这3天我也没帮到什么忙，主要是不懂这些数据，举个小栗子，看下面这张图。
这一串串数据，让一个对诊断没有任何概念的小白来看哪里能看懂啊。
后来，我明白了什么是SID、DID，什么又是DTC，诊断报文的这些数据要怎么看。
但是，由于没有具体开发过UDS，因此并不知道这些东西具体是怎么去开发的。比如19服务有个DTC状态码，这个状态码是要怎么开发？是Autosar配置工具配置的吗？还是不需配置静态代码已经全部实现？
两年过去，在换了一个企业后，有机会开始正式开发UDS和对UDS进行完整的测试，让我对UDS从概念上的认识进入到了UDS各个具体内容开发的认识。
下面就开始讲一下我理解的UDS基本概念。
UDS基本概念
UDS的作用
当一辆汽车出现故障的时候，维修人员会拿着诊断仪接上汽车，然后读取出车上的故障信息，这样就知道车上什么地方出故障了。（这只是其中一个功能，另外还有软件升级、标定等等。）
能实现山上面这个过程，就是因为有UDS的存在。
我们所说的诊断UDS开发，就是代码实现上面图中“ECU-A”的诊断功能。最终使得ECU-A能够根据诊断仪的请求，返回对应的数据信息。
UDS的宏观认识
就像地球总共由7块大陆组成一样。且先不管UDS的具体细节内容，UDS世界总共由以下这些“大陆板块”组成：
大家把这些大陆板块称之为：SID，即：诊断服务ID，简称“服务” 。每一个服务都有它的独特的职能。(车企常用到的每个服务后续我会每个都写一篇去展开描述。)
整个UDS都是围绕上面这些服务展开的，服务下面又会有子服务。这就好比“国家”的概念。“国家”是不会做事情的，做事情的是“国家”下面的各个“部门”，你可以把各个诊断服务理解为各个“国家”，子服务理解国家下面的“部门”。
举个栗子：28服务（CommunicationControl）有下面的这些子服务。
28服务它的作用是通讯控制，但是真正具体干活的是它的各个子服务，比如0x00：使能报文的发送和接收。
UDS的CAN通讯链路
UDS的最终目的，是如一开始那张图。告诉诊断仪自己的故障信息、通过诊断仪升级软件、标定等等。
而通讯总线，就是实现这些功能的媒介。
所谓的UDSOnCan，其实就是字面意思：基于CAN总线的UDS。
大家都知道，汽车上不止有CAN总线，可能还有LIN总线、以太网等等。所以，UDS还可以“On”在其它总线上。我们这里讲的是UDSOnCan，如下图。
从上面这张官方标准的图就可以看出UDS在整个CAN通讯中的链路了，但会比较抽象。
所以我按照Autosar的架构画了下面的图，UDS的整个链路如下图红色线所示：
UDSOnCan相关协议如下图示。
11898：这个是关于CAN总线的相关标准。比如它会描述CANH、CAHL的电平要求是多少、一帧CAN报文的结构定义、关于CAN Tranceive的一些要求等等。从上面的图中也可以看到，不只是诊断报文的这部分要满足11898，网管报文、应用报文也是同样要满足这个。实际上，所有的CAN报文，都得满足11898。
15765-2：这个就是诊断报文的传输协议标准，比如发送多帧时要如何发送，每帧的时间间隔等等。
14229-1：到这一层，才是真正打开UDS的世界，具体的UDS功能都在这个标准文档中定义。
诊断开发。一般来说实际上是指CANTP模块（15765-2）、DCM模块和DEM模块（14229-1）。
UDS的报文种类
UDS总共有3种报文。物理请求报文、功能请求报文、响应报文
我们先来讲一下为什么会有这3种诊断报文。
由于一辆汽车上有十几个ECU。因此，诊断仪对车上ECU的操作共有两种情况。
①对某一个ECU单独进行操作。比如读取某一个ECU的故障信息、升级某一个ECU的软件
②同时对所有ECU进行操作。比如整车处于唤醒过程中，大家都在往外发送报文，总线负载率相对较高。但诊断人员现在需要对某一个ECU升级软件，总线负载率高可能会影响，因此，需要先让所有的ECU都停止发送应用报文。这时候就需要通知所有ECU停发应用报文。
根据上面第①种情况。就出现了第一种诊断报文类型：物理请求报文。每个ECU都有自己唯一的诊断物理地址。当ECU接收到物理地址是指向自己的诊断报文时就要根据这帧报文的请求内容做出对应的操作。简单来说，就是一对一。
根据上面第②种情况。就出现了第二种诊断报文类型：功能请求报文。在同一个CAN网络上所有ECU的功能地址是一样的。在同一个CAN网络，当ECU接收到功能地址的诊断报文时都要根据这帧报文的请求内容做出对应的操作。简单来说，就是一对多。
好了，物理请求报文和功能请求报文都是ECU要接收的诊断报文，ECU接收到诊断报文后需要回应。因此就出现了第三种诊断报文类型：响应报文。
上面的描述可以用下面两张图表示：
物理请求示例如下图所示，诊断仪发送物理请求报文(红色)，ECU接收到后，回应响应报文(蓝色)
功能请求示例如下图所示：诊断仪发送功能请求报文(红色)，ECU接收到后，回应响应报文(蓝色)
另外需要注意的是：物理请求报文是支持回应多帧的。而功能请求报文只支持回应单帧。这在15765-2中8.3.2.4就有说明。
到这里为止。关于UDS的一些基本概念应该就差不多了。接下来我会先讲一下15765-2，即UDSOnCan的“OnCan”，也即CANTP层。
返回目录：
171
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
