诊断协议那些事儿

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

关联文章：
UDS的应用场景
UDS的OSI模型
UDS服务列表

文章目录

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

一、诊断的起源

诊断的概念来源于医学，当我们人出现头晕、发烧、呕吐、骨折等不适症状时，去医院就诊，医生会通过询问（什么时候、吃了什么东西或者闻到什么等）、观察，甚至仪器（CT、血检等）检测，最终对病症做出判断，并给出合理建议的过程。这个过程就是一个医学上的诊断服务过程。

车辆诊断的过程也有类似的地方，“车生病了，车主也需要去给其看病”，外部诊断设备，通过通信媒介（CAN、LIN、以太网等）连接车辆，获取车辆状态信息，为了能够快速准确的判断车辆或者某个控制器的故障以及故障原因，从而在不拆解整车的情况下为维修提供可靠的依据。

诊断是确定、检查和分类系统的症状，目的是获得整体情况。

二、UDS是什么？

Unified Diagnostic Services：统一诊断服务，简称UDS，是在汽车电子环境下的一种诊断通信协议！
形象理解-就是通过一套标准的服务，对当前汽车进行数据操作。
UDS

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

1.1 为什么汽车需要诊断？

随着电子技术与汽车技术相结合，电子技术的不断发展，驾驶员对于车辆不再仅仅满足于代步功能的需求，迫切要求提高车辆的动力性、舒适性、经济性和安全性。因此ECU数量不断增加，由最初的几个到现在上百个。数量的不断增加虽满足了驾驶员的新需求，但给车辆售后维修带来了极大的挑战，难以判定故障类型的问题。从20世纪80年代起，美欧等地汽车制造商开始在电喷系统上装备车载自诊断模块（On-Board Diagnostics Module），便于快速界定车身发生故障部位，方便售后维修（现代车载诊断功能不仅仅局限于此）。
vector
①汽车网络复杂性的增加
②汽车ECU的增加
③控制策略复杂性的增加
④诊断策略的增加——电子控制系统的安全容错处理（汽车不能因为ECU自身的突发故障导致汽车失控和不能运行）
⑤法规和标准（如：功能安全ISO26262）
⑥排放标准
⑦质量控制
⑧召回风险管控

1.2 诊断的基本原理

自诊断模块能在汽车运行过程中实时监测电控系统及其电路元件的工作状况，如有异常，根据特定的算法判断出具体的故障，并以诊断故障代码(DTC，Diagnostic Trouble Codes)的形式存储在汽车电脑芯片内。可以为车辆的维修和保养提供帮助，维修人员可以利用汽车原厂专用仪器读取故障码，从而可以对故障进行快速定位，故障排除后，采用专用仪器清除故障码。

OBD的工作原理（参考）：汽车在正常运行时，汽车的电子控制系统输入和输出的信号（电压或电流）会在一定的范围内有一定规律地变化；当电子控制系统电路的信号出现异常且超出了正常的变化范围，并且这一异常现象在一定时间（几个连续行程）内不会消失，ECU 则判断为这一部分出现故障，故障显示灯点亮，同时监测器把这一故障以代码的形式存入存储设备中，被存储的故障代码在检修时可以通过故障显示灯或 OBDⅡ诊断仪来读取。如果故障不再存在，监控器在连续 3 次未接收到相关信号后，将指令故障显示灯熄灭。故障显示灯熄灭后，发动机暖机循环约 40 次，则故障代码会自动从存储器中被清除掉。

1.3 诊断的应用领域

广泛应用于开发、生产、售后等各个领域。
dev
结合ISO14229诊断服务看，车辆诊断的作用涉及故障检测（DTC）、程序升级、EOL下线检测（车型配置、IO控制）、读取软硬件版本号/VIN等。

1.4 诊断实现模型

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

2.服务S（诊断服务）

诊断通信机制：基于C/S架构的请求/响应机制
Client客户端：诊断请求的提出者——Tester（诊断仪）
Sever服务器：诊断响应的提供者——ECU（电子控制单元）
service
诊断报文：不同于常规的总线周期性应用程序报文或网络管理NM报文，诊断报文是典型的事件触发型报文，有请求时才会响应。

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

2.1 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 请求具有永久状态的与排放相关的诊断故障代码

2.2 ISO14230

kwp2000

2.3 ISO14229

UDS
详情请查阅：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等），实现了模块化诊断，Tester诊断设备只要发送同样的命令就可以得到ECU的数据，而不关心底层的数据链路层和物理层是怎么实现的。在协议中定义诊断通信的准则：诊断请求、诊断响应的规则；诊断服务类型；ECU处理诊断请求的规则、诊断请求和诊断响应的内容；诊断通信的参数，数据传输的准则等等。