基于故障树的高速动车组网络故障分析系统

许 清，黎川宇

（株洲中车时代电气股份有限公司，湖南 株洲 412001）

0 引言

近年来，我国轨道交通建设高速发展，高速动车组作为方便、快捷、大容量的公共交通工具之一，已成为人们出行的重要方式。由于动车组运行速度较快，其安全运行的重要性日益凸显。动车组安全行驶过程中，网络控制系统起着主要作用，故障分析则是保证动车网络控制系统可靠运行的一种重要技术手段。

国外各公司针对列车的故障分析起步较早且技术相对成熟，如加拿大庞巴迪公司的Mitrac®TCMS 系统、日本三菱公司在Arcnet网络上研发的TIMS系统、法国阿尔斯通公司的eTrain 实时维护系统、德国西门子公司的SIBAS32系统、美国通用公司的DELTA系统等均实现了列车逻辑控制及故障深度分析功能［1］。我国的列车故障分析技术起步较晚，目前主要是根据系统的工作原理、特点、功能及架构对所有发生的故障原因进行分类汇总及罗列，发生故障时按既定程序逐一检查并排除［2］。此方法未区分故障原因且分析步骤较为固定，不能相对准确地反映出系统各不同层次故障间的关系，如关联程度、功能逻辑关系等，不能高效、精准地排查故障。

对此，为提升维护人员的诊断效率与故障处理能力，本文对高速动车组网络控制系统的故障问题展开研究，并应用故障树分析法［3］，结合VB 编程和Access 数据库软件设计了高速动车组网络故障分析系统。

1 高速动车组网络控制系统故障分类

高速动车组网络控制系统由中央控制单元CCU进行控制［4］，通过车辆总线、列车总线实现通信管理，收集车辆及子系统状态信息，通过逻辑处理实现列车控制、故障诊断、状态监视、数据记录等功能。网络控制系统基本功能如图1所示。

图1 高速动车组网络控制系统基本功能Fig.1 Basic functions of the network control system of high speed EMU

对高速动车组网络控制系统的控制需求、应用软件及故障清单展开研究发现，其出现的故障主要由软件和硬件两大原因造成。

软件问题可归根于应用软件故障、底层软件故障及两种软件不匹配故障。应用软件故障主要与整车逻辑控制相关。底层软件故障与操作系统、通信任务、算法处理任务相关。其中应用软件故障主要由整车逻辑问题、功能块未使能、任务周期错误及数据无写入/输出等故障导致；底层软件故障主要由单板上电不打印、操作系统未加载、配置错误及算法错误等故障导致。

硬件问题可归结于以下几点：中央控制单元、骨干网交换机、编组网交换机、输入输出设备、子系统设备、通信线缆及连接器等设备故障。其中中央控制单元、子系统设备故障由主控板或电源板故障导致，骨干网交换机、编组网交换机故障由交换板或电源板故障导致；输入输出设备故障由主控板或IO 板故障导致；通信线缆及连接器故障由电源板或线缆或连接器故障导致。

高速动车组网络故障思维导图如图2所示。

图2 高速动车组网络控制故障思维导图Fig.2 Mind map of high speed EMU network failure

2 故障树的建立

故障树分析法是以分析某个系统所诊断出的故障为目标，通过逻辑推理的方式挖掘出导致这些中间事件发生的所有的直接原因，并采用演绎法不断进行延伸及挖掘，直到找出导致某故障的所有原因，再通过故障树图的方式对其进行直观地描述。在实际使用的过程中，可应用故障树分析法迅速找出系统失效部分，并对其进行定性和定量的分析，以提升故障分析的效率，保证系统能够更稳定、正常的运行。故障树技术运用逻辑运算实现各事件之间的联系，常用的运算关系包括“与”“或”“非”“异或”等［5］。

本文引用故障树分析方法，结合上文对高速动车组网络控制系统的结构及故障形式的研究，建立高速动车组网络控制系统的故障树模型，以提高其故障分析效率及准确性。图3 示出高速动车组的输入输出装置（IOM）通信故障的建立过程。其中，顶事件为T（即IOM故障）。中间事件包括数据链路A1（因数据链路异常所导致的故障，包括交换机和线缆故障）、数据源A2（因IOM 自身原因导致的故障，如IOM 未发出数据）、数据宿A3（因CCU 异常导致的故障）、交换机异常A4（交换机未正常转发数据）、软件原因A5（因运行在PU300板卡上的底层软件和应用程序导致板卡无法发出数据）、应用软件异常A6（应用软件设计出错）。底事件包括线缆故障B1（因线缆问题导致通信链路中断）、硬件原因B2（因硬件导致板卡无法发出数据）、软件异常B3（软件设计出错导致上报通信故障）、硬件原因B4（硬件原因导致板卡无法收到数据）、硬件异常B5（硬件原因导致交换机无法收发数据）、软件异常B6（交换机软件原因导致数据未送达CCU处）、底层软件异常B7（底层软件出错）、匹配异常B8（应用软件与底层软件不匹配）、配置文件出错B9（配置文件中未配置正确的以太网端口、周期、源IP）、程序出错B10。

