【汽车故障诊断9】一文了解离线诊断系统

最新推荐文章于 2025-03-17 07:30:00 发布

谦益行

最新推荐文章于 2025-03-17 07:30:00 发布

阅读量548

点赞数 8

文章标签：汽车网络服务器

本文链接：https://blog.csdn.net/menghuyouyou/article/details/145979559

版权

本系列前面8篇文章是关于在线诊断系统的内容，从本文开始介绍离线诊断系统，即与UDS服务有关的内容。

Source：ISO14229-1

在刚进入汽车行业时，在主机厂，经常看有些同事拿着诊断仪去车上查故障和清故障，很好奇这诊断仪到底有什么魔法；后来我转到供应商做应用软件开发，常常听负责诊断模块的同事提UDS服务；最后我转做底层软件开发了，终于有了机会揭开UDS服务的神秘面纱。本文将先从三个方面进行概括性的介绍：

什么时候用UDS服务
什么是UDS服务
如何了解UDS服务

1 什么时候用UDS服务

我们知道UDS服务是用在车外离线诊断系统，而会用到车外离线诊断系统的有开发人员和维修人员。其中，开发人员包括软件和系统的开发与测试人员等，这些人员需要确保该系统的所有功能被正确实现，也能被正确使用。比如曾经作为底层软件开发人员，会使用UDS服务来刷写软件，测试UDS各个服务是否满足需求，查看故障码和清除故障码等操作。

Source：UDS - Unified Diagnostic Services - ISO 14229 | Vector

而维修人员，作为UDS服务的使用者，针对已经出现了故障的车辆，这些维修人员将会使用这个车外离线诊断系统，即使用诊断仪接入车辆的OBD接口，再使用UDS服务去读取故障信息，清除故障信息和其他操作。

source: AA wots goin on ere then? On Board Diagnostics - OBD - trefor.net

2 什么是UDS服务

上面我们知道开发人员和维修人员都会使用到UDS服务，那么到底什么是UDS服务？我们先一起了解下什么是诊断服务。

可以类比到人看病：某人生病了去看医生，通常过程是这样，医生先问病人有什么症状，持续了多久等信息，然后病人回答，然后医生开出相对应的检查，病人去检查，等病人的检查结果出来后，医生可能就能确定是什么病，开药，这样一个看病过程就相当于诊断服务。

也可以对应到汽车，驾驶员可能看到仪表的故障灯点亮或者感受到汽车的行驶状态异常，那么驾驶员就会开车去修理中心。然后修理人员会用诊断仪器查找故障和清除故障等操作。这样一个过程就是诊断服务的过程。

source：Figure 4 from Automotive Diagnostics Communication Protocols

通过上述两个例子，不难发现诊断服务都是需要一问一答的方式，也就是请求和响应，以这种形式实现某些功能。将上面的第二个例子再细化分析：当维修人员通过诊断仪使用UDS服务请求故障信息，此时是需要对应的ECU响应这个请求，将故障信息发送给诊断仪。

也就是说UDS服务需要通过请求与响应的通讯机制来实现诊断服务功能，在ISO14229中，定义了UDS（Unified Diagnostic Services，统一诊断服务）诊断协议是用于汽车行业诊断通信的需求规范，UDS服务有6类功能，26种服务，分别是：

1）诊断和通信管理功能单元，包括10，11，27，28，3E，83，84，85，86，87共10种服务；

2）数据传输功能单元，包括22，23，24，2A，2C，2E，3D共7种服务；

3）存储数据传输功能单元，包括14，19共2种服务；

4）输入输出控制功能单元，包括2F服务；

5）例行程序功能单元，包括31服务；

6）上传下载控制功能单元，包括34，35，36，37，38共5种服务。

对于这些服务，只是在应用层面的定义，它们是既可以通过CAN通讯来实现，也可以通过其他总线来实现。ISO14229协议定义UDS在OSI参考模型的位置，如下图红圈所示：

Source：ISO14229-1

通常，我们只关注应用层，即ISO14229-1协议。该协议提供的是一个诊断服务的基本框架，对于主机厂和零部件供应商，可以根据实际情况选择实现其中的一部分，也可以自定义一些私有化的诊断服务。

3 如何了解UDS服务

对于UDS服务，需要了解两部分内容，一部分上面提到的26种服务的定义与应用，可通过ISO14229-1来了解；另一部分是UDS服务的CAN通讯机制，可通过ISO15765了解。

3.1 ISO14229-1

对于ISO14229-1, 当然最重要的是理解里面定义的每一个服务及其应用，比如比如诊断仪请求10 03，然后ECU响应50 03 00 32 01 F4。

source: 汽车诊断obd-概览_哔哩哔哩 (゜-゜)つロ干杯~-bilibili

同时也可以向上抽象一层，从原理性的视角来看这些服务，即该协议中第7章关于应用协议控制信息，如下图定义了部分协议数据单元：

Source：ISO14229-1

关注红框内容，基于上面的例子，A_Data指的是10 03，50 03 00 32 01 F4，这里10 03中10，50 03 00 32 01 F4中50，对应A_Data中的A_PCI，又根据A_PCI的定义，10和50更准确的称呼是SI。

Source：ISO14229-1

另外，A_PCI还有一种形式，如下所示，UDS服务的负响应格式，后续文章会提及。

Source：ISO14229-1

A_Data组成部分除了A_PCI，还有Parameters，这些Parameters可能是sub-function（SF），也可能是data-parameter等，见后续文章。

Source：ISO14229-1

这样就了解到UDS服务的抽象定义，那么后续就能更好地理解各个服务的服务请求/响应行为的具体定义。

Source：UDS - Unified Diagnostic Services - ISO 14229 | Vector

3.2 ISO15765

对于上面的例子：诊断仪请求10 03，然后ECU响应50 03 00 32 01 F4，这个请求与响应的通讯过程具体是怎样的呢？简单地说是：诊断仪先发送一个诊断服务请求给ECU，这里诊断仪称为客户端或测试端，ECU称为服务端；然后ECU根据诊断服务按一定的机制响应给诊断仪。如果根据ISO14229协议定义，通讯涉及请求，响应，确认，通知4个过程，如下所示：

source: ISO14229-1

如果UDS服务基于CAN总线来实现，那么上述的请求和响应的信息都将通过CAN报文传输，具体的传输机制就需要根据ISO15765协议来实现。针对请求和响应存在数据超过8个字节的情况，该ISO15765协议提出了单帧和多帧的传输机制：

source: ISO15765

3）实战

当然上面两个ISO标准将能帮助你从理论掌握UDS服务，但是最关键还是需要自己通过项目实战来作更深入理解。如果你是软件开发人员，你将会使用代码来实现具体的UDS服务的逻辑；如果你是软件测试人员，你将会通过对每一项服务的测试，请求什么，然后响应是什么，将能极大帮助你深入理解它们。总之纸上得来终觉浅，绝知此事要躬行！