UDS协议发展历史

Posted 2022-12-06 诊断协议那些事儿

诊断协议那些事儿

本文为诊断协议那些事儿专栏首篇文章，旨在介绍诊断的起源、发展历史，让读者对诊断有一个基本的认识。

---

文章目录

• 诊断协议那些事儿
• 一、诊断的起源
• 二、UDS是什么？
• • 1.诊断D（诊断通信协议）
  • • 1.1 为什么汽车需要诊断？
    • 1.2 诊断的基本原理
    • 1.3 诊断的应用领域
    • 1.4 诊断实现模型
  • 2.服务S（诊断服务）
  • • ①ISO15031
    • ②ISO14230
    • ③ISO14229
  • 3.统一U（可以基于任意总线）
• 总结

---

一、诊断的起源

诊断的概念来源于医学，当病人出现头晕、发烧、呕吐、骨折等不适症状时，去医院就诊，医生通过询问、观察，或者仪器（CT、血检等）检测，利用数据对病症做出判断，并给出合理建议的过程。
车辆诊断的过程也有类似的地方，外部诊断设备，通过通信媒介（CAN、LIN、以太网等）连接车辆，获取车辆状态信息，为了能够快速准确的判断车辆或者某个控制器的故障以及故障原因，从而在不拆解整车的情况下为维修提供可靠的依据。

二、UDS是什么？

Unified Diagnostic Services：统一 诊断 服务，形象理解-就是通过一套标准的服务，对当前汽车进行数据操作。

1.诊断D（诊断通信协议）

1.1 为什么汽车需要诊断？

随着电子技术与汽车技术相结合，电子技术的不断发展，驾驶员对于车辆不再仅仅满足于代步功能的需求，迫切要求提高车辆的动力性、舒适性、经济性和安全性。因此ECU数量不断增加，由最初的几个到现在上百个。数量的不断增加虽满足了驾驶员的新需求，但给车辆售后维修带来了极大的挑战，难以判定故障类型的问题。从20世纪80年代起，美欧等地汽车制造商开始在电喷系统上装备车载自诊断模块（On-Board Diagnostics Module），便于快速界定车身发生故障部位，方便售后维修（现代车载诊断功能不仅仅局限于此）。

①汽车网络复杂性的增加
②汽车ECU的增加
③控制策略复杂性的增加
④诊断策略的增加
⑤法规和标准
⑥排放标准
⑦质量控制
⑧召回风险管控

1.2 诊断的基本原理

自诊断模块能在汽车运行过程中实时监测电控系统及其电路元件的工作状况，如有异常，根据特定的算法判断出具体的故障，并以诊断故障代码(DTC，Diagnostic Trouble Codes)的形式存储在汽车电脑芯片内。可以为车辆的维修和保养提供帮助，维修人员可以利用汽车原厂专用仪器读取故障码，从而可以对故障进行快速定位，故障排除后，采用专用仪器清除故障码。
OBD的工作原理（参考）：汽车在正常运行时，汽车的电子控制系统输入和输出的信号（电压或电流）会在一定的范围内有一定规律地变化；当电子控制系统电路的信号出现异常且超出了正常的变化范围，并且这一异常现象在一定时间（几 个连续行程）内不会消失，ECU 则判断为这一部分出现故障，故障显示灯点亮，同时监测器把这一故障以代码的形式存入存储设备中，被存储的故障代码在检修时可以通过故障显示灯或 OBDⅡ诊断仪来读取。如果故障不再存在，监控器在连续 3 次未接收到相关信号后，将指令故障显示灯熄灭。故障显示灯熄灭后，发动机暖机循环约 40 次，则故障代码会自动从存储器中被清除掉。

1.3 诊断的应用领域

广泛应用于开发、生产、售后等各个领域。

结合ISO14229诊断服务看，车辆诊断的作用涉及故障检测（DTC）、程序升级、EOL下线检测（车型配置、IO控制）、读取软硬件版本号/VIN等。

