故障分析中逻辑树到物理树的扩展装置及方法

摘要

本发明公开了一种故障分析中逻辑树到物理树的扩展装置及方法，能实现对故障的准确定位，该扩展装置包括：逻辑树管理模块，用于安排故障检测点，依据所述故障检测点建立表达设备故障模式的逻辑树；配置管理模块，用于根据当前配置情况建立配置数据库；相关性分析知识库，与所述逻辑树管理模块和配置管理模块相连，用于根据分析规则进行故障检测；物理树扩展模块，与所述相关性分析知识库相连，根据所述逻辑树中的节点对确定边方法。与现有技术相比，本发明装置和方法能够灵活、自适应地从逻辑树扩展到物理树，效率高而且定位准确，广泛适用于移动通讯设备故障分析。

说明书

技术领域

本发明涉及移动通讯设备故障分析领域，尤其涉及故障分析中逻辑树到物理树的扩展装置及方法。

背景技术

在目前的移动通讯设备故障分析中，主要是基于FMEA(故障模式影响分析)方法。FMEA基于事前设计故障树，即根据设备的逻辑设计视图及数据处理流程，设计故障检测点。在故障定位过程中，根据预定义的故障树，扩展分支与节点。在其他的一些方法中，还根据故障的历史信息，对故障树扩展作部分调整。

在复杂的系列化设备中，目前的故障分析方法难以适应设备的快速更新换代，更难以适应设备的灵活配置需求。通讯设备的系列化设计中，一般基于一个通用的逻辑设计平台，系统的业务处理逻辑基本保持兼容。而物理视图可以快速变换，如外观、容量等，以满足不同用户的需求。这样，逻辑视图与物理视图存在较大差异，而故障定位需要明确指出故障的物理位置，以利于用户维护，特别是对于多个物理单板提供的共享池、动态负载均衡系统，一般是灵活配置且动态自适应的，因此只使用逻辑视图无法准确定位。

在故障分析中，需要将逻辑视图正确扩展为物理视图，才能准确定位故障。但是现有技术都没有提到设备逻辑视图与物理视图的差异与联系，没有说明设备的逻辑视图如何映射到具体的物理视图。因此有必要提出新的技术方案来解决现有技术的这些技术缺陷。

发明内容

本发明所要解决的技术问题是在于需要提供一种移动通讯设备故障分析时从逻辑树到物理树的扩展装置及方法，实现对故障的准确定位。

为了解决上述技术问题，本发明首先提供了一种故障分析中逻辑树到物理树的扩展装置，包括：

逻辑树管理模块，用于安排故障检测点，依据所述故障检测点建立表达设备故障模式的逻辑树；

配置管理模块，用于根据当前配置情况建立配置数据库；

相关性分析知识库，与所述逻辑树管理模块和配置管理模块相连，用于根据分析规则进行故障检测；

物理树扩展模块，与所述相关性分析知识库相连，根据所述逻辑树中的节点对确定边方法。

如上所述的故障分析中逻辑树到物理树的扩展装置中，所述逻辑树管理模块安排所述故障检测点，可以根据业务数据的处理流程在系统设计阶段完成。

如上所述的故障分析中逻辑树到物理树的扩展装置中，所述逻辑树管理模块可以按照故障相关性，建立所述逻辑树。

如上所述的故障分析中逻辑树到物理树的扩展装置中，所述相关性分析知识库使用的分析规则，可以包括配置查询规则和节点扩展规则。

本发明进而提供了一种故障分析中逻辑树到物理树的扩展方法，包括：

(1)根据故障表现信息选择逻辑树，提取逻辑树中第一层逻辑节点及其边方法；

(2)根据故障初时位置及第一层逻辑节点的边方法查询配置数据库，获得与第一层逻辑节点对应的物理节点，并进行故障检测；

(3)检测到故障物理节点，且所述故障物理节点对应的逻辑节点有下一级逻辑节点，则扩展所述故障物理节点对应的逻辑节点，得到下一级逻辑节点，对所述下一级逻辑节点对应的物理节点进行故障检测；

(4)返回步骤(3)执行，直到检测到故障物理节点且对应的逻辑节点没有下一级逻辑节点，则该故障物理节点就是故障点。

如上所述的故障分析中逻辑树到物理树的扩展方法，步骤(1)中所述逻辑树可以按照故障相关性划分。

如上所述的故障分析中逻辑树到物理树的扩展方法，步骤(1)中选择逻辑树后可以输入逻辑根结点号，根据所述逻辑根结点号完成所述提取逻辑树中第一层逻辑节点及其边方法。

如上所述的故障分析中逻辑树到物理树的扩展方法，步骤(2)中根据所述故障初时位置及第一层逻辑节点的边方法，可以按照配置查询规则，查询所述配置数据库。

如上所述的故障分析中逻辑树到物理树的扩展方法，步骤(3)中可以根据节点扩展规则，扩展所述故障物理节点对应的逻辑节点，得到所述下一级逻辑节点。

与现有技术相比，本发明装置和方法能够灵活、自适应地从逻辑树扩展到物理树，效率高而且定位准确。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1是本发明扩展装置实施例的组成示意图；

