故障诊断案例分析--技术篇

之前分享了几篇与故障诊断相关的文章，偏向于原理或理论部分，本文将结合一个故障诊断案例，温顾下这些知识。

1 故障诊断案例介绍

本案例来自于一个变速箱控制单元TCU的市场反馈问题，驾驶员在行驶过程中看到仪表出现了档位电磁阀开路的故障，然后导致车辆无法挂挡，进而不能继续行驶。因此这是一个非常严重的质量问题，引起了高层的绝对重视，迅速组织相关人员展开问题调查。这里档位电磁阀的背景知识是：

1）电磁阀是PWM驱动形式的开关型电磁阀；

2）电磁阀采用高边驱动（几个电磁阀共用），低边开关（每个电磁阀独立）的控制方法，电磁阀的每路高边和低边分别有观测量反馈到控制器，如下图的左边部分所示；

2）电磁阀的引脚被焊接连接线束，线束另一端也被焊接连接到接插件母端，接插件母端与其公端通过插拔形式连接,公端被焊接到PCB上，如下图的右边部分所示：

2 问题的分析与验证

市场问题最开始总是模糊的，一般都只听说到出了啥问题，但其他情况就模糊不清了，因为信息已经经过多手的传递，有时连一个最基本的信息都不确定，比如问题能不能复现，所以这类问题总是需要花费大量的时间和人力去解决。就从本案例开始，这个问题能不能复现？--不能；确定吗？--不能百分之百确认，客户抱怨，箱子已经换新的了。故障件在哪里呢？--在返回的路上。有采集故障发生的历史数据吗？--有的，马上发给你。等等....这就是一个大概的开始过程。

首先，我们进行故障发生时的基本情况了解，包括故障发生的时间，地点，频次，工况，记录和后果等。通过掌握故障发生的工况，试图去复现它。同时故障会显示在仪表盘是一定通过了一系列的软件逻辑判断得出来的，因此我们同时从软件逻辑上来查找有哪些情况会出现。这里就从软件逻辑角度来分析，如之前文章故障诊断架构是先检测有没有失效发生，然后通过Debouncing算法来确认是不是故障，再确认故障后，该如何去处理故障，点灯报告故障。

关于第1步，先检测有没有失效发生，通过监控条件Mc和失效条件Fc来实施，也就是需求应该定义好什么时候要去检测电磁阀，以及如何检测有没有失效？针对本案例电磁阀的开路故障，关于Mc，比如所有的电磁阀处于关闭状态，那么基于现有的电路情况，是无法检测出来没有没开路，就不需要去检测了。当然此时需求定义是需要检测的话，那么可能就需要增加额外的电路来支持。关于Fc, 比如电磁阀的低边反馈正常工作应该为高电平，而出现开路时，则为低电平，那么就可以根据低边反馈这个信号来检测电磁阀是否出现失效。这部分逻辑本质上来源于对硬件电路，通过对硬件电路的分析，列举出各种故障，包括对电源短路，对地短路，开路，并结合实际应用情况（电磁阀开启的组合）制定相应的诊断逻辑，以此作为软件开发的需求。

通过第1步，我们就得出了电磁阀开路失效的前提是一定有硬件的断路，否则不可能去报开路故障。这时，一方面我们是相信该结论，因此我们就从连接电路去分析，是否可能因为硬件上出现的偶尔性断路引起。这是非常棘手的问题，按常理说硬件要是断了那就是断了，哪还能断了还恢复的，但现象就是有开路，因此从硬件连接分析，会有哪些薄弱的连接点，比如对于焊接点采用X射线去照射排查，对于车上的应用环境，排除是否振动，冲击引起瞬时的断路，对问题件进行后续的振动与冲击测试。另一方面我们再次加强该结论，比如我们排查是否会出现短路故障，但却报开路故障。因此制造一些短路的工况去验证。

在第1步只是分析了关于失效的软件逻辑，而失效如何被确认为故障，即第2步的Debouncing算法，如下图所示基于计数器的Debouncing算法：

通过第1步判断报告失效的状态，是PREFAILED还是PREPASSED还是其他？一般情况下，当检测出失效，会报告PREFAILED的状态，否则报告PREPASSED。

当报告PREFAILED的状态时，则计数器就会累加一个固定步长，当计数器计数累加到了设定的Failed阈值，那么失效将被确认为故障；而当报告PREPASSED的状态时，则计数器就会累减另一个固定步长，当计数器计数累减到了设定的Passed阈值，那么故障将被治愈而消除。这就是一种基于计数器的Debouncing算法的运行原理，这里会涉及的一些参数需要在需求里面定义清楚，因此为这些参数将会决定故障需要多长时间确认或恢复，像上述提到的固定步长和阈值。比如针对电磁阀开路故障，需求定义确认时间为200ms，计数器每5ms计数一次，假设设定阈值为40，报告状态切换时，计数器总是从0开始计数，那么这时针对故障确认的固定步长设置为1。

通过第2步，我们就能分析到开路诊断的确认时间是否合理，从故障发生可能对零部件危害，车辆行驶安全等影响分析，来有需要优化当前的确认时间。当故障出现，是否需要采取什么措施来确认行车安全，即第3步的故障响应处理和点灯机制。关于故障响应处理，比如某个档位的电磁阀开路了，是否会有其他档位来替代，或采取跛行模式等，这些就可以向应用层软件的提供方来支持。关于点灯机制，像电磁阀开路这种故障是否需要展示给驾驶员，这方面考虑主要是希望驾驶员看到故障信息后，能主动采取措施来规避危险，如果不能，能否以等效的其他提醒。

以上就是一个结合实际问题的故障诊断案例，希望通过对这个解决过程的基本叙述，一方面能够了解故障诊断的实际应用，另一方面也能够介绍了实际问题的解决思路。

作者：谦益行
文章来源：上汽零束SOA开发者论坛 
原文链接：https://bbs.z-onesoft.com/omp/community/front/api/page/mainTz?articleId=7726