掌桥专利:专业的专利平台
掌桥专利
首页

智能设备的监控维护方法、装置、服务器及存储介质

文献发布时间:2023-06-19 09:30:39


智能设备的监控维护方法、装置、服务器及存储介质

技术领域

本申请涉及设备监控技术领域,更具体地,涉及一种智能设备的监控维护方法、装置、服务器及存储介质。

背景技术

近些年来,随着经济水平的不断提升,消费者的消费能力也在逐步增强,同时,消费者对消费品的要求也在不断提升。例如,在智能设备市场,相较于传统的家居设备,智能设备能通过便捷的方式获知用户的意图,提升用户的使用体验,因此,智能设备受到了广泛的关注。然而,智能设备逐步普及的同时,也意味着与智能设备的维护相关的作业量也会同步增加。现有技术中,存在通过用户描述智能设备的异常场景,然后通过一些算法根据异常场景得到异常原因,然后派遣维修工人前去维修。虽然这种方法能够在一定程度上实现自动排查故障原因,但是该过程中用户的参与程度较高,且仅依据智能设备的异常场景进行维护,实际应用时的难度较高。

发明内容

鉴于上述问题,本申请提出了一种智能设备的监控维护方法、装置、服务器及存储介质,能够减少人力投入,降低监控维护智能设备的成本。

第一方面,本申请实施例提供了一种智能设备的监控维护方法,该方法包括:获取智能设备的运行信息;根据运行信息获取智能设备的异常参数;根据异常参数确定用于修复智能设备的维护方案;以及基于维护方案确定预警信息,并输出预警信息。

第二方面,本申请实施例提供了一种智能设备的监控维护装置,该装置包括:运行信息获取模块,用于获取智能设备的运行信息。异常参数获取模块,用于根据所述运行信息获取所述智能设备的异常参数。维护方案确定模块,用于根据所述异常参数确定用于修复所述智能设备的维护方案。预警信息输出模块,用于基于所述维护方案确定预警信息,并输出所述预警信息。

第三方面,本申请实施例提供了一种服务器,该服务器包括:一个或多个处理器;存储器;一个或多个应用程序,其中一个或多个应用程序被存储在存储器中并被配置为由一个或多个处理器执行,一个或多个程序配置用于执行上述的智能设备的监控维护的方法。

第四方面,本申请实施例提供一种计算机可读取存储介质,计算机可读取存储介质中存储有程序代码,程序代码可被处理器调用执行上述的智能设备的监控维护的方法。

相对于现有技术,本申请提供的方案,可以基于智能设备的运行信息获得异常参数,并根据异常参数确定维护方案,并基于维护方案输出预警信息,使得该智能设备的监控维护方法在实际实施时,可以自动得到维护方案并预警,无需维修人员实地对智能设备进行检修,有效减少人力投入,降低监控维护智能设备的成本。

本申请的这些方面或其他方面在以下实施例的描述中会更加简明易懂。

附图说明

为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。

图1示出了一种适用于本申请实施例的智能设备的监控维护方法的应用环境示意图。

图2示出了本申请一个实施例提供的智能设备的监控维护方法的流程示意图。

图3示出了图2所示的方法中得到异常参数的步骤的流程示意图。

图4示出了图2所示的方法中维护方案为专业维护方案下处理方法的步骤的流程示意图。

图5示出了图3所示的方法中得到比对结果的步骤的流程示意图。

图6示出了图3所示的方法中确定维修服务商的步骤的流程示意图。

图7示出了图5所示的方法中输出预警信息的步骤的一种流程示意图。

图8示出了图2所示的方法中维护方案为简易维护方案下处理方法的步骤的又一流程示意图。

图9示出了本申请实施例提出的一种智能设备的监控维护装置的功能模块框图。

图10示出了本申请实施例提出的一种服务器的功能模块框图。

具体实施方式

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

近些年来,市场上对智能设备的投入大大提高,智能设备也得到了广泛的应用,市场上基于智能设备维修方面的业务需求量也在逐步提高。目前市场上针对智能设备的维修一般有两种方案,第一种方案是维修人员上门检测,维修人员自行判断以及对智能设备进行维修;第二种方案是采用实时监控智能设备,基于智能设备的异常生成对应的维修工单,维修人员基于该维修工单上门维修。虽然上述两种方案能够在一定程度上满足对智能设备的维修需求,但是,第一种方案容易出现维修人员准备不足,导致一次上门维修不能修理智能设备,同时,相较于传统的家电电器设备而言,智能设备的复杂程度较高,对维修人员的要求也较高,因此在实际维修时的成本较高。第二种方案虽然可以在一定程度上实现基于智能设备的异常检测,并生成对应的维修工单,并在一定程度上解决了第一种方案存在的缺陷,但是,在实际维护过程中,维修人员还需要基于维修工单做比对,需要消耗大量人力,同时,若针对智能设备的每个异常均输出维修工单,不对异常进行区分,以确定是否可以通过软件修复,或者是用户在指导下自行修复,以及需要专业维修等难易程度,均需要维修人员根据该维修工单上门维修,容易造成资源浪费。