图2是本发明扩展方法实施例的流程示意图；

图3是本发明故障分析逻辑树的结构示意图；

图4是根据图3所示逻辑树扩展得到的物理树结构示意图；

图5是本发明另一个应用实例的机框配置图；

图6是针对图5所示Abis链路断的故障分析逻辑树；

图7是针对图5所示Abis链路断的故障分析第一轮测试结束后的物理树；

图8是针对图5所示Abis链路断的故障分析第二轮测试结束后的物理树图。

具体实施方式

以下将结合附图及实施例来详细说明本发明的实施方式，借此对本发明如何应用技术手段来解决技术问题，并达成技术效果的实现过程能充分理解并据以实施。

首先，本申请将故障分析的逻辑视图称为逻辑树，故障分析的物理视图称为物理树。逻辑树是故障分析的基础，是在系统设计阶段就确定了的，即设计阶段确定有效的检测点。物理树以逻辑树为基础，结合当前故障现象，在故障分析阶段逐步建立起来。

故障分析不是纯粹抽象的，而是用户在系统维护过程中，与具体物理设备对应的。从逻辑树到物理树的扩展过程中，涉及到节点和边方法。节点指故障树上的有效检测点，综合反映了逻辑树与物理树的属性，包含具体的故障信息。节点分为父节点和子节点，子节点指可能导致其上层故障的下层故障点。边方法指从父节点扩展到子节点的方法，以下简称为边。扩展方法中的关键是边，从故障分析的含义上，边包含从表层故障现象推导出低层故障本质的故障相关性关系，以及具体的配置情况。

本发明的基本思想是根据系统数据处理流程，在设计阶段安排合理的故障检测点，以这些故障检测点为基础建立逻辑树，然后依据逻辑树、当前配置情况以及故障信息来正确扩展物理树。

如图1所示，为本发明扩展装置实施例的组成示意图，该装置包括：

逻辑树管理模块102，根据业务数据的处理流程，在系统设计阶段合理安排故障检测点，依据设计阶段的故障检测点建立故障分析的逻辑树。故障分析逻辑树与系统设计应同步进行，或融入系统设计中去，这样才能达到满意的故障检测覆盖率，一棵逻辑树表达了设备的一种故障模式。逻辑树管理模块还含有对逻辑树的编辑、存储和更新等维护功能的作用，以及故障分析过程中的装载调用等功能的作用。逻辑树以规范的语言格式存储在数据库或文件中。

配置管理模块104，根据当前配置情况建立配置数据库，配置数据库提供了当前正确的配置情况。逻辑树只是故障分析的理论视图，只有参照配置情况，转换为物理树，故障分析才能正确定位故障。配置管理模块104还含有地址相关性分析、单板连接关系查询等功能作用。

相关性分析知识库106，故障分析过程中，需要使用各种分析规则，包括故障上下文关系，故障判断规则，配置查询规则，节点扩展规则，以及根据当前的系统状态需要执行的测试动作和不同的故障需要采取的各种动作。各种类型的规则以规范的格式编码，作为知识库存储。故障分析过程中，需要调用各种规则进行故障动态分析。

物理树扩展模块108，故障相关性分析过程中，根据逻辑树中一个[父节点，子节点]对，称之为节点对，可以确定一个边方法，即从父节点扩展到指定子节点的方法。综合考虑当前配置情况，一个逻辑节点可能扩展为多个物理节点。故障分析最终获得的是与当前设备配置、故障模式相匹配的物理树以及故障物理节点的位置。

图2是本发明扩展方法实施例的流程示意图，包括以下步骤：

步骤S102，根据故障表现的信息来选择逻辑树，逻辑树按故障相关性分析来划分，有关联关系的故障节点都按节点、边连接为一棵逻辑树，根据设备表现的初略信息就可以确定属于哪一棵逻辑树；

步骤S104，输入逻辑根结点号，根据逻辑根结点号提取第一层逻辑子节点及其边方法；一棵逻辑树有一个根节点，根节点下面有一个或多个逻辑子节点，一个节点对确定了一条边方法；

步骤S106，输入故障初始位置，调用第一层第一个逻辑子节点的边方法，按照配置查询规则查询配置数据库，获得第一个逻辑子节点对应的物理子节点，并按照同样方法，获得第一层其它逻辑子节点的物理子节点；

步骤S108，进行第一轮检测，检测根节点下的所有第一层物理节点；

步骤S110，判断这一层物理节点的检测结果，如果存在故障的物理节点，且这个节点对应的逻辑树节点有子节点，则需要继续扩展这个逻辑节点的下级物理节点，并检测扩展得到的下级物理节点；

步骤S112，返回步骤S110继续执行，直到某一层物理节点的检测结果中存在故障节点，且逻辑树上这个节点没有对应的子节点，则检测结束，这个位置就是故障点，故障分析结束。

本方法实施例中的层层推进体现的是相关性分析知识库106上下文关系的分析过程。其中的步骤S110、S112体现的是相关性分析知识库106故障判断规则的过程。

以下通过一个更具体的应用实例来进一步详细说明本发明是如何解决上述技术问题的。

