汽车上可能会出现各种各样的故障，比如仪表出现了故障亮灯，汽车已经无法启动，车上出现了奇怪的异响等现象。这些故障绝大多数都是由汽车上的一个又一个的电子控制单元（ECU）负责诊断出来的，并通过仪表报警并提醒驾驶员。

Source：汽车故障灯亮但使用正常 _排行榜大全 (pai-hang-bang.cn)

本文将具体介绍汽车ECU的故障诊断，其核心问题包括：有哪些故障？ECU怎么进行故障诊断？如何进行故障处理？又是如何进行故障修复？本文将回答第一个问题：有哪些故障？

1 整车控制架构概念

将一辆汽车进行彻底拆解，那就会非常多的零件，就如下图所示：

Source: 一大波“报废机动车回用件”正在路上，新版《报废机动车回收管理办法》6月1日起施行

这么多的零件中如果有某个零件出现故障或损坏，要直接识别出故障零件，这将会十分困难。那么如何才能准确而快速地识别出来故障？可以将上面的这些零件从汽车功能系统角度进行分类，也就是说这些零件构成了汽车的各个功能系统（动力系统，底盘系统，车载系统和智驾系统等）。而每个系统又包含多个控制功能，比如动力系统（新能源汽车为例）包括电机控制单元（MCU），电池管理系统(BMS)和高压配电单元（PDU）等，这样这些零件又被细分到各个控制功能单元。以这些控制功能单元为基础，形成了汽车控制架构，如下所示：

Source：【汽车以太网测试】系列之二： 确保新一代车载网络的性能和一致性 - 测试测量

2 电子控制功能单元

聚焦到某一个电子控制功能单元，比如发动机控制功能单元，如下所示：

Source：汽车发动机里所有的传感器的位置图解？- 知乎 (zhihu.com)

其组成是：发动机本体，传感器（位置，温度和转速等），电子控制单元ECU，执行器（电磁阀，执行电机）和执行机构等。

其工作原理是：

ECU先通过采集这些传感器信号和与其他ECU进行通讯，收发一些信号；

ECU再使用复杂的控制逻辑算法，计算得到执行器的控制指令；

执行器最后驱动执行机构，操控发动机机械部件运动，使得发动机按照期望的方式和效果运行。

3 故障类型

不难发现，在控制器层面可以进一步将各种零部件抽象到传感器，通讯，控制器，执行器和机械系统。这就是汽车实施故障诊断的起点，即针对ECU来做故障诊断，诊断哪些故障。按此思路，通常ECU故障分为5种类型：

• 机械/系统故障，主要是指机械部件的故障或多方面因素引起的系统故障。以上述的发动机控制功能单元所涉及的故障为例，像发动机活塞缸损坏，发动机工作温度过高等故障；

• 电子电器故障，主要指传感器和执行器的故障；比如温度传感器信号丢失，或电磁阀烧坏等故障。

• 硬件故障，主要指PCB上控制器和各种芯片的故障；比如电磁阀驱动芯片报过压或欠压等故障。

• 软件故障，主要指ECU软件故障，比如死循环， 除零，溢出等故障；

• 通讯故障， 主要指通讯中断，通讯停止和通讯数据错误等故障。比如CAN通讯信号超时等故障。

为了更具化地理解上述5类故障，这里具体以位置传感器为例说明下电子电器这类故障。就下图所示的位置传感器，一般都会考虑哪些故障？

从两个方面来考虑有哪些故障。

一方面从供电电压来看，是否欠压，是否过压，是否供电短路到地或开路，是否供电短路到电源。比如按照该位置传感器的规格书定义：

电压小于4.75V，属于欠压；

电压大于5.25V，属于过压；

电压小于1V，属于供电短路到地或开路；

电压大于6V，属于供电短路到电源。

另一方面从PWM信号来看，是否PWM信号的占空比是否在有效范围，PWM信号是否堵塞。比如按照该位置传感器的规格书定义：

PWM信号占空比的有效范围为[2%, 98%]。如果PWM信号占空比低于2%，或PWM信号占空比高于98%，属于PWM信号占空比无效。

PWM信号频率的有效范围为[1kHz, 3kHz]。如果PWM信号频率低于1kHz，或如果PWM信号频率高于3kHz，属于PWM信号频率无效。

前文详细介绍了故障的类型，针对这么多的故障，如何进行有效管理？采用诊断故障码（Diagnostic Trouble Code，DTC），即汽车在线诊断系统识别的故障条件的数字通用标识符。

Source：ISO15031-6

1 DTC怎么看