为了能够从根本性上解决上述描述的问题,本申请发明人持续投入研发,致力于研究如何能够一次上门维修能够解决智能设备的异常,无需重复上门维修,同时对各类异常进行区分,针对异常选择对应的处理方式,减少资源浪费。进一步地,发明人提出了本实施例的智能设备的监控维护方法,在该方法中,可以基于智能设备的运行信息获得异常参数,并根据异常参数确定维护方案,并基于维护方案输出预警信息,使得该智能设备的监控维护方法在实际实施时,可以自动得到维护方案并预警,无需维修人员实地对智能设备进行检修,有效减少人力投入,降低监控维护智能设备的成本,同时,当将预警信息发送至维修服务商时,维修服务商可以对过往的预警信息进行分析,统计各种异常出现的频率、异常原因等,根据分析统计结果提前对容易出现异常的智能设备进行预防处理,进一步防止智能设备出现异常。

首先对本申请实施例提供的智能设备的控制方法的应用环境进行介绍。

本申请实施例的智能设备的控制方法可以应用于如图1所示的应用场景示意图。该应用场景示意图中的系统环境可以包括服务端10、服务终端20和智能设备30。其中,服务端10可以用独立的服务器或者是多个服务器组成的服务器集群来实现。另外,服务器可以是云端服务器,还可以是传统机房服务器。服务终端20可以是用于控制服务端10的工作状态并获取服务端10输出的数据的设备,该设备可以包括但不限于包括个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备等智能携带装置,还可以是安装于电子设备的应用程序等软件,此处不做具体限制。智能设备30可以包括设置于室内空间中的多种智能家电设备、传感设备以及检测设备等,例如智能电视、智能冰箱或智能空调等。另外,服务端10可以分别与服务终端20、智能设备30形成交互通信,该交互通信的方式可以是无线通信,也可以是有线通信,例如,无线通信可以是蓝牙、WLAN、Wi-Fi(Wireless-Fidelity,无线保真)、ZigBee(紫峰技术)等,有线通信可以是光纤、电缆、网线等。

请参阅图2,本申请实施例提供的一种智能设备的监控维护方法,应用于服务端,其一旦被触发,则实施例中方法的流程可以通过控制设备自动运行,其中,各个步骤在运行的时候可以按照如流程图中的顺序先后进行,也可以根据实际情况多个步骤同时进行,在此并不作限定。该智能设备的监控维护方法用于通过获取智能设备的运行信息输出预警信息。该智能设备的监控维护方法包括以下步骤S11至步骤S14。

步骤S11:获取智能设备的运行信息。

在本实施例中,运行信息可以是智能设备在工作过程中产生的信息。例如,运行信息可以是智能设备中的检测单元检测得到的检测数据,也可以是智能设备中各个功能单元的操作日志数据,还可以是智能设备中各个功能单元的工作日志数据。示例性地,当智能设备为智能空调时,运行信息可以是压缩机、冷凝器、蒸发器的工作功率和工作电压范围,也可以是四通阀各个阀门的开关闭合状态,还可以是制冷时间、目标温度、风口角度等等。另外,在一些示例中,可以周期性地获取智能设备的运行信息,也可以实时地获取智能设备的运行信息,对获取智能设备的运行信息的时间不做具体限制。

在本实施例中,可以通过直接或者间接的方式获取智能设备的运行信息。例如,当采用直接的方式获取智能设备的运行信息时,服务端可以直接与智能设备形成通信连接,直接从智能设备获取运行信息;当采用间接的方式获取智能设备的运行信息时,服务端可以不直接与智能设备形成通信连接,可以通过人工导出的方式从智能设备中获取运行信息,然后将该运行信息发送至服务端。具体地,当智能设备与服务端能够形成完整的通信链路时,选择直接的方式获取运行信息的效率较高,同时可以实现实时监控智能设备。当智能设备中的通信设备出现故障,或者智能设备中的某些信息没有向服务端发送的权限时,可以选择间接获取运行信息的方式,实现智能设备不能外发运行信息时服务端依然能够获取运行信息。

也就是说,本实施例中,可以根据实际场景需求选择对应的方式获取智能设备的运行信息,对获取智能设备的运行信息的方式不做具体限制。

步骤S12:根据运行信息获取智能设备的异常参数。

在本实施例中,异常参数为用于表示智能设备异常的参数。

进一步地,可以将运行信息进行数据标准化处理,得到对应的设备参数,将设备参数与预设的标准参数区间进行比对,若设备参数在标准参数区间之外,则确定该设备参数为异常,并将该设备参数作为异常参数。