图3是本发明故障分析逻辑树的结构示意图。逻辑树是静态的，是在设计阶段就确定了的。如图3所示，根节点下面有三个逻辑子节点，逻辑节点1、逻辑节点2和逻辑节点3；对应到每个逻辑子节点有一个边方法，分别为边1、边2和边3。边方法指从相应逻辑父节点查询获得物理子节点的方法，比如边1指逻辑根节点下面的逻辑节点1对应的物理节点的配置查询方法。逻辑节点2下面有三个逻辑子节点，逻辑节点21、逻辑节点22和逻辑节点23，对应的边方法分别为边21、边22和边23。逻辑节点21下面有两个逻辑子节点，逻辑节点211和逻辑节点212，对应的边方法分别为边211和边212。逻辑节点22下面也有两个逻辑节点，逻辑节点221和逻辑节点222，对应的边方法分别为边221和边222。各个逻辑节点的子节点数量是根据设备设计视图、故障相关性分析确定的。

图4是根据图3所示逻辑树扩展得到的物理树结构示意图。物理树是动态的，是在具体的故障相关性分析过程中一层一层建立起来的。如图4所示，按图3所示逻辑树结构，以及当前配置情况，根节点扩展为三个物理子节点。对应图3，根据逻辑节点1扩展出物理节点1、根据逻辑节点2扩展出物理节点2、根据逻辑节点3扩展出物理节点3。测试这三个物理节点，发现物理节点2表现为故障，则需要继续扩展物理节点2的子节点。根据逻辑节点21扩展出物理节点21，根据逻辑节点22扩展出两个物理节点，分别为物理节点2201、物理节点2202，根据逻辑节点23扩展出物理节点23。再测试这四个物理节点，发现物理节点2201故障，则需要继续扩展物理节点2201的子节点。根据物理节点2201扩展出两个子节点，分别为物理节点221和物理节点222，测试这两个物理节点，则必会有一个节点为故障。物理树动态扩展时，测试结果正常的节点不需要进一步扩展测试，只需要扩展测试结果为故障的节点。

图5是以一个Abis口(基站控制器与基站收发信机接口)通讯链路处理为本发明另一个应用实例的机框配置图，图中配置2块ABPM(Abis协议处理板)，分别如ABPM[1]和ABPM[2]所示；3块DTB(数字中继处理板)，分别如DTB[3]、DTB[5]和DTB[6]所示；一块UIM(通用接口板)，如UIM[4]所示。单板的配置信息存储在配置数据库中，如表1所示：

表1、配置数据库中的表记录

  槽位号  单板类型    1    ABPM    2    ABPM    3    DTB    4    UIM    5    DTB    6    DTB

图5是一个配置方法的具体体现，结合图6、7、8可以体现地址相关性及单板连接关系等功能。

图6是针对图5所示Abis链路断的故障分析逻辑树。图中逻辑树的含义是，出现Abis口链路故障时，第一轮应检查ABPM上的PPP(点对点协议)链路是否正常、UIM上的交换端口是否正常。如果检测到ABPM上的PPP链路故障，则第二轮继续检查DTB上的HDLC(高速数据链路)通讯是否正常。

图7是针对图5所示Abis链路断的故障分析第一轮测试结束后的物理树。如图5所示设备出现Abis链路断故障时，从逻辑树得知，第一轮应检查ABPM上的PPP链路是否正常、UIM上的交换端口是否正常。但这两类检查点的具体位置，需要通过边方法来查询。ABPM上的PPP链路需要查询ABPM的位置，通过查询配置数据库，得知配置了两块ABPM，分别为ABPM[1]和ABPM[2]。同样，从配置数据库查询得知UIM配置了一块，为UIM[4]，则第一轮需要进行三个测试，分别为ABPM[1]PPP通讯测试、ABPM[2]PPP通讯测试和UIM[4]交换端口测试。检测结果为ABPM[2]PPP通讯断，其它两个正常。

图8是针对图5所示Abis链路断的故障分析第二轮测试结束后的物理树图。从第一轮测试结果得知，ABPM[2]PPP通讯断，则需要继续扩展ABPM上PPP通讯的物理子节点。从逻辑树得知，ABPM上的PPP通讯有一个子节点，即DTB HDLC通讯。通过边方法，查询配置数据库，获得当前配置的三块DTB板，分别为DTB[3]、DTB[5]和DTB[6]，则第二轮需要进行三个测试，分别为DTB[3]HDLC通讯、DTB[5]HDLC通讯和DTB[6]HDLC通讯。检测结果为DTB[3]HDLC通讯和DTB[5]HDLC通讯正常，DTB[6]HDLC通讯断。由于在逻辑树中，DTB上的HDLC通讯没有子节点了，说明真实的故障点就是DTB[6]HDLC通讯断，分析结束。

虽然本发明所揭露的实施方式如上，但所述的内容只是为了便于理解本发明而采用的实施方式，并非用以限定本发明。任何本发明所属技术领域内的技术人员，在不脱离本发明所揭露的精神和范围的前提下，可以在实施的形式上及细节上作些许的更动与润饰，但本发明的专利保护范围，仍须以所附的权利要求书所界定者为准。