使用DTC指示具体的故障类型，那么通过读取DTC，汽车维修人员就可以确定出现了什么问题，并进行相应的修复。DTC通常由一系列的字母和数字组成，如DTC为P0127，或B0001，或C0031, 或U0105，那它们表示什么意思？

P0127代表进气温度过高

B0001 代表驾驶员正面第1阶段展开控制（子错误）

C0031代表左前轮速度传感器（子错误）

U0105代表与喷油器控制模块通讯丢失

具体怎么看？根据ISO15031-6的DTC定义，如下所示：

Source：ISO15031-6

DTC使用5个字符来表示，如上的四个DTC，每个DTC占用2个字节数据长度。其中：

第1个字符占用2位数据长度，表示故障所属系统，每个数值的具体意义如下：

00 = P，代表动力总成（引擎和传动系统）故障

01 = C，代表底盘故障，如制动系统或底盘控制模块故障

10 = B，代表车身故障，如车身电子系统故障。

11 = U，代表网络通信故障，表示车辆各系统之间的通信故障

Source：ISO15031-6

第2个字符同样占用2位数据长度，表示故障类型，每个数值的意义如下：

00 = 0，代表ISO/SAE标准定义的故障码

01 = 1，代表汽车制造商自定义的故障码

10 = 2，ISO/SAE预留

11 = 3，ISO/SAE预留

第3个字符占用4位数据长度，表示故障所属的子系统，以网络系统为例，

0 代表网络电器

1，2 代表网络通讯

3 代表网络软件

4，5 代表网络数据

具体可参考：ISO15031-6

第4，5个字符占用1字节数据，表示具体故障对象和类型，继续以网络系统为例，

U0101，前三个字符按照上述说明解析，后两字符01代表的具体故障对象和类型是与TCM通讯丢失

U0302，后两字符02代表的具体故障对象和类型是与变速器控制模块软件不兼容

U0405，后两字符05代表的具体故障对象和类型是从巡航控制模块接收到的数据无效

通过上述对DTC定义的解释，就知道怎么看DTC了。DTC可以说是故障类型的"身份ID"，一个DTC映射一个故障类型。

2 DTC格式

DTC格式是根据几个标准协议来定义，比如ISO-14229-1，SAE J2012 OBD DTC和SAE J1939-73等。总的来说，DTC分为non OBD和OBD两种格式，如下所示：

上面讲的都是OBD格式的DTC（省略了0x00），这里介绍了non OBD的DTC，该类DTC包含3个字节数据，其中:

HighByte和MiddleByte这2个字节与OBD的DTC定义一样，对应5位标准故障码（第一位是字母，后四位是数字）；

LowByte表示故障类型，包含了DTC故障类别和DTC故障子类型，它代表了电路或系统中的故障类型（比如传感器开路，传感器对地短路等），具体可参考ISO15031-6

Source：ISO15031-6

其中DTC故障类别的定义如下：

Source：ISO15031-6

当故障类型为一般故障信息(General failure information)时，DTC故障子类型有如下多种：

Source：ISO15031-6

当故障类型为一般信号故障（General signal failures）时，DTC故障子类型有如下多种：

Source：ISO15031-6

为了更好地理解non OBD格式的DTC，再看两个DTC，按照上述的定义说明，如下解释：

B0039-10 代表第1排右前方阶段部署控制 - 一般电器失效

C0031-23 代表左前轮速传感器 – 一般信号故障 - 信号卡在低位

对于上述两种格式，具体怎么区分，可通过DTC格式标志字来区分解析方式来区分解析方式，DTC格式标志字定义如下：

Source：ISO15031-6

在OBD诊断当中用的最多的格式是SAE_J2012-DA_DTCFormat_00，即上面的OBD的DTC格式；在UDS诊断当中用的最多的格式是ISO_14229-1_DTCFormat，即上面的non OBD的DTC格式。需要注意的是，虽然OBD-II标准定义了DTC格式，但不同OEM可能会在其标准之上添加自定义的DTC。因此，对于特定车辆的诊断，最好参考该OEM提供的DTC解释表或相关文档。

3 DTC的16进制表示

通过诊断通信获取的DTC通常是16进制数值，而非5个字符形式，需要转换一下。那么上面例子中字符形式的DTC，如果采用16进制表示，将如何计算？先看个例子：

Source：ISO15031-6

这样不难计算得到文章开头的4个DTC的16进制表示，如下：

以上其实就是将下表的Code categories转换为Hex value的过程。

4 DTC的应用

在故障诊断通信的一些UDS服务中，将会涉及到DTC，比如19服务读取DTC信息：

source: ISO14229-1

这只是DTC应用的一个简单举例，更多应用可参考ISO14229-1。

前面介绍DTC的基本概念，下面将继续介绍DTC的其他信息：DTC状态位。