其中,可以针对每一个运行信息可以有一种对应的数据标准化处理方式,数据标准化处理可以是将运行信息转换为同一标准下的数据,从而便于后续比对。标准参数区间可以根据智能设备的生产商在智能设备出厂时的规定参数确定。例如,运行信息为报文数据,报文数据的内容为智能设备在过往一个小时内消耗电量为10W,针对智能设备耗能的数据标准化处理为转化为占标准耗能的百分之,该智能设备在一个小时内的标准消耗电量为20W,此时对运行信息进行数据标准化处理,得到的异常参数为消耗电量50%。

步骤S13:根据异常参数确定用于修复智能设备的维护方案。

在本实施例中,维护方案为修复存在异常的智能设备的方案。例如,维护方案可以包括修复智能设备的方法及步骤、修复智能设备所需的配件、修复智能设备所需的维修工具。

在本实施例中,专业维护方案可以包括指定的维修服务商提供维修服务的维护方案。通常而言,专业维护方案通常需要指定的维修服务商提供专业的维修人员为发生异常的智能设备提供维修服务。另外,维护方案还可以包括简易维护方案,简易维护方案可以是维护方案中的执行主体不在于维修服务商的方案。也就是说,当修复智能设备无需维修服务商派遣维修人员来处理时,可以将维护方案视为简易维护方案。

步骤S14:基于维护方案确定预警信息,并输出预警信息。

在本实施例中,预警信息为用于提示智能设备出现异常的信息。具体地,可以向维修服务商发送预警信息,以提示维修服务商智能设备出现异常、异常原因、异常修复内容等。维修服务商为出现异常的智能设备提供维修服务的信息。例如,预警信息可以包括智能设备的异常信息。

在本实施例中,服务端可以向服务终端发送预警信息,维修服务商可以接收到预警信息,以便于提前安排维修事宜。同时,维修服务商可以对过往的预警信息进行分析,统计各种异常出现的频率、异常原因等,根据分析统计结果提前对容易出现异常的智能设备进行预防处理,进一步防止智能设备出现异常。

在本实施例中,通过上述步骤S11至步骤S14的实施,可以基于智能设备的运行信息获得异常参数,并根据异常参数确定维护方案,并基于维护方案输出预警信息,使得该智能设备的监控维护方法在实际实施时,可以自动得到维护方案并预警,无需维修人员实地对智能设备进行检修,有效减少人力投入,降低监控维护智能设备的成本,同时,当将预警信息发送至维修服务商时,维修服务商可以对过往的预警信息进行分析,统计各种异常出现的频率、异常原因等,根据分析统计结果提前对容易出现异常的智能设备进行预防处理,进一步防止智能设备出现异常。

基于上述的智能设备的监控维护方法,本申请实施例还提供另一种智能设备的监控维护方法,应用于服务端,其一旦被触发,则实施例中方法的流程可以通过控制设备自动运行,其中,各个步骤在运行的时候可以按照如流程图中的顺序先后进行,也可以根据实际情况多个步骤同时进行,在此并不作限定。该智能设备的监控维护方法用于通过获取智能设备的运行信息输出预警信息。该智能设备的监控维护方法包括以下步骤S21至步骤S24,在本实施例所提供的智能设备的监控维护方法中,执行步骤与S11至S14中相似的部分,可以参考上述的实施例,本说明书不再赘述。

步骤S21:获取智能设备的运行信息。

步骤S22:根据运行信息获取智能设备的异常参数。

如图3所示,进一步地,作为本实施例的一种实施方式,在执行步骤S22时,可以基于运行信息判断智能设备是否出现异常并获取异常参数,因此,上述步骤S22可以包括以下步骤S221至步骤S223。

步骤S221:根据运行信息获取智能设备的运行参数,分析运行参数并确定智能设备是否出现异常。

在本实施例中,运行参数可以是智能设备在工作状态下产生的数据。例如,运行参数可以是智能设备过往五分钟、十分钟、半小时时间段的功耗,又可以是控制智能设备的响应时间,还可以是智能设备功能的完成度。比如,当智能设备为智能灯时,运行参数可以是过往十分钟内的耗能、开启该智能灯的时间、智能灯发出的光的光强与目标光强之比。

在本实施例中,智能设备可以包括处理器和多个功能实现单元,当处理器控制各个功能实现单元运转时,各个功能实现单元可以通过报文数据的形式向处理器反馈工作过程中的操作和工作日志等数据,并将该数据作为运行信息。由于运行信息的数据格式通常与智能设备配置的环境有关,可以将运行信息转换为可以直接用来比对的运行参数,以便于将运行数据与规定范围的参数进行比对,当运行参数超过该规定范围的参数,确定智能设备出现异常;当运行参数未超过该规定范围的参数,确定智能设备出现异常。其中,功能实现单元可以是智能设备中实现某一功能的单元。例如,当智能设备为智能空调时,功能实现单元可以是压缩机、冷凝器、蒸发器等。

