一种应急指挥通信中的故障分析和解决方法及装置与流程

本申请涉及应急通信领域，尤其涉及一种应急指挥通信中的故障分析和解决方法及装置。

背景技术：

物联网作为新一代信息通信技术的典型代表，已成为全球新一轮科技革命与产业变革的核心驱动和经济社会绿色、智能、可持续发展的关键基础与重要引擎。当前，物联网以泛在感知、精益控制、数据决策等能力要素集的形式向传统行业的上下游各个环节加速渗透、多维融合，促进产业升级和结构优化，推动新兴业态不断涌现。以自动感知为基础、数据采集为手段、智能控制为核心、精细管理和服务提升为目的，实现物联网技术的综合集成应用，全球物联网正在整体进入实质性推进和规模化发展的新阶段。

在物联网应用的诸多领域当中，以国防建设、应急指挥通信保障、国家安全、环境数据采集、森林防火、地质灾害检测等多个领域，其部署实施主体多为政府及公共服务部门，安全级别要求较高。因此，特种通信物联网技术被应用于应急指挥通信系统、数据链系统等智能信息管理系统，提供特种设备管理、资源调配、信息感知与传输、应急通信、实时决策、预警和应急管理方案等服务是当今技术的发展趋势。

在应急通信中由于环境原因，很容易出现运营异常的情况，而这些情况光靠人工监测效率太低，严重影响应急救援效果。

技术实现要素：

本申请提供了一种应急指挥通信中的故障分析和解决方法，包括：

采集各通信基站、通信节点和终端设备中存储的大量运行异常历史数据，根据大量的运行历史日志数据进行学习，构建能够自动分析预测新加入的通信基站、通信节点和终端设备故障原因的故障分析模型；

采集各通信基站、通信节点和终端设备的运行数据，输入故障分析模型进行分析得到解决方案；

根据分析得到的解决方案启动对应的应急响应机制，作出异常报警处理。

如上所述的应急指挥通信中的故障分析和解决方法，其中，根据大量的异常运行数据构建故障分析模型，具体包括如下子步骤：

将大量的异常运行日志数据进行数据预处理；

将日志数据进行特征权重计算，得到文本向量集；

将文本向量集随机分为训练集、验证集和测试集，将训练集两两配对后输入故障分析模型进行训练，并使用验证集对训练的故障分析模型进行调整，然后使用测试集和训练出的故障分析模型进行测试，得到最终训练好的故障分析模型；

根据故障分析模型的分析结果确定对应的解决方案。

如上所述的应急指挥通信中的故障分析和解决方法，其中，云平台在获取到运行数据之后，执行如下子步骤：

s1、获取运行数据中的数据标识，根据数据标识判定该运行数据是正常运行数据还是异常运行数据，如果是异常运行数据，则执行步骤s2，如果是正常运行数据，则继续等待各设备上传的运行数据；

s2、将数据标识输入故障分析模型中，判断根据数据标识是否能够从故障分析模型中获取到解决方案，如果是，则根据分析得到的解决方案启动对应的应急响应机制，否则执行步骤s3；

s3、向执勤人员发送异常报警，并在后续异常处理之后请求对应的异常设备上传异常处理的解决方案。

如上所述的应急指挥通信中的故障分析和解决方法，其中，运行异常历史数据包括数据标识、数据长度、设备标识、设备位置和解决方案；新加入的各通信基站、通信节点和终端设备的运行数据运行数据包括数据标识、数据长度、设备标识和设备位置。

如上所述的应急指挥通信中的故障分析和解决方法，其中，启动对应的应急响应机制，作出异常报警处理，具体包括：如果解决方案是由执勤人员解决，则向执勤人员移动终端发送异常报警；如果解决方案是由专业人员解决，则向专业人员移动终端发送异常报警；如果解决方案是程序自行恢复解决，则云平台向对应的异常设备发送程序解决代码，由异常设备运行解决代码达到异常方案的解决；其中，异常报警信息中包括设备标识和设备位置。

本申请提供一种应急指挥通信中的运行异常监测装置，包括：故障分析模型构建模块、运行数据采集模块和异常报警处理模块；

故障分析模型构建模块用于采集各通信基站、通信节点和终端设备中存储的大量运行异常历史数据，根据大量的运行历史日志数据进行学习，构建能够自动分析预测新加入的通信基站、通信节点和终端设备故障原因的故障分析模型；

运行数据采集模块用于采集各通信基站、通信节点和终端设备的运行数据，输入故障分析模型分析得到解决方案；

异常报警处理模块用于根据分析得到的解决方案启动对应的应急响应机制，作出异常报警处理。