1 什么是DTC状态位

DTC状态位，即StatusOfDTC，是用来指示DTC所对应的故障是否发生，是否被确认等状态。DTC状态位包含1个字节数据长度，每一位都有具体的定义，如下所示：

但并不是每一位不一定都要使用，具体取决于各OEM的需求，在ISO14229-1中，除了bit3: ConfirmedDTC是强制约束外，其他都没有强制约束。

首先了解几个概念：测试（test），操作循环（operation cycle）和老化（aging）

测试，是指在一个操作循环内，在线诊断软件算法去判断一个组件或系统的故障状态的过程，在一个操作循环，有可能只跑一次测试，也有可能周期性循环地跑测试。

操作循环，定义了测试的开始和结束条件，车身与底盘域一般由OEM或者供应商自己确定(如上下电、休眠唤醒等)，对而动力域还会存在其它标准规定。

老化，被所记录的DTC，如果这个故障不再出现，那就不会一直被记录下去，这时需要通过一个过程：当测试结果连续出现多少次Passed，才可将这个DTC清除，这个过程就叫老化。多少次称为老化阈值。

接着下面开始详细介绍DTC状态每一位的定义：

1.0 DTC status bit0 : testFailed

如果在最近的一次测试结果为Failed，那么相应DTC的状态位bit0就置1。当OEM定义的重置条件满足，或者最近的一次测试结果Passed，或者使用诊断设备执行了清除DTC指令，那么相应DTC的状态位bit0就重置为0，其切换逻辑如下所示，该位初始值为0。

source：ISO14229-1

1.1 DTC status bit1 :testFailedThisOperationCycle

对于当前操作循环是否出现一次测试结果为Failed，如果出现了，则相应DTC的状态位bit1置1。该位初始值为0，如果被置1，那么只有当操作循环改变，或者使用诊断设备执行了清除DTC指令，该位才能被重置为0，如下所示：

source：ISO14229-1

1.2 DTC status bit 2 : pendingDTC

在上一次或当前操作循环是否出现一次测试结果为Failed，如果出现了，则相应DTC的状态位bit2就置1。该位初始值为0，如果被置1，那么只有当前操作循环完成时测试已完成且没出现Failed，或者使用诊断设备执行了清除DTC指令，该位才能被重置为0，如下所示：

source：ISO14229-1

1.3 DTC status bit 3 : confirmedDTC

当检测到的故障次数足够多，需要将相应DTC存入非易失性内存。如果已将DTC已存入非易失性内存，那么该DTC的状态位bit3置1，但该位为1不意味着故障仍然存在，假如测试结果为Passed，则说明这个DTC表示的故障目前已消失。如何重置为0，使用诊断设备执行了清除DTC指令或达到老化阈值等，如下所示：

source：ISO14229-1

1.4 DTC status bit 4 : testNotCompletedSinceLastClear

自从上次故障信息被清除，是否执行了某DTC测试（不管测试结果是什么，只关心是否测了）。如果执行了，则该DTC的状态位bit4置0，如果被置0，那么使用诊断设备执行了清除DTC指令，该位才能被重置为1，如下所示：

source：ISO14229-1

1.5 DTC status bit 5 : testFailedSinceLastClear

自从上次故障信息被清除，是否出现某DTC测试结果为Failed。如果出现了，则该DTC的状态位bit5置1；如果被置1，那么只有当操作循环改变且满足老化阈值条件，或者使用诊断设备执行了清除DTC指令等，该位才能被重置为0，如下所示：

source：ISO14229-1

1.6 DTC status bit 6 : testNotCompletedThisOperationCycle

在当前操作循环，是否执行了对某DTC的测试（不管测试结果是什么，只关心是否测了）。如果执行了，则该DTC的状态位bit6置0；如果被置0，那么使用诊断设备执行了清除DTC指令或当前操作循环完成，该位才能被重置为1，如下所示：

source：ISO14229-1

1.7 DTC status bit 7 : warningIndicatorRequested

某些特殊的DTC会与用户可见的警告指示相关联，比如仪表上的报警灯，或是文字信息等。该DTC的状态位bit7就用于这类DTC，置1则表示服务器请求激活警告指示，置0则表示服务器不请求激活警告指示，具体设置条件如下所示：

source：ISO14229-1

注意，如果这个DTC不支持警告指示，则这个位永远置0。

2 为什么需要DTC状态位

通过上节我们已经知道了DTC状态位的定义，但为什么需要这么定义？或者为什么需要DTC状态位？总的来说，从以下几个方面可以进一步了解到DTC状态位作用：