步骤S222:若智能设备出现异常,则获取智能设备的异常代码。

在本实施例中,可以先获取智能设备的异常功能监测单元,再基于该异常功能监测单元获取智能设备的异常代码。其中,可以基于智能设备的异常参数确定智能设备的异常功能监测单元,再从智能设备的处理器中获取控制该异常功能监测单元或者代表该异常功能监测单元反馈信息的代码。异常功能监测单元可以是智能设备中出现异常的功能监测单元。

步骤S223:根据异常代码确定智能设备的异常问题,并对异常问题进行标准化处理,得到异常参数。

在本实施例中,异常问题可以是智能设备中异常功能监测单元检测到异常状态。例如,智能设备为智能灯,智能灯包括十个发光二极管(LightEmitting Diode,LED)灯,根据异常代码确定智能灯的实际工作功率为1.8W,而每个LED灯正常的工作功率为0.2W,智能灯正常的工作功率为2W,因此,根据智能灯的实际工作功率、每个LED灯正常的工作功率以及智能灯正常的工作功率、LED灯个数可以确定异常问题为智能灯损坏中的一个LED损坏,异常参数为:LED灯×1。

在本实施例中,通过上述步骤S221至步骤S223的实施,能够基于运行信息判断智能设备是否出现异常,可以从智能设备中获取异常代码,并得到异常问题,到为后续制定维护方案提供依据,同时,每个异常参数可以按照统一的标准进行表示,利于后续的数据处理过程。

步骤S23:根据异常参数确定用于修复智能设备的维护方案。

步骤S24:基于维护方案确定预警信息,并输出预警信息。

进一步地,作为本实施例的一种实施方式,可以先确定维护方案是否为专业维护方案,基于维修服务商的储备资源确定预警信息,进而向维修服务商发出预警信息;其中,专业维护方案所涉及的维护提供方包括指定的维修服务商信息,如图4所示,步骤S24可以包括以下步骤S241至步骤S243。

步骤S241:若维护方案为专业维护方案,则确定智能设备所关联的维修服务商。

在本实施例中,智能设备所关联的维修服务商可以是能够对智能设备维修的维修服务商。例如,智能设备所关联的维修服务商可以是智能设备的生产商,也可以是智能设备的品牌服务商、经销商,还可以是专业维修智能设备的服务商。

步骤S242:根据维护方案得到修复智能设备所需的配件信息。

在本实施例中,修复智能设备所需的配件信息应当至少包括该配件和该配件的数量。例如,智能设备为智能灯,专业维护方案为更换智能灯中的五个LED灯,此时,修复智能灯的LED灯为五个。

步骤S243:基于配件信息和维护方案确定预警信息,并向维修服务商发出预警信息。

在本实施例中,预警信息可以包括配件信息和维护方案。

进一步地,作为本实施例的一种实施方式,可以将配件信息与储备资源进行比对,以基于维修服务商实际的储备资源发送对应的信息至维修服务商,如图5所示,上述步骤S243可以包括以下步骤S2431至步骤S2432。

步骤S2431:获取维修服务商的储备资源,并将配件信息与储备资源进行比对。

在本实施例中,储备资源可以是智能设备所关联的维修服务商中的专业维修人员数量、修复智能设备所需配件的库存、修复智能设备所需工具的库存等。

在本实施例中,可以通过在预先构建的数据库中遍历查询的方式确定智能设备所关联的维修服务商,并在该数据库中获取该维修服务商的储备资源。该数据库可以存储于服务端,在该数据库中预先存储与智能设备、维修服务商相关的信息,当与智能设备、维修服务商相关的信息更新时,将更新的信息存储至该数据库。例如,当某维修服务商中的储备资源变化时,可以将变化后的储备资源更新至该数据库中。当某一智能设备出现异常时,可以基于该智能设备在该数据库中查询与该智能设备所关联的维修服务商,并基于该智能设备的专业维护方案获取修复该智能设备所需的资源,在该数据库中查询该维修服务商的储备资源。

在本实施例中,可以将配件所需的数量与储备资源中配件的库存数量进行比对,得到比对结果。其中,比对结果可以包括需补充配件的数量。

步骤S2432:将比对结果与预警信息发送给维修服务商。

在本实施例中,比对结果可以包括维护方案和需要补充配件的数量。

在本实施例中,通过上述步骤S2431至步骤S2432的实施,可以基于维护方案所需的配件与储备资源进行比对,为维修服务商提供准确的比对结果和预警信息,无需维修服务商核对。

进一步地,作为本实施例的一种实施方式,可以基于服务商与智能设备之间的距离获取维修服务商,从而得到距离较短的维修服务商,如图6所示,上述步骤S241可以包括以下步骤S2411至步骤S2413。