图3 高速动车组输入输出系统故障树Fig.3 Fault tree of EMU input and output systems

在故障树中导致顶事件发生的底事件集合为割集。求解最小割集的方法通常有下行法和上行法两种［6］：

（1）上行法。从底事件出发，由下往上开始运算，计算事件的集合。当遇到或门时，可将该情况理解为输出事件的并；当遇到与门时，可将该情况理解为输出事件的交，直到最后得到最小割集。

（2）下行法。从顶事件出发，由上往下开始运算，计算事件的集合。同样，当遇到或门时，可将该情况理解为输出事件的并；当遇到与门时，可将该情况理解为输出事件的交，一直到无法分解的事件为止，最后得到最小割集。以图3 为例，利用下行法求解，其过程如表1所示。

表1 求解最小割集过程Tab.1 Process of solving the minimum cut set

经吸收并简化，得到10 个最小割集：K1：｛B1｝；K2：｛B2｝；K3：｛B3｝；K4：｛B4｝；K5：｛B5｝；K6：｛B6｝；K7：｛B7｝；K8：｛B8｝；K9：｛B9｝；K10：｛B10｝。

2.1 故障树定性分析

对上述高速动车组输入输出系统故障树进行定性分析，由顶事件自上而下找出不能再分割的事件集合（即故障原因）；根据已建好的故障树，利用下行法求出最小割集［7］。所以，导致动车输入输出系统故障的原因有K1：｛B1｝；K2：｛B2｝；K3：｛B3｝；K4：｛B4｝；K5：｛B5｝；K6：｛B6｝；K7：｛B7｝；K8：｛B8｝；K9：｛B9｝；K10：｛B10｝。

2.2 故障树定量分析

衡量底事件对顶事件的影响程度定义为底事件重要度，因此确定底事件重要度能迅速定位导致事件发生的最直接原因。为进一步帮助维护人员快速定位分析和维修，节约故障排查及分析时间，需根据最小割集的重要度进行排序，从而提高故障排查效率［8］。底事件重要度计算过程如下：

（1）顶事件发生的概率P(X)为

式中：X——输出事件；xi——输入时间，i=1，2，…，n；P(xi)——输入事件发生的概率。

（2）底事件发生的概率qk为

式中：αk——第k个底事件发生的概率，由可靠性试验和长期故障统计得到；t——底事件工作时间。

（3）底事件重要度M(k)为

经计算，以输入输出系统为例，数据链路发生故障的概率更大，其次是数据宿，最后是数据源。数据链路中，线缆故障的概率大于交换机故障的；交换机故障中，硬件异常概率大于软件异常的。数据宿中，硬件原因导致板卡无法收到数据的概率大于因软件设计出错导致上报通信故障的概率。数据源中，硬件原因导致板卡无法发出数据的概率大于因程序导致板卡无法发出通信数据的概率。软件在出厂前已调试得较完善，在正线运行过程较稳定，所以硬件故障的概率一般大于软件故障的概率。

3 高速动车组网络故障分析系统设计

为缩短故障处理时间，实现对故障数据库更便捷的查看、浏览及分析，本文结合VB编程及Access数据库软件，设计了高速动车组网络故障分析系统对故障进行分析。该故障分析系统总体设计如图4所示。

图4 故障分析系统设计步骤Fig.4 Design steps of the fault analysis system

故障分析系统主要由数据库（包括案例库和故障库）、故障分析和数据库维护组成，操作人员通过使用这3 个模块能实现动车故障分析、曾经案例及现有故障浏览、数据库的修改及维护等操作，为故障分析提供数据及技术支撑。

当技术人员从故障分析界面输入故障时，系统会从数据库中选取一条内容与输入故障进行匹配，当匹配成功时，系统会结合已建立的故障树对输入的信息进行逐层推理及分析，最终得到故障分析结果。

3.1 数据库的创建

为组织及管理大量由故障树分析法所得的系统故障数据，实际应用中需搭建数据库来存储数据，一般采用“产生式规则”。产生式规则一般用以下方式表示：IF A THEN B。其中A 表示条件，B 表示结论，其意思为：如果满足条件A，则可以得到结论B。

故障树的建立过程可认为是获取知识的过程，逐层深入剖析。在建立故障树时，将故障树的顶事件存入数据库故障表的故障类型中，将最小割集中的基本事件（底事件）即故障原因存入故障表的故障原因中，按底事件概率重要度从大到小对故障原因进行排序，从而得到排查顺序。数据库创建流程如图5所示。

图5 数据库创建流程Fig.5 Flowchart of database creation

3.1.1 案例库模块