故障确认：DTC状态位可以用于确认故障是否持续存在。一旦故障被检测到并生成了故障码，相关的DTC状态位可以指示故障是否仍然存在。比如下图所示：

情况1表示是一个瞬时（潜在）故障，情况2表示是一个历史故障，情况3表示是一个当前故障。

故障历史记录：DTC状态位可以记录故障的历史信息。当故障发生时，DTC状态位可以被设置为指示该故障已经发生过，如上情况2的历史故障等。

故障清除和重置：DTC状态位还可以用于指示故障码是否已被清除或重置，比如下图所示：

情况1有种解释是DTC被清除过后没出现过故障，情况2有种解释是DTC被清除过后出现过故障。

另外就是本来DTC状态位显示为故障，如下情况1，执行故障清除指令后，DTC状态位显示已重置，如下情况2。

故障监控：DTC状态位可以用于监控特定系统或组件的故障状态。通过检查DTC状态位的值，可以实时了解故障的出现和消失情况，以便进行故障排除和维护。

可以说，DTC状态位提供了一种有效的方式来管理和跟踪车辆故障的状态和诊断过程。它们有助于提供故障的持续性信息、历史记录、修复状态和监控功能，从而支持更精确的故障诊断和维修。

3 DTC状态位说明

以ISO14229-1中关于DTC状态位在两个操作循环的排放相关的OBD DTC的操作概述进行说明。

Source：ISO14229-1

对照上图所示序号，说明如下：

0 接收到清除故障信息指令 --> 初始化DTC状态位。

1，2 测试执行完成，结果为passed --> DTC的状态位bit4和bit6从1变为0，表明测试已执行，自上次DTC清除指令后，在操作循环1DTC已达到准备就绪状态。

3，4，5，6 测试执行完成，结果出现failed --> DTC的状态位bit2-bit0和bit5从0变为1，表明故障已被检测到，但未被确认（确认需要经过两个操作循环）。

7 测试执行完成，结果又变为passed --> DTC的状态位bit0，从1变为0，表明故障又没出现了。

8 测试执行完成，结果出现failed --> DTC的状态位bit0，从0变为1，表明故障在操作循环1重复出现。

9，10 操作循环1结束操作循环2开始，那么DTC的状态位bit1由1变为0，DTC的状态位bit6由0变为1，这个切换时机具体取决于OEM如何定义。

11 新的操作循环开始，DTC的状态位bit0是否仍然保持上一个操作循环，也取决于OEM如何定义，多次测试执行完成，结果又变为passed --> DTC的状态位bit0，从1变为0，表明故障又没出现了。

12 新的操作循环开始，测试执行完成，结果仍为passed，bit6由1变为0，表示在新的操作循环，测试至少被执行了一次。

13，14 测试执行完成，结果出现failed --> DTC的状态位bit0和bit1从0变为1，表明在新的操作循环，故障已被检测到。

15 DTC的状态位bit3由0变为1，表明故障已经两个操作循环，已被确认。

前文介绍DTC状态位，下面将继续介绍DTC的其他信息：DTC严重程度，DTC快照和DTC扩展数据。

1 什么是DTC严重程度

DTC严重程度占用1个字节数据，包含两部分信息，DTC严重程度信息（3位）和DTC类别信息（5位），如下所示：

source：ISO15031-6

DTC严重程度信息是指一个特定的诊断故障代码的影响程度或严重性。它表明故障的严重性，并帮助确定诊断和处理问题的必要行动的优先次序。严重程度通常对已确定的故障的潜在后果和影响进行分类，ISO14229-1中将其分为三类，如下：

source：ISO15031-6

仅维修（maintenanceOnly）：当诊断代码或警告表明一个非紧急问题或一个需要注意的常规维护任务，但不需要立即采取行动时。它表明该问题应在下一次预定的维护或服务预约中解决。

在下次停车时检查(checkAtNextHalt)：意味着一旦安全，就应该检查或解决某个故障或问题，通常是在下一次停车时。虽然这个问题可能不是一个直接的安全问题，但建议尽早检查，以防止潜在危害或进一步的损害。

立即检查(checkImmediately)：意味着诊断代码或警告表明有一个关键或严重的问题需要立即关注。它表明在安全的情况下，应尽快停止车辆，并采取必要的措施及时解决这个问题。继续驾驶车辆而不解决这个问题可能会带来安全风险或造成进一步的损害。

具体的定义和严重程度会因制造商和所使用的诊断系统的不同而不同。

DTC等级信息是指根据受影响的系统或部件对DTC进行的分类或分级，适用于符合WWH-OBD GTR的OBD系统。其中A类、B1类、B2类或 C是与排放有关的DTC的属性，这些属性描述了故障对排放或对OBD系统监测能力的影响，具体定义如下：

