间歇性网络故障的排除
开篇：润墨网以专业的文秘视角，为您筛选了一篇间歇性网络故障的排除范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
当今的电子产品可以说是日新月异，作为越来越普及和离不开的高档产品，汽车必然也会由此不断更新，车辆模块化和网络化、多种网络并存是必然的发展方向。处在维修第一线的我们对此会深有感触，随之而来的变化可能会使一部分维修人员处理相关故障时感觉个个都是“嫌疑犯”，不知从何处下手，如果再加上是间歇性的，那可以说是雪上加霜。本文以2个案例的检修简单地了解一下车辆的网络，以及对此类故障排除的一些方法。
故障1
关键词：电子稳定控制系统（VSES）
故障现象：一辆2010年产别克昂科雷运动型多功能车，行驶里程3万km，搭载3.6 L发动机和全时四驱系统。车辆在行驶过程中间歇性出现电子稳定控制系统（VSES）故障灯点亮。检查历史故障码，分别是：DTC U2100——控制器局域网（CAN）总线通信；DTC U2142——与横向偏摆率传感器（YRS）失去通信：DTCC0710——向盘位置信号：DTC C0186——横向加速计电路（有时）；DTC C0196——横向偏摆率电路（有时）。
该车此前进行过2次维修：第1次来厂，VSES故障灯间歇点亮，清除故障码后试车，故障未再现，于是交车，但不久后故障灯又再次点亮。第2次进厂检修，维修人员调取故障码，与上次一样且都为历史码。通过检查发现2后轮在外更换过，大小与前轮不一致，怀疑这会影响车辆稳定控制系统工作，于是要求更换轮胎，更换轮胎后反复试车，故障未出现，于是再次将车交换客户。不幸的是，不久后车辆因此问题第3次进厂了。
检查分析：笔者接车后首先用专用诊断仪TECH2查看故障码，有以上故障码。通过分析故障码可以发现：首先故障是与网络通信有关，其次是出现网络故障的范围主要集中在底盘高速网络上（图1）。它们的信息是通过高速网络传递给其他控制单元及诊断接口DLC的6号和14号针脚（图2），电子制动控制单元（EBCM）同时处在这2个网络中。最后，底盘高速网络中转向盘位置信号、横向加速计信号以及横向偏摆率信号可作为突破口。查看TECH2数据，很快发现一个明显异常：“转向盘位置”一直为86°（图3）不动，正常情况下随着左右转动转向盘数值有正负值的变化。
是否因为这些信号出现异常影响到底盘高速网络，于是重点检查转向盘位置传感器线路，拆开转向盘位置传感器插接器测量：5号脚点火电压12V正常，6号脚搭铁良好。测试底盘高速CAN—H串行数据线3号和37号脚：2.5～3.5 V，CAN-L串行数据线2号和24号脚：1.5～2.5 V（无短路、断路）。断开EBCM控制单元插接器测量通断也是良好的，测试线路未见异常。
笔者决定更换转向盘位置传感器，进行对中学习后查看数据流：“转向盘位置”在-525°～+525°变化，完全正常。没有直接证据表明转向盘位置传感器存在故障，并且再次装回旧的转向盘位置传感器，数值变化也正常了。为防止再次返工，于是利用TECH2监控连续试车，重点捕捉颠簸路面试车数据。试车结束后仔细查看和比对捕捉的数据流，结合实际试车路况发现了异常：在转弯路口过一个较大减速带时，数据流中“转向盘位置”瞬间保持在53。不变，数据流中的“VSES失败”也由否变为是，但很快又恢复正常（图4）。虽然未能马上点亮故障灯，但已经足够表明故障依然未排除。
根据以上检查分析可能原因：线路因振动接触不良、短路或控制单元因振动出故障。故障又是间歇性出现，因简易程度及可能性下一步重点还是检测线路。为了验证这一假想且更直接地把故障再现出来，排查相关线路和控制单元的过程中，当一人用手晃动EBCM线束插接器，另一人边转方向边看TECH2内数据时，发现相关数据出现异常。严重时仪表中挡位信息也无显示，这是因为挡位信号是变速器控制单元（TCM）接收到挡位开关信号后，通过相关的CAN网络串行数据线送给仪表的，而因为CAN网络链中EBCM处出现异常，导致整个网络链中故障的出现。而其中“转向盘位置”信号也是因为类似原因导致故障。
故障排除：基本故障点已确认，处理EBCM线束插接器，分解端子注入导电胶并固定（图5）。反复试车、查看数据流及交车给客户使用故障末再出现，至此故障完全排除。
故障2：
关键词：偏摆及侧向加速度传感器控制单元
故障现象：一辆2011年产别克GL8豪华商务车，行驶里程6万km。因ABS故障灯亮、电子稳定系统故障灯亮进厂维修。读取故障码，有多个C类故障码：DTC C056D——电子控制单元硬件；DTC C0121——阀继电器电路故障；DTC C0800——控制模块电源回路等。还有网络通信故障：DTC U0121——发动机控制单元（ECM）与电子制动控制单元失去通信；DTC U0121——变速器控制单元（TCM）与电子制动控制单元失去通信：DTC U0140——ECM与车身控制单元失去通信；DTC U0100——车身控制单元（BCM）与发动机控制单元失去通信等多个u类故障码。EBCM有时用专用诊断仪GDS+MDI无法通信，于是更换EBCM，但更换后，尝试模块编程，不能成功进行（因为还是有时不能通信），还多了DTC C056E——电子控制单元软件（图6），并且故障依旧。
检查分析：笔者接车后了解到情况：更换EBCM前后DTC基本一样，之前维修人员更换EBCM依据是EBCM内的DTCC056D——电子控制单元硬件，维修手册对此故障码的说明是“硬件、内部故障、不涉及外部电路等”（图7），并且检查EBCM控制单元的电源、搭铁无异常。分析DTC又是有关网络通信的故障，范围也是缩小到底盘高速网络以及底盘高速网络中的主要控制单元EBCM有时不能通信。
笔者根据电路图（图8）先对这明显单一网络（也是双线高速一种）故障进行测量，通过诊断接口DLC的12及13号脚测量其网络静态终端电阻，约为60.1Ω（图9）正常；测试CAN-H和CAN-L线路的电压，无对搭铁或电源短路，也无开路。通过简单的以上测量可以说明在这个网络中连接线路通信是没问题的，于是接下来主要针对EBCM进行测量。
再次检查影响EBCM控制单元工作的电源、搭铁和唤醒线。查看EBCM内的数据流发现有异常：“系统电压”在0～11 V不停跳动，正常应是稳定的蓄电池电压，（图10中为8.27 V）。对照“防抱死制动系统电路图（控制单元电源、搭铁和子系统参考）”（图11）测量线路，电源1号脚、25号脚电压12 V且用试灯测试明亮，搭铁13号脚、38号脚与负极电阻为0.5 Ω正常，处理各搭铁点也未发现异常；EBCM控制单元启用的唤醒线35号脚，在休眠状态时为0 V，唤醒时为12 V，也非常正常；线插接器也未发现接触不良等异常现象。
是什么原因导致数据流中的电压不稳定，这应正是间歇产生U类码、诊断仪GDS+MDI无法通信的原因，但实际测试似乎相关电源和搭铁都没有问题。再次仔细阅读所有EBCM电路图，发现EBCM还为转向角传感器（B99）及偏摆及侧向加速度传感器（B119）提供电源及搭铁，16号脚为它俩提供搭铁，打开点火开关32号脚提供12 V电源（图12）。分别断开转向角传感器B99、偏摆及侧向加速度传感器B119插接器进行测试，结果搭铁线路正常，但电源线路2087在连接着B119测B99的电源时有异常，只有2.75 V且不稳定（图13）；但连接着B99测B11g的电源就是正常的12 V。测量EBCM、B99和B11g问的12 V电源线2087无接触不良、短路等异常。恢复线路，但不连接B11g插接器，然后再次查看EBCM控制单元内数据“系统电压”为稳定的12 V电压，至此故障已基本明了。
故障排除：更换偏摆及侧向加速度传感器控制单元（B119），故障完全排除。由于EBCM、B99、B119是共用2087电路，B119传感器内部故障造成此电路电压不稳定，进而影响到EBCM的正常工作，相应的网络通信在此电路电压过低时就会出现中断。
回顾总结：车辆网络故障通常会有包括U类在内大量的故障码，面对大量的故障码和故障现象，可能会使人茫然，不知从何下手。对于处理此类故障我认为首先应通过诊断仪读取全车故障码，并分析维修方向：全车网络通讯故障；单个网络有通讯问题；只有一个控制单元问题。然后根据以上方向来制定具体检测方法。
（1）全车网络通讯情况都有问题的，主要检查诊断仪的连接状态、DLC（X84数据链路连接器）的针脚连接状态和电源及搭铁线路、DLC至网关BCM的连接线束及BCM本身状态、电源及搭铁等。
（2）单个网络无通讯主要是对该网络连接具体的测量。刚好这2个案例都是底盘高速网络出现问题，就此说明如下：首先要通过DLC测量高速网络静态终端电阻，正常值约为60Ω；其次测量CAN-H和CAN-L线路的电压，是否对搭铁或电源短路、是否开路等，如有必要可以用示波器去观察、对比故障车与正常车波形信号的差异（正常情况是CAN·H为2.5～3.5 V和CAN-L为1.5～2.5 V的方波信号），并加以分析判断。
（3）只有一个控制单元无通讯，首先查看相关电路图，然后考虑以下问题。
①网络通信线出现断路、短路或者信号电压异常。
②控制单元故障：控制单元电源、搭铁或控制单元内部故障。如故障2中所有的外部电源无任何问题，但网络中各元件问的电源线路同样须注意，否则就会产生像之前更换EBCM的误判。
③t唤醒线故障，因为控制单元如处在休眠状态，就谈不上通信了。
再有就是对间歇性故障的处理，本文2案例都有类似情况，对此维修人员肯定是最为头痛的。所以排除此类故障时应做好充分准备，规范诊断流程，注重各种故障现象和每一个细节，合理利用各种诊断工具，充分利用车辆模块化带来的便利，认真仔细进行故障及数据流分析，加上像本文2案例中的部件替换，颠簸路面施加振动以及拉拽线束等方法，想方设法进行故障隔离，这些方法对排除间歇性故障是非常有帮助的，也是行之有效的。
最后，我们要从各式各样的故障中找到原因，就要分析出它们的特点和规律，当然这就需要我们必须先充分熟悉相关系统的结构和工作原理，这样才会在众多的故障现象和诊断数据流中找到所需要的来进行分析，从而找到正确的方向，快速解决问题，避免以上2个案例中所出现的返工及误判。