如上所述的应急指挥通信中的运行异常监测装置，其中，故障分析模型构建模块具体用于将大量的异常运行数据进行数据预处理；将日志数据进行特征权重计算，得到文本向量集；将文本向量集随机分为训练集、验证集和测试集，将训练集两两配对后输入故障分析模型进行训练，并使用验证集对训练的故障分析模型进行调整，然后使用测试集和训练出的故障分析模型进行测试，得到最终训练好的故障分析模型；根据故障分析模型的分析结果确定对应的解决方案。

如上所述的应急指挥通信中的运行异常监测装置，其中，运行数据采集模块具体包括运行数据类型识别子模块、解决方案查询子模块和异常处理子模块；

运行数据类型识别子模块获取运行数据中的数据标识，根据数据标识判定该运行数据是正常运行数据还是异常运行数据，若判定为异常运行数据，则触发解决方案查询子模块，否则继续等待各设备上传的运行数据；

解决方案查询子模块将数据标识输入故障分析模型中，判断根据数据标识是否能够从故障分析模型中获取到解决方案，若判定为是，则根据分析得到的解决方案启动对应的应急响应机制，若判定为否，则触发异常处理子模块；

异常处理子模块向执勤人员发送异常报警，并在后续异常处理之后请求对应的异常设备上传异常处理的解决方案。

如上所述的应急指挥通信中的运行异常监测装置，其中，运行异常历史数据包括数据标识、数据长度、设备标识、设备位置和解决方案；新加入的各通信基站、通信节点和终端设备的运行数据运行数据包括数据标识、数据长度、设备标识和设备位置。

如上所述的应急指挥通信中的运行异常监测装置，其中，异常报警处理模块，具体用于如果解决方案是由执勤人员解决，则向执勤人员移动终端发送异常报警；如果解决方案是由专业人员解决，则向专业人员移动终端发送异常报警；如果解决方案是程序自行恢复解决，则云平台向对应的异常设备发送程序解决代码，由异常设备运行解决代码达到异常方案的解决；其中，异常报警信息中包括设备标识和设备位置。

本申请实现的有益效果如下：采用本申请的故障分析和解决方法，能够实现在应急指挥通信时更加快速精准地找到异常设备，而且为异常情况提供准确的解决方案，减少了异常恢复的时间。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1是本申请实施例一提供的一种应急指挥通信中的故障分析和解决方法流程图；

图2是云平台根据大量的异常运行数据构建故障分析模型的具体方法流程图；

图3是云平台在获取到运行数据之后的具体操作流程图；

图4是本申请实施例二提供的一种应急指挥通信中的故障分析和解决装置示意图。

具体实施方式

下面结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例一

本申请实施例一提供一种应急指挥通信中的故障分析和解决方法，应用于云平台，如图1所示，包括：

步骤110、采集各通信基站、通信节点和终端设备中存储的大量运行异常历史数据，根据大量的运行历史日志数据进行学习，构建能够自动分析预测新加入的通信基站、通信节点和终端设备故障原因的故障分析模型；

在各通信基站、通信节点和终端设备中均以日志形式记录各设备的历史运行数据，并定期向云平台上传运行数据；另外，各通信基站、通信节点和终端设备在对异常进行修复后还包括向云平台上传解决方案；云平台存储各通信基站、通信节点和终端设备的运行数据以及异常修复解决方案，借助及其学习的方式对历史故障的日志数据进行学习，由此沉淀出能够实现自动化分析新加入设备故障的原因，进而实现对故障的预测；

其中，各通信基站、通信节点和终端设备的运行数据包括正常运行时数据和异常运行时数据，具体如下表1所示：

表1运行数据统计表

如上表1所示，在云平台中统计各通信基站、通信节点和终端设备的运行数据，每一个通信基站的运行数据包括正常运行数据(即接收到的数据形式为0xa101)和异常运行数据，异常运行数据又包括多种异常类型，包括但不限于表1所述的三种异常类型，即第一种接收到的数据标识0xa101表示为硬件故障类型，例如交流断点、空开跳闸、电源缺相/错相等硬件异常，在数据标识之后为数据长度+基站标识(即来自哪个基站的数据)+基站位置；第二种接收到的数据标识0xa102表示基站间通信中断异常，在数据标识之后为数据长度+基站标识(即来自哪个基站的数据)+基站位置；第三种接收到的数据标识0xa103表示ecc通信中断异常，即由于ecc组网不合理而导致的基站网络异常；同样地，表1中每一个通信节点和终端设备也设置有相对应的数据标识来指示运行数据的类型，在此不作详述；

需要说明的是，表1所述的几种异常类型仅为应急通信中的几种异常形式，除此之外还有发生很多异常事件，每种设备对不同的异常事件均设置对应的异常数据标识，云平台根据异常数据标识确定异常类型；