source：ISO15031-6

2 什么是DTC快照信息

DTC快照信息是通过UDS协议获取的一种特定数据记录，用于帮助诊断车辆故障。根据ISO 14229标准的规定，DTC快照信息就类似照相机一样，在故障发生的时刻，对整车信息按下快门，做个记录，以便后续分析问题。

DTC快照信息可以包括多个方面的数据，如故障码、故障条件、传感器数据、控制单元状态等。下图为发动机控制相关的DTC快照信息，包括发动机冷却液温度，节气门位置，发动机转速，车速等信息，如下所示：

source：ISO14229-1

这些DTC快照信息规定的方式进行记录和存储，然后可以通过诊断仪发送特定的UDS请求来获取。总的来说，DTC快照信息提供了一个详细的故障现场记录，这样技术人员在故障诊断和维修过程中能够更准确地了解故障发生时的车辆状态和参数，可以分析故障发生时的数据差异，确定潜在的故障源，并采取相应的修复措施。

需要注意的是，ISO 14229标准中的DTC快照信息并非所有车辆都支持或实现。具体的车辆型号和制造商可能会根据自己的需求和设计选择是否支持和提供DTC快照信息功能。

3 什么是DTC扩展数据

DTC扩展数据是指与诊断故障码相关的附加信息，它提供了更详细的故障描述、故障发生条件、故障影响等方面的数据：

故障描述：提供了关于故障的详细描述，例如故障类型、故障位置、故障原因等。这些描述可以帮助技术人员更好地理解故障的性质和特征。

故障发生条件：描述了故障发生的条件和环境。这包括诊断条件、车辆状态、传感器数据等。了解故障发生的条件可以帮助技术人员在诊断过程中模拟相似的条件，以便更好地复现和解决故障。

故障影响：说明了故障对车辆性能和功能的影响。这包括对安全性、驾驶性能、排放性能等方面的影响。了解故障的影响可以帮助技术人员评估故障的紧急程度和优先级，并采取适当的修复措施。

故障解决建议：提供了针对特定故障的解决建议和修复步骤。这些建议可以包括检查项目、维修流程、替换部件等。技术人员可以根据这些建议来进行故障诊断和修复操作。

这些信息的具体内容一般都由客户来定义。DTC扩展数据是通过通用诊断测试和编程通信协议（UDS）进行获取和交换的，如下示意：

source：ISO14229-1

技术人员向车辆的ECU发送特定的请求，以获取与DTC相关的扩展数据，这样技术人员更准确地诊断和解决车辆故障。

在本系列前4篇文章中介绍了汽车ECU有哪些故障以及如何用DTC来表示，其逻辑如下：

关于DTC的这些信息如何被应用，将能从后续UDS的19服务的介绍中得到更深入的理解。本文开始将继续回答第二个问题：ECU怎么进行故障诊断？

1 故障诊断系统

汽车上任何零件或任何零件间都有可能出现故障，即使故障的概率极低，但也没法完全保证无故障。我们只能尽可能去识别潜在的故障，最大限度去避免人员伤害。所以汽车各个ECU都有各自的故障诊断系统，去检测是否有故障，如果有故障，一方面要采取临时措施最大限度减小伤害，另一方面保存故障信息，以供后续排查和解决故障。因此可以ECU故障诊断系统简单分为两块：车内在线诊断系统和车外离线诊断系统。下面就具体介绍这两块内容：

1.1 车内在线诊断系统

车内在线诊断系统是指ECU会在什么条件下，用什么逻辑去检测是否有故障，以及如何进行故障处理。

以汽车ECU故障诊断功能解析系列1 (qq.com)的位置传感器为例，假设需要诊断PWM信号占空比无效这个故障。根据该位置传感器的规范说明可知，PWM信号占空比的有效范围为[2%, 98%]，那么该如何诊断？

首先，明确多久监控一次，是周期性监控还是间断触发监控？本例中位置传感器用来监测曲轴位置，也就是发动机运行的实时状态，这个信号的有效性至关重要，那么就应该采用周期性监控方式，比如10ms就监控一次。

然后，怎么检测故障，根据定义，这里检测故障的逻辑可设定为PWM信号占空比是否在[2%,98%]，若不在，出现一次失效。出现一次失效是否就意味着故障产生呢？也不一定，通常会采用防抖（Debounce）算法，通过累计一定的数量或者时间确认故障是否发生。

其次，记录哪些故障相关数据，即在故障产生过程中，需要记录一些相关数据，以便后续技术或维修人员查找故障和分析故障产生的原因，比如之前文章提到的快照信息和扩展数据等，定义具体需要记录哪些信号。