步骤S2411:若维护方案为专业维护方案,则确定智能设备所关联的多个服务商。

在本实施例中,智能设备所关联的多个服务商可以是智能设备的生产服务商,也可以是智能设备的品牌服务商,还可以是专业维修智能设备的服务商。

步骤S2412:分别获取各个服务商与智能设备之间的距离。

在本实施例中,可以在预先构建的数据中查询各个服务商和智能设备的地理位置,基于各个服务商和智能设备的地理位置计算得到各个服务商与智能设备之间的距离。

在本实施例中,可以直接从数据库中查询各个服务商的地理位置,还可以先从数据库中查询各个服务商的名称,再联网查询各个服务商所处的地理位置。

步骤S2413:根据距离和预设的筛选规则从多个服务商中确定维修服务商。

在本实施例中,可以分别比较多个服务商与智能设备之间的距离大小,得到与智能设备之间的距离最近的服务商,并将该服务商确定为维修服务商,并获取该维修服务商的储备资源。其中,筛选规则可以是将距离按照从小到大的顺序依次选择,按照排列结果来确定维修服务商;筛选规则也可以是根据服务水平按照从高到低的顺序依次选择确定维修服务商;筛选规则还可以是根据派遣维修人员的人数的情况进行选择确定维修服务商;筛选规则又可以是前述多种条件进行多维度组合后按照权重比例择优选择确定维修服务商。例如,将与排名第一的距离对应的服务商确定为维修服务商。

在本实施例中,通过上述步骤S2411至步骤S2413的实施,能够基于各个服务商与智能设备之间的距离的远近程度来确定维修服务商,有效节省服务商到达智能设备所处位置的时间,尽快为出现异常的智能设备提供维修服务。

进一步地,作为本实施例的一种实施方式,可以基于维护方案和储备资源的实际情况,生成对应的比对结果,以发送至维修服务商,如图7所示,上述步骤S2431可以包括以下步骤S24311至步骤S24313。

步骤S24311:确定储备资源中是否包含配件信息。

在本实施例中,具体是将配件信息中的配件以及配件数量与储备资源中的配件以及配件数量进行比对,从而确定储备资源中是否包含配件信息。

步骤S24312:若储备资源包含配件信息,则将与配件信息对应的储备资源进行标记,以生成比对结果。

在本实施例中,对储备资源进行标记的方式不做具体限制,例如,可以将与配件信息对应的储备资源以表格的形式提取,将该表格作为比对结果;还可以将与配件信息对应的储备资源以清单的形式提取,将该清单作为比对结果。

步骤S24313:若储备资源不包含配件信息,则生成缺货信息表,以生成比对结果。

在本实施例中,该缺货信息表可以包括缺少的配件以及对应的配件数量。例如,配件为LED灯,配件信息中的配件LED灯三个,储备资源中LED灯为1个,此时缺货信息表中应当包括至少两个LED灯。

在本实施例中,通过上述步骤S24311至步骤S24313的实施,可以基于维护方案和储备资源的实际情况,生成对应的比对结果,以发送至维修服务商,从而实现提前预警维修服务商。

进一步地,作为本实施例的一种实施方式,可以基于维护方案确定维修智能设备的主体,以实现针对不同维护方案的维护类型做对应处理,如图8所示,智能设备的监控维护方法还可以包括以下步骤S25至步骤S27。

步骤S25:若维护方案为简易维护方案,则根据维护方案确认维护智能设备的维护主体。

在本实施例中,维护主体可以是修复智能设备的主体。例如,维护主体可以是服务端,还可以是用户端。

步骤S26:若维护主体为服务端,则获取维护方案的控制指令,并按照控制指令控制智能设备。

在本实施例中,控制指令可以是基于维护方案生成的指令,用于控制智能设备的工作状态。例如,维护方案为关闭智能设备中各个功能实现单元关闭十秒后重新启动各个功能实现单元,则控制指令为控制关闭智能设备中各个功能实现单元关闭十秒后重新启动各个功能实现单元的指令,从而控制各个功能实现单元关闭十秒后重新启动,完成修复智能设备。

步骤S27:若维护主体为用户端,则向用户端发送包含维护方案的提示信息。

在本实施例中,该提示信息可以是用于提示用户修复智能设备的信息。例如,维护方案为关闭智能设备中各个功能实现单元关闭十秒后重新启动各个功能实现单元,则提示信息为控制关闭智能设备中各个功能实现单元关闭十秒后重新启动各个功能实现单元的信息,用户根据该提示信息控制各个功能实现单元关闭十秒后重新启动,完成修复智能设备。

在本实施例中,用户端可以是可以接收信息的设备,该设备可以包括但不限于包括个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备等智能携带装置,还可以是安装于电子设备的应用程序等软件,此处不做具体限制。

