虹科案例 | 2015年 Case 821F 轮式装载机失去通讯

当我被询问是否想去海边去检查一辆怀疑CAN通讯有问题的装载机时，我期待可以花一些时间来欣赏北海感受海风。可怜的是，我知道我遥远地去海边是去一个许多海鸥在飞来飞去的回收场周围。

我在这里要检查的机器已经遭遇了数周的间歇性故障并且没有明确的方式来使故障发生。操作员告诉我它有时可以工作几个小时，但其他时候一开始运作就会出现故障。与往常一样，确保你可以从客户那边获得尽可能的信息，因为它可以说明你开始思考可能的故障。更重要的是，你应该尝试重现故障来确认问题。不要去修没坏的东西。而间歇性故障就在于它是间歇性的。由于没有特定的方式来重现故障，我们最好先对机器的DTC进行扫描。

幸运地，我们有了一些储存故障代码，所有的故障点都指向CAN的问题。

有趣的是，机器的仪表还闪烁了警告灯表示发动机CAN讯号逾时以及DEF/AdBlue的警告灯表示喷射故障与扭力受限。随着DTC的纪录看一些进一步的方向，我们清除了故障代码希望他能再重现。我们连接示波器以便我们可以在故障发生时捕获一些信息。设置好示波器来监测在机器运作的期间的CAN网络，考虑到储存的故障码，这似乎是最好的行动方案。这款装载机的网络并不复杂，因为在BUS上的ECM相对较少。然而这是一台2015年的机器，运作的时间已经超过13000小时，并且对于要接近发动机舱较困难。

幸运的是，发动机的ECU相当容易接近，使连接上更直接方便。不过我没有考虑到人为错误。下面是在我启动机器后就捕获到的数据，我立刻得出了结论。

如你所见，与信道A相比，信道B极度失真，这就是A-B数学信道具有失真物理层的原理。在我注意到明显的问题之前我甚至认为我遇到了故障。在PicoScope7中，通道区为你提供设置的一些详细信息，例如探头、量程、耦合与滤波。是的，我忘了关闭20kHz的硬件过滤器。之前设置它是为了演示4*25 and 4*25A示波器的可用功能。带宽限制是为了去除示波器中高于20kHz的频率，因此与软件中的DSP滤波器不同，没有办法取得这些资料。这个过滤器对于电流钳相当有用，并且在察看可能有高频干扰影响的讯号时(例如MAF传感器与含氧传感器)，但对于CAN讯号则不太有帮助。

在花了一些时间查看后我认为是接线问题，很明显问题只出现在那个通道，最后才恍然大悟，如果我使用的是PicoScope6，我认为需要更长的时间才能意识到，因为你必须实际打开信道选项来查看带宽限制是否处于开启状态。

在恢复了通道B之后，我们开始尝试捕获故障并利用新的J1939译码器来说明更好地了解故障发生时那些ECU与于开启或关闭状态。

我们很确定的一件事是对于这类的非道路机械而言，要获得详细的线路图是很困难的一件事。

在我到达现场之前，我试图去找到一张线路图结果发现那张线路图与此机械完全不同。幸运的是，我们似乎有一张与机器互相匹配的线路图。我重新绘制了CAN连接部分如下图：

我只想解释一些，并没有把所有在驾驶室的ECU都列出来。其他还有仪表板，远程通信与其他单元，但那些与此故障无关。我仍然怀疑这张图不是正确的，因为我认为NOx传感器不会单独出现在上面。然而，这就是我们所要做的。最有趣的部分是从诊断接头到ECM的K线，它说明我们必须使用串型工具(CAN (J1939), J1587 or K-Line)来进行通讯的选项。

经过一段时间的驾驶和运作机器后故障终于出现在仪表板上。有趣的是，当我们试图使用J1939协议来读取故障码时，我们无法进入ECM，仪表板出现故障。相反地，我们发现与ECM通讯的唯一方式是使用K线，然后我们又试了一次J1939，突然就可以通讯了。我们连接示波器来看看我们是否能够发现CAN网络中发生的事情。我们连接了两条CAN线，但使用示波器的浮动输入，这代表我们只需要两个通道就可以进行此捕获。

浮动输入仅适用于 4*25/4*25A 范围的示波器。我们很幸运，故障变得越来越明显，这代表捕获它变得更容易了。

上面的捕获不是立即发生的，这是一个捕获30分钟的过程，希望你能看到，在这张波型图的中间，通道A的数据包减少了，而通道B在前后都保持一致。

藉由使用J1939译码器和链结文件把译码后的源地址ID转换成可读的信息，我们可以看到当时发生了什么。我们知道发动机ECM是在故障时无法使用串型工具来与它通讯，因此找寻这个是我们的首要事项。

我添加了一个额外的译码表来更好地显示这个过程。我在底部的观看窗口添加了一个过滤器，这样我们就可以只看到源地址存在发动机#1的译码数据。我们试图查看发动机#1在失去通讯期间是否有脱机，或是发生其他事情。正如我们在发动机ECU上量测的那样，这种下降与接线问题无关。透过将鼠标停在图表上的数据包上，我们大致了解波型的变化发生数据包约在500附近。

你可以看到在观看窗口顶端的已译码信息，并在窗口底部看到发动机#1的过滤数据包。我在两个窗口标记了发动机#1的数据包，约在500附近。如同你所看到的，发动机#1在485数据包之后没有向网络提供进一步的流量，但所有其他ECU很多且在线将数据发送到总在线。ECM丢失与我们看到的故障码以及我们无法透过CAN总线通讯(只能透过K线)让我们更加确定这个问题。

为了确保我们了解所有可能性，下一步是在ECM在开启和关闭时检查电源和接地的供应。我们想要确保当ECM关闭时不会失去电源。由于ECU的电源数量很多，因此最好使用8通道的示波器来捕获所有的内容。当然，你仍然可以使用4通道是波器来检查且拆分为多次捕获。

当ECM在线，我们可以看到在一个缓冲区2秒的时间内，我们有来自发动机#1的1110个数据包，还记录了27.9V的电压。当你认为此捕获是在发动机工作进行时，这与预期的一样。我们还可以看到接地电压值极低，为33.5mV。

相比之下，当发动机#1在关闭时，我们只有两个数据包，电源跟接地电压稳定。有了这些信息后，我们决定告知客户至少需要检查发动机的ECU。与许多工作机械一样，让它停止运作比单换零件成本更高。因此透过CASE订购了一个ECU，且请求他们来安装并程序设计ECU。有趣的是，负责这样工作的技术人员表示，它怀疑是否这样能解决问题，因为它从未看过这故障。然而，证据很清楚，我们没有看到其他可能导致的问题。透过PicoScope记录所有内容，我们可以回顾每个步骤，来确保我们仍确定进行更换。六个月后，机器仍按预期工作。

我希望这会有所帮助，这表示新的J1939译码器可以与串型工具一起使用来帮助诊断。在此感谢Darren Savage有机会加入它的冒险旅程。