最后，如何进行故障处理，当故障确认发生，这时需要采取相应的故障处理措施，比如功能降级，以及点亮相对应的故障灯，显示在仪表，提醒驾驶员。

1.2 车外离线诊断系统

上述车内在线诊断系统中记录了故障的相关数据，这些数据将会被技术或维修人员使用。具体来说，就是技术或维修人员使用外部的诊断设备（比如诊断仪）做一些获取故障信息的操作，他们还可能会使用诊断仪去做清除故障和更新软件等操作。这里把支持做这些操作的系统称为车外离线诊断系统，如下所示：

通过上图可理解为：车外离线诊断系统是一个关于故障诊断的通讯系统，其实它是基于UDS服务的诊断通讯系统，即外部的诊断设备（比如诊断仪）发送请求，然后ECU响应回复。比如使用诊断仪请求读取PWM信号占空比的故障信息，ECU验证通过，就会响应回复DTC，DTC状态位，DTC严重程度以及其他数据；或者使用诊断仪清除故障，那么ECU响应回复故障是否清除；或者使用诊断仪更新软件，那么ECU响应回复软件更新的实时进程。

也就是说车外离线诊断系统的核心是UDS服务，其定义可参考ISO14229-1，总的来说，按功能划分，UDS服务可分为6类，共26种服务，分别是：

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

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

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

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

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

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

UDS服务具体应用可参见后续文章的详细介绍。

1.3 小结

通过上述对两个系统的介绍，我们就清楚了：汽车出现故障过程中，车内在线诊断系统在起作用，它会检测故障，确认故障，处理故障，它会尽可能减少人员伤害，记录故障相关数据等，当汽车返修时，维修人员进行查因和维修，会使用车外离线诊断系统，查看故障信息、查找原因和更新软件操作等。这两个系统通过AutoSAR实现的架构如下所示：

前面对故障诊断系统的基本介绍，本文将其中的Debounce进行详细说明。

1 为什么需要Debounce

故障诊断中使用debounce（去抖动）的原因是为了解决信号抖动问题。信号抖动是指在电路中接收到一个短暂的不稳定信号，可能是由于电源噪声、开关的物理特性或其他干扰因素引起的。当进行故障诊断时，通常需要监测输入信号的状态，并根据信号状态进行相应的判断和操作。如果信号存在抖动，可能会导致误判，从而产生错误的诊断结果。

为了解决这个问题，就引入了debounce算法。具体来说，故障诊断策略判断出现了潜在故障信号，那么就会启动一个计时器/计数器，在计时器/计数器运行期间，如果检测到信号的状态发生变化，计时器/计数器会被重置。只有在计时器/计数器到达设定的稳定时间/次数后，才能确认故障。这样通过debounce算法，可以消除因信号抖动而带来的误判问题，提高故障诊断的准确性和可靠性。

2 Debounce算法

故障诊断步骤是先进行故障检测，即根据前提条件和判断条件实时监控，判断是否有潜在的故障。通常采用4个状态（PREPASSED、PASSED、PREFAILED、FAILED）来表示判断的结果，对于有些故障，不需要经Debounce算法确认故障，这时判断的结果只有PASSED和FAILED,直接得到确认的故障；而对于有些故障，可能只是某些信号波动引起，不是故障，姑且称为潜在的故障，这时引入PREFAILED和PREPASSED来表示，需要采用Debounce算法才能进一步确认是否为故障。当前常用Debounce算法有基于计数器的Debounce算法和基于时间的Debounce算法两种。

2.1 基于计数器的Debounce算法

该算法使用一个Debounce计数器（计数范围取决于具体的定义）用来记录判断的结果，当根据前提条件和判断条件得到一次PREFAILED状态，那么计数器（Fault Detection Counter）会增加一个步长，以此不断累加，当累计计数达到设定的Failed限值时，故障状态就变成Failed，即潜在故障被确认，如下图t1时刻。

有些故障被确认后，是有可能被恢复的，也就是说只要根据前提条件和判断条件得到一次PREPASSED状态，那么计数器（Fault Detection Counter）会减小一个步长，以此不断减小，当达到设定的Passed限值时，故障状态就变成Passed，即故障已消除，如下图t2时刻。

对于上图中的两个值Jump down value,和Jump up value)，此处需要再解释一下，所谓Jump down value是指故障被确认处于Failed状态，如果下一次根据检测的前提条件和判断条件得到PREPASSED状态，这时计数器的数值不会从设定的FAILED限值开始减小一个步长，而是跳到Jump down value开始减小一个步长。同理去理解Jump up value，这两个值均由用户自定义。