在本实施例中,通过上述步骤S25至步骤S27的实施,可以根据维护方案的维护主体不同,选择对应的维护方案,当维护方案为简易维护方案,无需维修服务商派遣维修人员修复,实现服务端或者用户端自行完成对智能设备的修复,提高修复效率,节约用户修复智能设备的成本。

作为本实施例的一种实施方式,智能设备的数量为多个;多个智能设备之间形成通信连接。在实际运行时,多个智能设备之间的信息交互有可能发生异常,因此本实施例提供的智能设备的管理维护方法还用于根据智能设备之间的信息交互异常,自动处理对存在信息交互异常的智能设备进行处理。在本实施例中,智能设备之间的信息交互异常可以理解为设备关联异常,其属于智能设备有可能发生的异常状况的一种。基于此,在一些实施例中,在执行步骤S23时,当智能设备的异常类型为设备关联异常时,可以选择对应的处理方式,因此,上述步骤S23还可以包括以下步骤S231至步骤S232。

步骤S231:根据异常参数确定智能设备的异常类型,异常类型包括设备关联异常,设备关联异常为该智能设备与其他智能设备信息交互产生的异常。

在本实施例中,当在同一局域网下存在多个智能设备,且多个智能设备之间可以形成通信交互时,多个智能设备之间可以存在信息输送。具体地,该信息输送可以是用于控制与其通信交互的智能设备,还可以是获取与其通信交互的智能设备的信息。例如,多个智能设备包括第一智能设备和第二智能设备,当根据异常参数确定第一智能设备控制与第一智能设备通信交互的第二智能设备超过第一智能设备原有的控制权限,或者根据异常参数确定第一智能设备获取与第一智能设备通信交互的第二智能设备的隐私信息时,可以确定第一智能设备的异常类型为设备关联异常。

步骤S232:若智能设备的异常类型为设备关联异常,则断开该智能设备和与该智能设备进行通信交互的智能设备之间形成的通信连接。

在本实施例中,当多个智能设备包括第一智能设备和第二智能设备,第一智能设备控制与第一智能设备通信交互的第二智能设备超过第一智能设备原有的控制权限时,可以通过服务端可以控制第一智能设备与第二智能设备之间的通信连接断开。

也就是说,当智能设备发生设备关联异常时,通过服务端一侧对智能设备的控制,可以在无需向用户端和服务终端发送预警信息的情况下,完成智能设备的异常修复。

在本实施例中,当多个智能设备中的某一智能设备出现设备关联异常时,可以将控制该智能设备与其他智能设备之间的通信连接断开,该方法尤其适用于多个智能设备形成通信连接场景,有效防止智能设备的隐私信息泄露和智能设备控制失序情况出现,保护智能设备安全运行。

作为本实施例的一种实施方式,在实际运行时,在同一场景下的多个智能设备之间有可能相互影响导致发生异常,因此本实施例提供的智能设备的管理维护方法还用于当某一智能设备受其他智能设备影响发生异常时,自动对智能设备进行处理,完成智能设备的异常修复。在本实施例中,某一智能设备受其他智能设备影响发生的异常可以理解为设备关联异常,其属于智能设备有可能发生的异常状况的一种。基于此,在一些实施例中,智能设备的数量为多个;在执行步骤S23时,当智能设备的异常类型为场景触发异常时,可以选择对应的处理方式,因此,上述步骤S23还可以包括以下步骤S233至步骤S235。

步骤S233:根据异常参数确定智能设备的异常类型,异常类型包括场景触发异常,场景触发异常为该智能设备受其他智能设备影响发生的异常。

在本实施例中,场景触发异常可以是一个智能设备出现异常是另一个智能设备导致。例如,多个智能设备包括智能空调和智能门,根据智能空调的异常参数确定智能空调所处空间的温度下降速率较低,此时智能门处于开启状态,导致智能空调所处空间的气体流通状态较好,温度下降速率较低,此时,智能空调的异常类型为场景触发异常。

步骤S234:若智能设备的异常类型为场景触发异常,获取导致该智能设备发生异常的源触发智能设备。

以上述智能空调和智能门的示例为例,此时源触发智能设备为智能门。

步骤S235:通过控制源触发智能设备的状态,排除导致该智能设备发生异常的触发场景。

在本实施例中,源触发智能设备的状态具体可以是源触发智能设备的工作状态。以上述智能空调和智能门的示例为例,可以控制智能门关闭,使得智能空调所处空间的气体流通状态较差,从而有效降低智能空调所处空间的温度。

也就是说,当智能设备发生场景触发异常时,通过服务端一侧对智能设备的控制,可以在无需向用户端和服务终端发送预警信息的情况下,完成智能设备的异常修复。