进一步地，表1展示的是设备之间可以通信但出现了异常情况，此外，还包括设备之间不能通信的异常，具体地，由于各通信基站、通信节点和终端设备定时上传数据至云平台，云平台定期检测各通信基站、通信节点和终端设备的上传数据，因此若云平台在超过检测周期后仍未接收到上传数据，则云平台主动向未上传数据的设备发送获取数据请求，若长时间未接收到响应，则认定当前设备出现通信故障，云平台为此类异常设置对应的数据标识，如0x00；

为增加运营异常及其模型的准确性，将上述多种类型的大量异常运行数据均作为故障分析模型的样本，云平台根据大量的异常运行数据构建故障分析模型，如图2所示，具体包括如下子步骤：

步骤210、将大量的异常运行日志数据进行数据预处理；

其中，预处理具体为对异常运行数据进行数据筛选和数据清洗；

具体地，数据筛选包括剔除对故障定位没有存在价值的日志数据，以及选择能够用作机器学习模型分类的日志数据，即故障类别对应的日志数量较多的日志数据；

数据清洗包括剔除经数据筛选后的日志数据中的特殊符号、各种格式类无用信息等，分离出数据标识、设备标识、设备位置和解决方案；另外对于不同格式的日志数据需要分别进行清洗。

步骤220、将日志数据进行特征权重计算，得到文本向量集；

本申请实施例中，从异常运行数据的解决方案的描述中提取数据标识特征和解决方案特征，数据标识特征表示异常类型，解决方案特征表示解决对应异常的解决方案，包括由执勤人员解决、由专业人员解决和程序自行解决；将数据标识特征和解决方案特征作为特征词进行特征权重计算；

具体地，特征权重计算的方式包括但不限于布尔权重计算方法、频度权重计算方法和词频-逆文件频率计算方法等；

其中，布尔权重计算方法具体为：查找某一故障特征词在文本中是否出现，如果出现则权重设为1，如果未出现则权重设为0；

频度权重计算方法具体为：获取某一故障特征词在文本中出现的频度权重，即出现次数越多的特征词，设定的权重数越大，即其重要性越大；

词频-逆文件频率计算方法具体为：某一故障特征词在一条日志数据中出现次数越多,同时在所有日志数据中出现次数越少,则说明该特征词具有很好的类别区分能力，越能够代表该日志数据为故障数据；具体采用下式计算词频-逆文件频率：

tf_idf＝tf×idf

tf＝m/n

其中，tf_idf为词频-逆文件频率，tf为某一故障特征词在一条日志数据中出现的频率，m为该故障特征词在某一条日志数据中出现的次数，n为出现该故障特征词的某一条日志数据的总词汇量；idf为逆文件频率，x为在经数据筛选和清洗后的所有异常运行日志数据总数，y为某一故障特征词在经数据筛选和清洗后的所有异常运行日志数据。

经上述几种方式的特征权重计算之后，得到每一条日志数据的文本向量，组成文本向量集。

步骤230、将文本向量集随机分为训练集、验证集和测试集，将训练集两两配对后输入故障分析模型进行训练，并使用验证集对训练的故障分析模型进行调整，然后使用测试集和训练出的故障分析模型进行测试，得到最终训练好的故障分析模型；

由于将全部样本数据用作训练模型会出现过度拟合而导致模型评估结果不合适的问题，为了防止过度拟合，将文本向量进行组合分组训练，例如，按照6:2:2的比例将文本向量分为训练集、验证集和测试集；可选地，在实际应用中，可以只将文本向量分为训练集和测试集；

其中，训练集为学习样本数据集，用于训练故障分析模型；验证集为确定网络结构或者控制模型复杂度的参数，用于调整学习出的故障分析模型的分类器参数；测试集用于校验最终选择最优的模型的性能，测量训练好的故障分析模型的识别率；

故障分析模型训练包括两个输入(训练集两两分组，其中一个输入数据作为待训练数据，另一个输入数据作为故障模板数据)，来自相同类的数据标签为1，来自不同类的数据标签为0；故障分析模型输出两个数据的相似度，该输出为当前输入数据的相似度。

步骤240、根据故障分析模型的分析结果确定对应的解决方案；

具体地，故障分析模型输出的相似度的取值范围为0到1，将分析结果以概率形式输出，将输出的分析结果与预先设定的阈值进行对比，如果输出的相似度为1，则说明被训练的文本向量越有可能是相同类型的故障，如果输出的相似度为0，则故障类型不同，根据不同的故障特征词输入故障分析模型之后输出所属的故障类型，根据故障类型确定对应的解决方案；

例如对于硬件故障异常，则由执勤人员恢复；对于设备间通信异常，则由专业人员恢复；对于ecc通信异常，则由程序自行尝试恢复。