2.2 基于时间的Debounce算法

该算法使用一个Debounce计时器（范围同样为-128到127）用来记录判断的结果，当根据前提条件和判断条件得到一次PREFAILED状态，那么计时器（Fault Detection Counter）开始计时，累计一段时间t_failed，仍然没有出现PREPASSED或PASSED状态，那么故障状态就变成Failed，如下图t1时刻；在t failed内，如果出现FAILED状态，那么故障状态就直接变成Failed，即故障被确认，如下图t4时刻。

当故障被确认了，接着当根据前提条件和判断条件得到一次PREPASSED状态，那么计数器归零，开始重新计时，同理一直PREPASSED状态，累计一段时间t_passed后，表示故障已消除。如下图t2时刻。

当故障被确认了，接着当根据前提条件和判断条件得到一次PASSED状态，那么计数器不需要累计时间，直接表明故障已消除，如下图t3时刻。

2.3 小结

通过上述两种Debounce算法可以知道其原理是：根据检测到“故障”状态（PREFAILED, FAILED, PREPASSED, PASSED）来增减计数器或定时器，只有次数或时间达到阈值，才能确认或消除故障。当报告的状态是PREFAILED时，计数器或定时器就累加一次；当累加次数或时间到Failed的域值，那么“故障”就被确认。其中的一些参数需要被定义清楚，因为这些参数将会决定故障需要多长时间确认或恢复，像上图中的步长，阈值和时间等参数。比如某个故障的确认时间为200ms，计数器每5ms计数一次，假设设定阈值为40，报告状态切换时，计数器总是从0开始计数，那么这时针对故障确认的固定步长设置为1。

总之，不同Debounce算法的细节处理会有所不同，可根据实际诊断需求来配置Debounce算法参数。另外，针对不同故障类型的确认，如何选用这两种Debounce算法。通常，对于timeout类故障，可采用基于时间的Debounce算法来完成确认；对于事件触发类故障，则可采用基于计数的Debounce算法来完成确认。

在本系列前6篇文章中介绍了DTC和故障诊断系统的部分内容，如下：

本文将再补充一些故障诊断相关的概念信息，包括愈合与老化，驾驶循环和点灯，以此将能够基本读懂故障诊断列表的需求。

1 愈合（Healing）& 老化(Aging)

愈合：是指一段时间或多个操作循环内，某个DTC状态Bit7不再置位，关闭指示灯的行为。

对于愈合，诊断方案中会定义好愈合条件和愈合时间，比如针对转速传感器信号范围过高故障，假设转速信号超过15000rpm持续100ms会报该故障，点灯提示驾驶员。相应地定义愈合条件为转速信号小于15000rpm，并且愈合时间超过100ms，那么就可以关灯取消提示。

老化：是指某个失效事件或DTC在一定次数的操作循环内不再出现时，将该DTC对应的存储信息从内存中清除的行为。

对于老化，诊断方案中会定义重置确认状态的驾驶循环数和移除故障的暖机循环数等信息。比如同样比如针对转速传感器信号范围过高故障，假设重置确认状态的驾驶循环数为1和移除故障的暖机循环数为30，那么当故障愈合后，如果经过了1个驾驶循环，那么故障确认状态将被重置；如果经过了30个暖机循环，那么故障快照信息和扩展数据将从内存中清除。

2 驾驶循环(Driving cycle) & 暖机循环(Warm up cycle)

DTC老化是一个以循环周期作为单位的过程。通常循环周期采用驾驶循环和暖机循环，如上例子。那么到底什么驾驶循环，又什么是暖机循环？

驾驶循环：汽车完成点火，运转（若车辆存在故障应能被检测到），熄火的完整过程称为一个驾驶循环。ISO14229定义如下：

暖机循环：发动机经充分运转，使冷却温度比发动机启动时上升至少20℃，并达到一个最低温度70℃的过程。一般是针对排放相关DTC所设定的循环周期。

通常定义三四十个暖机循环作为故障码清除的条件，因为在相对较长过程中，如果车辆没再发生这个故障，则可认为是一个偶发的现象，车辆处于相对稳定的状态，则可将这个故障码清除。

3 点灯

当某个DTC状态Bit7置位，开启指示灯。这里：

对于乘用车来说，点灯是指点亮MIL（Malfunction Indicator Lamp），灯，即故障报警指示灯。该灯用来迅速提示驾驶员出现了故障。

source: 汽车仪表盘故障灯图解(大全)，记住这10个就行|用车知识 - 驾照网 (jiazhao.com)

而对于商用车来说，故障码虽然通过驾驶座的指示灯指示，但其标准J1939定义了四种不同的灯，分别是：