通过上述步骤S233至步骤S235的实施,能够实现当智能设备的异常类型为场景触发异常时,可以选择对应的处理方式,而在此过程中,无需用户干预,提高了用户使用智能设备的体验。

作为本实施例的一种实施方式,在执行步骤S24时,可以基于智能设备的维护等级输出对应的预警信息,因此,上述步骤S24可以包括以下步骤S244至步骤S246。

步骤S244:根据维护方案确定智能设备的维护等级,维护等级包括第一维护等级和第二维护等级。

在本实施例中,若维护方案中存在修复智能设备所需的配件信息,则确定该智能设备的维护等级为第一等级;若维护方案中不存在修复智能设备所需的配件信息,则确定该智能设备的维护等级为第二等级。也就是说,当智能设备为第一维护等级时,修复智能设备需要更换配件;当智能设备为第二维护等级时,修复智能设备不需要更换配件。例如,智能设备为智能灯,维护方案为更换智能灯中的灯芯,此时智能设备的维护等级为第一维护等级;智能设备为风扇,维护方案为风扇螺丝松动,此时智能设备的维护等级为第二维护等级。

步骤S245:若智能设备为第一维护等级,则根据维护方案获取修复智能设备所需的配件,根据配件和储备资源确定预警信息,并输出预警信息。

在本实施例中,由于“根据维护方案获取修复智能设备所需的配件,根据配件和储备资源确定预警信息,并输出预警信息”的方法与上述描述的“根据维护方案获取修复智能设备所需的配件,将配件与储备资源进行比对,得到比对结果,根据比对结果确定预警信息,并输出预警信息”的方法类似,此处不再赘述。

步骤S246:若智能设备为第二维护等级,则根据储备资源确定预警信息,并输出预警信息。

在本实施例中,由于智能设备为第二维护等级时,维修人员修复智能设备时无需更换智能设备的配件,因此,维修人员可以无需携带配件。同时,由于在修复智能设备时需要维修工具,可以根据储备资源确定维修服务商中是否存在对应的维修工具,根据维修服务商中是否存在对应的维修工具来确定预警信息。例如,智能设备为风扇,维护方案为风扇螺丝松动,此时仅需要确定维修服务商的储备资源是否有与该风扇螺丝对应的螺丝刀。

通过上述步骤S244至步骤S246的实施,能够基于智能设备的维护等级输出对应的预警信息,实现个性化预警。

通过本实施例提供的智能设备的监控管理方法的实施,可以基于智能设备的运行信息获得异常参数,并根据异常参数确定维护方案,并基于维护方案输出预警信息,使得该智能设备的监控维护方法在实际实施时,可以自动得到维护方案并预警,无需维修人员实地对智能设备进行检修,有效减少人力投入,降低监控维护智能设备的成本,同时,当将预警信息发送至维修服务商时,维修服务商可以对过往的预警信息进行分析,统计各种异常出现的频率、异常原因等,根据分析统计结果提前对容易出现异常的智能设备进行预防处理,进一步防止智能设备出现异常;同时,维修服务商无需针对智能设备的每种异常状况进行维护处理,当智能设备需要维修专业性较高的维修人员才对维修服务商进行预警,同时自动匹配维修服务商中的储备资源,无需维修人员核算修复智能设备所需的资源,减少人力投入,降低监控维护智能设备的成本;还能够基于各个服务商与智能设备之间的距离的远近程度来确定维修服务商,有效节省服务商到达智能设备所处位置的时间,尽快为出现异常的智能设备提供维修服务;同时,当多个智能设备中的某一智能设备出现设备关联异常时,可以将控制该智能设备与其他智能设备之间的通信连接断开,该方法尤其适用于多个智能设备形成通信连接场景,有效防止智能设备的隐私信息泄露和智能设备控制失序情况出现,保护智能设备安全运行;并且能够实现当智能设备的异常类型为场景触发异常时,可以选择对应的处理方式,而在此过程中,无需用户干预,提高了用户使用智能设备的体验。

请参阅图9,其示出了本申请实施例提供的一种智能设备的监控维护装置的结构框图。该装置可以包括运行信息获取模块61、异常参数获取模块62、维护方案确定模块63和预警信息输出模块64。各功能模块详细说明如下:运行信息获取模块61,用于获取智能设备的运行信息。异常参数获取模块62,用于根据运行信息获取智能设备的异常参数。维护方案确定模块63,用于根据异常参数确定用于修复智能设备的维护方案。预警信息输出模块64,用于基于维护方案确定预警信息,并输出预警信息。

进一步地,作为本实施例的一种实施方式,维护方案包括专业维护方案,专业维护方案所涉及的维护提供方包括指定的维修服务商信息;预警信息输出模块64可以包括维修服务商获取单元、配件信息获取单元和预警信息发送单元。各功能单元详细说明如下:维修服务商获取单元,用于若维护方案为专业维护方案,则确定智能设备所关联的维修服务商。配件信息获取单元,用于根据维护方案得到修复智能设备所需的配件信息。预警信息发送单元,用于基于配件信息和维护方案确定预警信息,并向维修服务商发出预警信息。