1.4 诊断实现模型

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

2.服务S（诊断服务）

诊断通信机制：基于C/S架构的请求/响应机制
Client客户端：诊断请求的提出者——Tester（诊断仪）
Sever服务器：诊断响应的提供者——ECU（电子控制单元）

各个协议规定了不同的服务，不同的诊断服务代表着不同的功能，具体如下：

①ISO15031

服务	描述
01	Request current powertrain diagnostic data 请求当前动力总成诊断数据
02	Request current powertrain diagnostic data 请求当前动力总成诊断数据
03	Request emission-related diagnostic trouble codes 请求与排放相关的诊断故障代码
04	Clear/Reset emission-related diagnostic information 清除/重置排放相关诊断信息
05	Request oxygen sensor monitoring test results 请求氧气传感器监测测试结果
06	Request on-board monitoring test results for specific monitored systems 请求特定监控系统的车载监控测试结果
07	Request emission-related diagnostic trouble codes detected during current or last completed driving cycle 请求在当前或上次完成的驾驶循环中检测到的与排放相关的诊断故障代码
08	Request control of on-board system, test, or component 请求控制车载系统、测试或组件
09	Request vehicle information 请求车辆信息
0A	Request emission-related diagnostic trouble codes with permanent status 请求具有永久状态的与排放相关的诊断故障代码

②ISO14230

③ISO14229

详情请查阅：UDS诊断服务列表

3.统一U（可以基于任意总线）

①OBD：On-Board Diagnostics
第一代OBD（OBD-I）
i.加州环保局（CARB）1985年立法，1988年开始实施
ii.要求对硬件失效（包括氧传感器、废气在循环阀、供油系统和发动机系统）实施监控
iii.没有统一的故障码和通讯协议标准
第二代OBD（OBD-II）
建立了标准化故障码和通讯协议标准

②ISO 14230：Keyword Protocol 2000（KWP2000）
该协议实现了一套完整的车载诊断服务，并且满足 E-OBD（European On Board Diagnose）标准。最初使用K-Line串行传输，最大通信速率10.4Kbps。由于 K 线物理层和数据链路层在网络管理和通讯速率上的局限性，使得 K 线无法满足日趋复杂的车载诊断网络的需求。而 CAN网络（Controller Area Network）由于其非破坏性的网络仲裁机制、较高的通讯速率（可达 1M bps）和灵活可靠的通讯方式被广泛使用，发展为基于CAN总线的KWP2000（ISO 15765）。

③ISO 15765 Diagnostic On CAN
基于CAN总线传输，最大速率达1Mbps

④ISO 15031 On-Board Diagnostic（OBD）
与排放相关的诊断通信，是由法规要求，具有强制标准需要参照的，最初目的是环保（同时方便售后维修）。

⑤ISO 14229-1：Unified Diagnostic Services
定义了诊断服务，只是一个应用层协议，不涉及网络，可以基于任意总线。
与OBD最大的区别就在Unified（统一）上，它是面向整车所有ECU的，而OBD是面向排放系统ECU的。

因为全球有许多OEM，假如每家OEM都定义自己的诊断通信标准，则会造成社会资源不必要浪费（Supplier要根据不同OEM搭建功能实现平台）。因此定义统一的诊断协议，让大家都遵守，避免浪费社会资源，这也是ISO组织定义车载诊断行业标准的目的（ISO 14229、ISO 15765、ISO 14230、ISO 15031等）。在协议中定义诊断通信的准则：诊断请求、诊断响应的规则； 诊断服务类型；ECU处理诊断请求的规则、诊断请求和诊断响应的内容；诊断通信的参数，数据传输的准则等等。

---

总结

以上就是今天要讲的内容，本文仅仅简单介绍了UDS的起源和发展，还有许多值得去挖掘和研究的内容，后续小编会不断介绍ISO协议，以此来加深对诊断的理解。