MIL（Malfunction Indicator Lamp，故障指示灯）)，该灯由OBD指南规定，用于指示与尾气有关的故障。

RSL（Red Stop Lamp，红色刹车灯）)，指示需立即停车的严重错误。

AWL（Amber Warning Lamp，琥珀色警示灯）)，指示无需停车的一般错误。

PL（Protection Lamp，保护灯）)，该灯用于指示非电子设备引起的错误，例如，清洗液水位过低或发动机冷却温度过高。

所有灯都定义了四种状态：关闭，开启（稳定状态），以1Hz频率闪烁和以2Hz频率闪烁。

前文章中介绍了DTC和故障诊断系统的部分内容，如下：

这些内容基本为介绍故障诊断列表做好了铺垫，本文将通过一个例子从正向设计角度定义故障诊断列表。

source：CDD文件——CANdelaStudio_诊断协议那些事儿的博客-CSDN博客

案例：电源电压监测--过压，欠压

注意：本例子数据的数值均为虚构，重在辅助具象化故障诊断的正向开发，以下内容也并非考虑到了故障诊断正向开发的所有关键点，重在展现故障诊断的正向思考或开发过程。

电源电压KL30给某ECU供电，通常硬件电路路径是：KL30通过接插件的电源引脚输入给ECU，ECU硬件电路将对KL30做保护，通断和滤波等处理，然后KL30给ECU的电源管理芯片PMIC，以及一些执行器的驱动芯片供电。当然这些电子器件有相应的供电范围要求，所以需要监测KL30，即增加相应的硬件采集电路，将采集的电压输入给微控制器，最终通过软件逻辑判断电源电压是否正常。

因此，电源部分的硬件电路可简化成如下所示逻辑：

这里，我们的目标是需要监测KL30是否出现过压，欠压故障。针对这两个故障：

首先，定义它们的DTC。采用OBD格式的DTC，如下表定义：

其对应十六进制格式表示则对应为：0x0562和0x0563。

相关内容可参考：汽车ECU故障诊断功能解析系列2 (qq.com)

然后，如何实施故障诊断。

已知KL30正常范围为9V到16V；KL30高于16V过压，处于过压状态时，如果KL30低于15V，则可恢复正常；KL30低于9V欠压，处于欠压状态时，如果KL30高于10V，则可恢复正常，如下所示：

当然，对于硬件采集电路输入给微控制器的V_k30的电压并不能等于KL30的电压值，通常低于5V范围，假设V_k30与KL30的电压值成比例关系，V_k30=KL30电压/4，则有：

参照 汽车ECU故障诊断功能解析系列5 (qq.com)的思路：

1）MC。对于电源电压，一直在供电，故应该实时监测，设置为周期性监测，10ms一次。

2）FC。根据已知部分提供的信息，判断逻辑为：

V_K30高于4V，则电源电压过压；V_K30低于2.25V，则电源电压欠压。

3）Debounce算法。考虑到电源电压可能收到干扰等因素出现偶然的尖峰，因此需要采用Debounce算法，采用基于时间的Debounce算法，Debounce时间为500ms。

4）处理策略。电源电压过压或欠压将可能导致ECU相关的功能出现异常，这时应该立马提醒驾驶员，比如点亮警告灯，在仪表显示。

5）存储策略。考虑到电源电压故障与排放不相关，那么不需要存储该故障相关的快照信息和扩展数据信息。

如果电源电压过压或欠压故障后，其电压范围又恢复到正常范围，这时是不是应该删除这个故障信息？因此，这里第一步是需要如何判断确认的故障是不是消除了，即确定愈合策略，包括愈合条件和愈合时间。

根据已知部分提供的信息，愈合的判断逻辑可设置为：当电源电压过压时，一旦V_K30低于3.75V，持续500ms，则警告灯熄灭；当电源电压欠压时，一旦V_K30高于2.5V，持续500ms，则警告灯熄灭。

第二步是故障真的消除了，原先故障确认时存储的相关信息是不是应该清除，那么根据怎样策略逻辑来确定，即确定老化策略。对这两个故障，故障愈合后，设置为经过1个驾驶循环，故障确认状态被重置；经过30个暖机循环，故障快照信息和扩展数据从内存中被清除。

参考：汽车ECU故障诊断功能解析系列7 (qq.com)

因此根据上述故障诊断的正向开发过程，我们可以得到故障诊断列表的两条故障，如下所示：

这样通过本例实施正向设计后，就得到故障诊断列表的核心内容，希望你以后在项目中看到这个列表的时候不再陌生。就本人经历，不同公司对于故障诊断列表定义内容会稍有不同，但其核心内容还是本例所列举的。