进一步地,作为本实施例的一种实施方式,维修服务商获取单元可以包括服务商获取子单元、距离获取子单元和维修服务商确定子单元。各功能子单元详细说明如下:服务商获取子单元,用于若维护方案为专业维护方案,则确定智能设备所关联的多个服务商。距离获取子单元,用于分别获取各个服务商与智能设备之间的距离。维修服务商确定子单元,用于根据距离和预设的筛选规则从多个服务商中确定维修服务商。

进一步地,作为本实施例的一种实施方式,预警信息发送单元可以包括比对组件和信息发送组件。各功能组件详细说明如下:比对组件,用于获取维修服务商的储备资源,并将配件信息与储备资源进行比对。信息发送组件,用于将比对结果与预警信息发送给维修服务商。

进一步地,作为本实施例的一种实施方式,比对组件可以包括配件信息确定子组件、比对结果生成子组件和比对结果生成子组件。各功能子组件详细说明如下:配件信息确定子组件,用于确定储备资源中是否包含配件信息。比对结果生成子组件,用于若储备资源包含配件信息,则将与配件信息对应的储备资源进行标记,以生成比对结果。比对结果生成子组件,用于若储备资源不包含配件信息,则生成缺货信息表,以生成比对结果。

进一步地,作为本实施例的一种实施方式,维护方案还包括简易维护方案,智能设备的监控维护装置还可以包括维护主体确定模块、智能设备控制模块和提示信息发送模块。各功能模块详细说明如下:

维护主体确定模块,用于若维护方案为简易维护方案,则根据维护方案确认维护智能设备的维护主体;智能设备控制模块,用于若维护主体为服务端,则获取维护方案的控制指令,并按照控制指令控制智能设备;以及提示信息发送模块,用于若维护主体为用户端,则向用户端发送包含维护方案的提示信息。

进一步地,作为本实施例的一种实施方式,异常参数获取模块62可以包括异常确定模块、异常代码获取单元和运行参数获取单元。各功能单元详细说明如下:异常参数获取单元,用于根据运行信息获取智能设备的异常参数,分析异常参数并确定智能设备是否出现异常。异常代码获取单元用于若智能设备出现异常,则获取智能设备的异常代码。运行参数获取单元,用于根据异常代码确定智能设备的异常问题,并对异常问题进行标准化处理,得到维护方案。

所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述装置和模块的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。

在本申请所提供的几个实施例中,所显示或讨论的模块相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或模块的间接耦合或通信连接,可以是电性,机械或其它的形式。

另外,在本申请各个实施例中的各功能模块可以集成在一个处理模块中,也可以是各个模块单独物理存在,也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。

请参阅图10,其示出了本申请实施例提供的一种服务器800,包括:处理器810、通信模块820、存储器830和总线。处理器810、通信模块820和存储器830通过总线相互连接并完成相互间的通信。总线可以是ISA总线、PCI总线或EISA总线等。总线可以分为地址总线、数据总线、控制总线等。其中:

存储器830,用于存放程序。具体地,存储器830可用于存储软件程序以及各种数据。存储器830可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作至少一个功能所需的应用程序可以包括程序代码,程序代码包括计算机操作指令。除了存放程序之外,存储器830还可以暂存通信模块820需要发送的消息等。存储器830可能包含高速RAM存储器,也可能还包括非易失性存储器(non-volatile memory),例如至少一个磁盘存储器。

处理器810用于执行存储器830存放的程序。程序被处理器执行时实现上述各实施例的基于智能设备的监控维护方法的步骤。

本申请实施例还提供一种计算机可读存储介质,计算机可读存储介质上存储有计算机程序,该计算机程序被处理器执行时实现上述基于智能设备的监控维护方法实施例的各个过程,且能达到相同的技术效果,为避免重复,这里不再赘述。其中,的计算机可读存储介质,如只读存储器(Read-Only Memory,简称ROM)、随机存取存储器(Random AccessMemory,简称RAM)、磁碟或者光盘等。

需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端(可以是手机,计算机,服务器,空调器,或者网络设备等)执行本申请各个实施例的方法。

上面结合附图对本申请的实施例进行了描述,但是本申请并不局限于上述的具体实施方式,上述的具体实施方式仅仅是示意性的,而不是限制性的,本领域的普通技术人员在本申请的启示下,在不脱离本申请宗旨和权利要求所保护的范围情况下,还可做出很多形式,均属于本申请的保护之内。

相关技术
  • 智能设备的监控维护方法、装置、服务器及存储介质
  • 一种服务器故障维护方法、装置、服务器及存储介质
技术分类

06120112189823