聊一聊诊断

摘要：

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

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

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

1 整车控制架构概念

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

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

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

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

2 电子控制功能单元

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

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

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

其工作原理是：

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

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

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

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

4 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映射一个故障类型。

5 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解释表或相关文档。

6 DTC的16进制表示

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

Source：ISO15031-6

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

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

7 DTC的应用

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

source: ISO14229-1

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

8 什么是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。

9 为什么需要DTC状态位  

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

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

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

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

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

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

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

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

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

10 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，表明故障已经两个操作循环，已被确认。

11 什么是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 

12 什么是DTC快照信息

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

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

source：ISO14229-1  

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

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

13 什么是DTC扩展数据  

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

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

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

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

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

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

 source：ISO14229-1   

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

DTC 

         

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

14 故障诊断系统  

汽车上任何零件或任何零件间都有可能出现故障，即使故障的概率极低，但也没法完全保证无故障。我们只能尽可能去识别潜在的故障，最大限度去避免人员伤害。所以汽车各个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种服务。

15 为什么需要Debounce  

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

         

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

16 Debounce算法  

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

基于计数器的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，这两个值均由用户自定义。

基于时间的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时刻。

来源 | 汽车与基础软件