案例库为高速动车运营到目前为止的故障案例，案例库界面由4 个搜索框、1 个数据表格控件和3 个命令按钮组成。用户可根据需要在搜索框内输入相应主题进行搜索，浏览与其类似的案例，获取分析经验；维护人员也可在该界面添加案例。案例库界面如图6所示。

图6 案例库界面Fig.6 Case library interface

3.1.2 故障库模块

故障库是基于故障树分析法得到的动车各系统故障的最小割集的数据库，故障库界面由4 个搜索框、3个命令按钮和1 个数据表格控件组成。用户既可在该界面浏览所有的故障现象、故障原因及排查顺序，也可输入关键词搜索故障。故障库为故障分析的基础，维护人员也可在该界面添加和删除故障库内容。故障库界面如图7所示。

图7 故障库界面Fig.7 Fault library interface

3.2 故障分析模块

故障分析模块是系统的核心，其主要功能为分析动车的故障。故障推理是故障分析的关键，本文利用正向推理策略设计推理程序。故障搜索流程如图8所示。当需进行故障分析时，在检索框中输入故障的表征，由程序不断地对上文中建立的数据库进行访问和检索。当匹配成功，系统将结合已建好的故障树对输入信息进行层层推理、逐一判断，依次将得到的“故障原因”“排查顺序”“字段”存储在表格中［9］，并生成故障分析建议表。若未匹配成功，系统将会提示重新输入与数据库内容匹配的信息，继续重复以上步骤，直到得到分析结果［10］。

图8 故障搜索流程Fig.8 Flowchart of fault search

故障库模块的窗口由2个搜索框、1 个数据表格控件和2 个组合框控件组成。故障分析界面如图9所示。本文设计的数据库搜索功能代码如图10所示。

图9 故障分析界面Fig.9 Failure analysis interface

图10 搜索功能代码Fig.10 Search function codes

3.3 数据库维护模块

数据库维护模块是技术人员对故障分析系统进行维护的窗口，完成对曾经案例及现有故障、数据库的添加、删除、修改及维护等操作，为故障分析提供数据及技术支撑。数据库维护流程如图11所示。

图11 数据库维护流程Fig.11 Database maintenance process

4 高速动车组网络故障分析系统应用

高速动车组网络故障分析系统自创建以来，已取得较好的应用效果。下面通过实例对高速动车组网络故障分析系统的应用展开说明。

故障现象：2021年3月16日18时10分，某动车报受电弓不可用故障，司机处理无效后车辆退出运营。

4.1 原故障分析过程

若无高速动车组网络故障分析系统，技术员将用原始的诊断方法进行故障排除，其过程如下：

（1）查看控制要求说明，研究受电弓工作原理；

（2）对导致受电弓不可用的原因进行列举；

（3）按上述原因进行一一排查。

4.2 高速动车组网络故障分析系统故障分析过程

技术员通过高速动车组网络故障分析系统对该故障按以下步骤进行分析：

（1）登录故障诊断系统。进入故障诊断系统，在故障类型中选择“受电弓不可用”，在故障现象中选择“受电弓不可用，无法升弓”，得到诊断建议如图12所示。

图12 故障诊断界面Fig.12 Failure diagnosis interface

（2）查看案例库。点击案例库查看曾发生类似故障的原因，为故障诊断提供分析经验，图13 所示为案例库界面。

图13 案例库界面Fig.13 Case library interface

（3）故障排查。查看故障诊断界面，结合案例库的经验，对本次故障进行分析，依照排查顺序依次展开检查。检查结果为列车还处于400 V供电模式状态，调整供电模式后，受电弓可用。

4.3 应用效果分析

由上述流程可知，使用原故障诊断方法，技术人员需要通过分析设备工作原理及查看电气图纸来查找可能导致问题的原因或故障元器件，该过程至少耗费0.5 h时间。采用本文设计的故障诊断系统对故障进行诊断，导致故障的原因可立即被直接列举出来，供技术人员第一时间排查故障使用，简化了查看设备工作原理、分析故障原因的流程，缩短了排查故障时间，提高了诊断效率。

随着列车运营时间的增加，各设备发生故障的概率会逐渐增大，此时结合高速动车组网络故障分析系统能使维护人员更快捷地进行故障诊断。

5 结语

本文通过分析高速动车组网络控制系统的结构以及故障形式，对网络故障监控系统进行详细的研究，采用基于故障树的故障分析方法，根据底事件的重要度及发生概率对故障原因进行排序研究，最终确定故障分析的最优方法。在此基础上，文章结合VB 编程及Access数据库软件，以最小割集和案例库为数据库，设计高速动车组网络故障分析应用系统。高速动车组网络故障分析系统的应用，可简化故障诊断流程，快速定位故障，得到故障诊断建议，缩短故障分析时间。本系统虽然能在故障发生后提高故障分析效率，但不能提前预测故障。下一步，我们将在此系统的基础上研究故障预测技术，并展开应用。