返回参见图1，步骤120、采集新加入的各通信基站、通信节点和终端设备的运行数据，输入故障分析模型分析得到解决方案；

本申请实施例中，各通信基站、通信节点和终端设备实时或定时地将运行数据上传云平台，或者云平台实时或定时地向各通信基站、通信节点和终端设备发送采集指示，采集各设备的运行数据；

如图3所示，云平台在获取到新加入的各通信基站、通信节点和终端设备的运行数据之后，执行如下子步骤：

步骤310、获取运行数据中的数据标识，根据数据标识判定该运行数据是正常运行数据还是异常运行数据，如果是异常运行数据，则执行步骤320，如果是正常运行数据，则继续等待各设备上传的运行数据；

由于在云平台中记录的可能只是各通信基站、通信节点和终端设备的一部分异常情况，所以云平台在接收到运行数据之后，只要运行数据的数据标识不是正常运行数据的数据标识，则将该运行数据均当做异常运行数据处理。

步骤320、将数据标识输入故障分析模型中，判断根据数据标识是否能够从故障分析模型中获取到解决方案，如果是，则执行步骤130，否则执行步骤330；

将数据标识输入故障分析模型之后，如果能够找到对应的解决方案，则认定该数据标识为已记录的异常情况，如果不能找到对应的解决方案，则认定为新的异常情况。

步骤330、向执勤人员发送异常报警，并在后续异常处理之后请求对应的异常设备上传异常处理的解决方案。

返回参见图1，步骤130、根据分析得到的解决方案启动对应的应急响应机制，作出异常报警处理；

具体地，如果解决方案是由执勤人员解决，则向执勤人员移动终端发送异常报警；如果解决方案是由专业人员解决，则向专业人员移动终端发送异常报警；如果解决方案是程序自行恢复解决，则云平台向对应的异常设备发送程序解决代码，由异常设备运行解决代码达到异常方案的解决；

其中，异常报警信息中包括设备标识和设备位置，工作人员根据设备标识可以确认是哪类设备发生异常，根据设备位置确定设备所在，方便工作人员精准找到异常设备。另外，对于通知执勤人员或专业人员，也可以由云平台将此解决方案发送至应急指挥中心，由应急指挥中心根据解决方案向对应的工作人员进行异常处理调度。

实施例二

本申请实施例二提供一种应急指挥通信中的故障分析和解决装置，如图4所示，包括：故障分析模型构建模块410、运行数据采集模块420和异常报警处理模块430；

故障分析模型构建模块410用于采集各通信基站、通信节点和终端设备中存储的大量运行异常历史数据，根据大量的运行历史日志数据进行学习，构建能够自动分析预测新加入的通信基站、通信节点和终端设备故障原因的故障分析模型；异常运行数据包括数据标识、数据长度、设备标识、设备位置和解决方案；

运行数据采集模块420用于采集各通信基站、通信节点和终端设备的运行数据，输入故障分析模型分析得到解决方案；运行数据包括数据标识、数据长度、设备标识和设备位置；

异常报警处理模块430用于根据分析得到的解决方案启动对应的应急响应机制，作出异常报警处理。

具体地，故障分析模型构建模块410具体用于将大量的异常运行日志数据进行数据预处理；将日志数据进行特征权重计算，得到文本向量集；将文本向量集随机分为训练集、验证集和测试集，将训练集两两配对后输入故障分析模型进行训练，并使用验证集对训练的故障分析模型进行调整，然后使用测试集和训练出的故障分析模型进行测试，得到最终训练好的故障分析模型；根据故障分析模型的分析结果确定对应的解决方案。

其中，运行数据采集模块420具体包括运行数据类型识别子模块421、解决方案查询子模块422和异常处理子模块423；

运行数据类型识别子模块421获取运行数据中的数据标识，根据数据标识判定该运行数据是正常运行数据还是异常运行数据，若判定为异常运行数据，则触发解决方案查询子模块422，否则继续等待各设备上传的运行数据；

解决方案查询子模块422将数据标识输入故障分析模型中，判断根据数据标识是否能够从故障分析模型中获取到解决方案，若判定为是，则根据分析得到的解决方案启动对应的应急响应机制，若判定为否，则触发异常处理子模块423；

异常处理子模块423向执勤人员发送异常报警，并在后续异常处理之后请求对应的异常设备上传异常处理的解决方案。

进一步地，异常报警处理模块430，具体用于如果解决方案是由执勤人员解决，则向执勤人员移动终端发送异常报警；如果解决方案是由专业人员解决，则向专业人员移动终端发送异常报警；如果解决方案是程序自行恢复解决，则云平台向对应的异常设备发送程序解决代码，由异常设备运行解决代码达到异常方案的解决；其中，异常报警信息中包括设备标识和设备位置。

以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围。都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。