CN117278385A - 异常恢复方法、相关装置、设备以及计算机可读存储介质 - Google Patents

Abstract

本申请实施例公开一种异常恢复方法、相关装置、设备以及计算机可读存储介质，该异常恢复方法包括：在通信模块中的第一业务模块出现目标异常的情况下，执行第一业务模块的异常自恢复流程；当通过第一业务模块的异常自恢复流程无法恢复正常时，基于目标异常更新异常统计表；基于异常统计表确定异常恢复方式，并执行异常恢复方式。本申请实施例，可以提高异常恢复的效率。

Description

异常恢复方法、相关装置、设备以及计算机可读存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种异常恢复方法、相关装置、设备以及计算机可读存储介质。

背景技术

随着通信技术的发展，通信模块的使用场景也越来越多，支持的功能也越来越多，相应地，通信模块的整体功能架构也越来越复杂。在通信模块运行过程中，其中一些功能模块可能会出现异常。

与此同时，在功能模块出现异常的情况下，如何提高异常恢复的效率是技术人员关注的问题。

发明内容

本申请实施例公开了一种异常恢复方法、相关装置、设备以及计算机可读存储介质，可以降低异常恢复的影响，提高异常恢复的效率。

第一方面公开一种异常恢复方法，该异常恢复方法可以应用于电子设备，也可以应用于电子设备中的模块(例如，通信模块、通信模块中的处理器等)，还可以应用于能实现全部或部分电子设备功能的逻辑模块或软件。下面以应用于电子设备为例进行描述。该异常恢复方法可以包括：在通信模块中的第一业务模块出现目标异常的情况下，执行该第一业务模块的异常自恢复流程；当通过该第一业务模块的异常自恢复流程无法恢复正常时，基于该目标异常更新异常统计表；基于该异常统计表确定相对应的异常恢复方式，并执行该异常恢复方式。

本申请实施例中，当通信模块中的某个业务模块出现异常时，可以先执行自身的异常自恢复流程，当自身的异常自恢复流程无法恢复时，可以再基于异常统计表确定恢复面更广的异常恢复方式，并执行对应的异常恢复方式，以实现异常的自恢复。其中，由于业务模块自身的异常自恢复流程相较于拨号重置、SIM卡重置和通信模块重启等恢复方式而言，耗时较短，影响较小，而拨号重置、SIM卡重置和通信模块重启等恢复方式相较于业务模块自身的异常自恢复流程而言，恢复面更广，因此，本方案先通过业务模块自身的异常自恢复流程进行异常恢复，可以降低异常恢复的影响，提高异常恢复的效率。

作为一种可能的实现方式，该第一业务模块的处理过程包括多个阶段，该多个阶段中的每个阶段均有对应的异常自恢复流程，该执行该第一业务模块的异常自恢复流程包括：确定该第一业务模块出现异常的目标阶段；执行该目标阶段对应的异常自恢复流程。

本申请实施例中，由于业务模块的整个处理过程中的不同处理阶段出现异常的原因可能不同，因此，可以针对业务模块的处理过程的每一个处理阶段均预设对应的异常自恢复流程，这样，可以保证对于不同的处理阶段出现的异常，均可以通过对应的异常自恢复流程尝试进行异常恢复，可以提高异常恢复的概率。

作为一种可能的实现方式，该异常统计表包括异常的触发次数，该基于该目标异常更新异常统计表包括：将该异常统计表中该目标异常的触发次数加1；该基于该异常统计表确定相对应的异常恢复方式包括：基于该更新后的所述目标异常的触发次数确定相对应的异常恢复方式。

本申请实施例中，可以基于目标异常的触发次数确定恢复方式，这样，可以使得确定的恢复方式较为合适，可以提高异常恢复的效率。

作为一种可能的实现方式，该基于更新后的该目标异常的触发次数确定相对应的异常恢复方式包括：在该更新后的该目标异常的触发次数小于第一阈值的情况下，确定该异常恢复方式为拨号重置；在该更新后的该目标异常的触发次数大于或等于第一阈值，且小于第二阈值的情况下，确定该异常恢复方式为SIM卡重置；在该更新后的该目标异常的触发次数大于或等于第二阈值的情况下，确定该异常恢复方式为通信模块重启。

本申请实施例中，可以将目标异常的触发次数与预先设定的阈值进行比较，从而可以快速准确地确定出对应的异常恢复方式。

作为一种可能的实现方式，该方法还包括：确定该目标异常的优先级；该基于更新后的该目标异常的触发次数确定相对应的异常恢复方式包括：基于该目标异常的优先级和该更新后的该目标异常的触发次数确定异常恢复方式。

本申请实施例中，在可以将异常分为多个优先级，优先级越高，表示目标异常的严重程度越高，优先级越低，表示目标异常的严重程度越低。基于此，在确定异常恢复方式时，可以结合目标异常的优先级和目标异常的触发次数综合确定异常恢复方式，这样，可以提高确定的异常恢复方式的准确性。

作为一种可能的实现方式，该基于更新后的该目标异常的触发次数确定相对应的异常恢复方式包括：基于该目标异常的特性和该更新后的该目标异常的触发次数确定第一执行等级；将该第一执行等级和当前的执行等级中等级较高的确定为目标执行等级；基于该目标执行等级确定异常恢复方式。

作为一种可能的实现方式，该通信模块包括第一业务模块、异常恢复模块和主控，该方法还包括：

当通过该第一业务模块的异常自恢复流程无法恢复正常时，该第一业务模块向该异常恢复模块发送异常信息；

该异常恢复模块基于该异常信息更新异常统计表；

该异常恢复模块基于更新后的该异常统计表确定相对应的异常恢复方式；

该异常恢复模块向该主控发送该异常恢复方式；

该主控通知相应的模块执行该异常恢复方式。

第二方面公开一种异常恢复装置，该异常恢复装置可以为电子设备，也可以为电子设备中的通信模块(模组)，该异常恢复装置可以包括：

第一执行模块，用于在通信模块中的第一业务模块出现目标异常的情况下，执行该第一业务模块的异常自恢复流程；

更新模块，用于当该第一业务模块的异常自恢复流程无法恢复正常时，基于该目标异常更新异常统计表；

确定模块，用于基于该异常统计表确定相对应的异常恢复方式；

第二执行模块，用于执行该异常恢复方式。

第三方面公开一种电子设备，该电子设备包括处理器、存储器，该处理器调用该存储器中存储的计算机程序或计算机指令实现如上述第一方面以及第一方面中任一可能的实现方式中所提供的异常恢复方法。

第四方面公开一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序或计算机指令，当该计算机程序或计算机指令运行时，实现如上述各方面公开的异常恢复方法。

第五方面公开一种芯片，包括处理器，用于执行存储器中存储的程序，当程序被执行时，使得芯片执行上述各方面公开的异常恢复方法。

作为一种可能的实施方式，存储器位于芯片之外。

应理解，本申请上述多个方面或者任一种可能的实施方式的实现和有益效果可互相参考。

附图说明

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

图1是本申请实施例公开的一种系统架构示意图；

图2是本申请实施例公开的一种异常恢复方法的流程示意图；

图3是本申请实施例公开的一种执行等级1(level-1)下的流程示意图；

图4是本申请实施例公开的一种执行等级2(level-2)下的流程示意图；

图5是本申请实施例公开的一种执行等级3(level-3)下的流程示意图；

图6是本申请实施例提供的一种异常恢复装置的结构示意图；

图7是本申请实施例公开的一种电子设备的结构示意图。

具体实施方式

本申请实施例公开了一种异常恢复方法、相关装置、设备以及计算机可读存储介质，可以降低异常恢复的影响，提高异常恢复的效率。下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

为了更好地理解本申请实施例，下面先对本申请实施例的相关技术进行描述。

随着通信技术的发展，通信模块的使用场景也越来越多，对通信模块的可靠性、安全性的要求也越来越高。示例性的，针对于具有PC(personal computer，个人电脑)-IOT(internet of things，物联网)功能的通信模块而言，其一般运行在无人值守或者整个操作系统(operating system，OS)处于休眠/关机状态的环境中。目前，这种场景下，通信模块的功能主要依赖于各个功能模块的稳定性，如果某个功能模块出现异常，通常需要人工进行干预，如重启PC(如笔记本电脑)等。这种解决方案耗时较长，影响异常恢复的效率。

本申请实施例中，为了解决上述问题，提出了一种异常恢复方法，该异常恢复方法主要包括两部分，一部分为各个功能模块的异常自恢复，另一部分为整个模块系统的异常自恢复。当某个功能模块出现异常时，可以先执行自身的异常自恢复流程，当自身的异常自恢复流程无法恢复时，可以再执行整个模块系统的异常自恢复流程。并且，整个模块系统的异常自恢复可以分为多个层级，如重新拨号、SIM(subscriber identity module,用户标识模块)卡重置、通信模块重启等。可见，这种方式下，可以在某个功能模块出现异常的情况下，自动进行异常恢复。并且，异常恢复分为多个层级，可以尽量减轻对整个模块系统的影响，可以提高异常恢复的效率。

为了更好地理解本申请实施例，下面先对本申请实施例的系统架构进行描述。

请参阅图1，图1是本申请实施例公开的一种系统架构示意图。如图1所示，该系统架构可以为PC-IOT功能的软件架构。

其中，PC IoT平台服务(PC-IoT platform Service)100可以包括主控(PCClient)101以及多个功能模块，如图1所示的设备管理单元(Device Manager)102、拨号管理单元(Connection Manager)103等。此外，PC IoT平台服务(100)还可以包括用于异常恢复的异常恢复管理模块(PC IoT Recovery Manager)104，以及用于适配的适配层(PC IoTAdaptor Layer)105。

主控也可以称为客户端等，可以用于接收来自异常恢复管理模块104的异常恢复方式，并通知对应的模块执行相应的异常恢复方式。

设备管理单元102可以用于设备的管理和控制，如管理和控制硬件资源，监控设备的状态等，并可以提供相应的管理功能，如SIM卡重置、通信模块重启等。

拨号管理单元103可以用于管理拨号功能，如配置和管理相关拨号参数、监测拨号过程。此外，整个系统架构还可以包括空中升级模块(firmware over-the-air，FOTA)、电子SIM卡管理服务(Esim Service)、嵌入式控制器管理服务(embedded controller service，EC Service)、定位服务(Location Service)、消息队列遥测传输客户端(message queuingtelemetry transport，MQTT Client)等功能模块。需要说明的是，设备管理单元102、拨号管理单元103、空中升级模块、电子SIM卡管理服务、嵌入式控制器管理服务、定位服务、消息队列遥测传输客户端等功能模块可以称为业务模块。

异常恢复管理模块104(下述简称为Recovery模块)，主要负责异常恢复的相关处理，如确定异常恢复方式、向主控发送异常恢复方式等。

适配层105为整个架构的适配层，主要作用是在不同的系统、平台或者接口之间进行数据的转换和适配，以实现它们之间的互操作性和兼容性。例如，通过适配层105可以使得整个系统架构可以适配于不同厂家的通信芯片。

本申请实施例中，在设备管理单元102、拨号管理单元103、空中升级模块、电子SIM卡管理服务、嵌入式控制器管理服务、定位服务、消息队列遥测传输客户端等功能模块出现异常的情况下，各个功能模块可以先执行自身的异常自恢复流程，如果自身的异常自恢复流程无法恢复，可以向异常恢复管理模块104发送异常消息。异常恢复管理模块104接收到异常消息之后，可以基于当前的情况确定异常恢复方式(如重新拨号、SIM重置、通信模块重启中的一种)，之后，可以向主控101发送确定的异常恢复方式。主控101接收到来自异常恢复管理模块104的异常恢复方式之后，可以通知相应的模块执行。

可以理解的是，图1所示的软件架构可以应用于通信模块中。通信模块可以集成在智能手机、笔记本电脑、平板电脑等电子设备中。其中，针对于集成在PC(如笔记本电脑)等场景而言，无论PC是处于正常开机状态(即工作状态)，还是处于关机状态或休眠状态，具有PC-IOT功能的通信模块可以与PC上的EC(嵌入式控制器)始终保持工作状态，并通过EC协议进行交互。

需要说明的是，可以实现本申请实施例所提供的技术方案的软件架构可以有多种，图1所示的软件结构只是一种示例性说明，并不对其构成限定。在本申请另一些实施例中，图1所示的软件结构可以包括比图示更多或更少的软件模块，或者合并某些模块，或者拆分某些模块，或者不同的模块设置等，这里不作限制。

为了更好地理解本申请实施例，下面先对申请实施例所提供的异常恢复方法的整体构思进行介绍。本申请实施例所提供的异常恢复方法主要包括两个阶段，第一个阶段为具体功能的异常自恢复，第二个阶段为整个模块系统的异常自恢复。当某个功能模块(如FOTA)出现异常时，首先会执行第一阶段的自恢复流程，也即是该功能模块自身的异常自恢复流程，如果该功能模块自身的异常自恢复流程无法解决异常，会执行第二阶段的自恢复流程，也即是整个模块系统的异常自恢复流程。由于第一阶段的异常自恢复流程相较于第二阶段的异常自恢复流程一般耗时较短，影响较小，而第二阶段的异常自恢复流程相较于第一阶段的异常自恢复流程一般恢复面更广，因此，通过这种两级的异常恢复方式，可以降低异常恢复的影响，提高异常恢复的效率。

下面结合图2对本申请实施例所提供的异常恢复方法的总体流程进行示例性说明。如图2所示，该处理流程可以包括但不限于如下步骤：

201.第一业务模块检测到异常并执行异常自恢复流程。

其中，第一业务模块可以为通信模块中的任一业务模块，例如，第一业务模块可以为Device Manager、Connection Manager、FOTA、Esim Service、EC Service、LocationService、MQTT Client中的任一业务模块。

第一业务模块在运行过程中，可以检测自身是否出现异常，在出现异常的情况下，第一业务模块可以执行自身的异常自恢复流程(异常自恢复逻辑)。针对于各个业务模块的自恢复逻辑，在一种可能的实现方式中，可以以各个业务模块的功能的执行流程为中心，梳理出整个执行流程各个阶段的异常场景，并对各个阶段的异常场景预先制定对应的自恢复逻辑(即自恢复策略)。这样，当整个执行流程中某个阶段出现异常时，可以先执行该阶段对应的异常自恢复流程。示例性的，假设将某个业务模块的整个执行流程划分为3个阶段，分别为阶段1、阶段2和阶段3，可以分别针对阶段1、阶段2、阶段3各自可能存在的异常情况预先制定对应的自恢复逻辑，如阶段1对应的自恢复逻辑可以为重新分配资源，阶段2对应的自恢复逻辑可以为等待5秒(s)，重新发起连接请求，阶段3对应的自恢复逻辑可以为业务模块重启。基于此，当之后某个阶段出现异常时，可以均先执行对应的自恢复逻辑进行异常恢复。

202.在异常自恢复流程无法恢复的情况下，第一业务模块向Recovery模块发送异常信息。

在异常自恢复流程无法恢复的情况下，第一业务模块可以调用Recovery模块提供的API(application programming interface，应用程序编程接口)接口向Recovery模块发送异常信息。异常信息可以包括异常的标识(ID)，也可以包括异常类型等。

203.Recovery模块基于异常信息更新异常统计表。

Recovery模块在接收到来自第一业务模块的异常信息之后，可以基于异常信息更新异常统计表，如将目标异常的触发次数加1。异常统计表可以包括各类异常的触发次数，也可以包括当前异常恢复等级等信息，还可以包括其它与异常相关的统计信息，本申请实施例对此不作限定。

204.Recovery模块基于异常统计表确定异常恢复方式。

Recovery模块更新异常统计表之后，可以基于异常统计表确定异常恢复方式。其中，异常恢复方式可以包括重新拨号(拨号重置)、SIM卡重置(SIM卡复位)、通信模块重启(通信模块复位)等。

本申请实施例中，基于异常统计表确定异常恢复方式时，可以仅考虑当前触发的异常(下述简称为目标异常)，也即是此次异常信息对应的异常，也可以考虑整体异常情况。在仅考虑当前触发的异常的情况下，Recovery模块可以基于异常统计表中目标异常的触发次数确定异常恢复方式。在考虑整体异常的情况下，Recovery模块可以基于异常统计表中所有异常的触发次数确定异常恢复方式。在一种可能的实现方式中，针对于每一种异常均可以预设有对应的异常恢复方式，例如，针对于异常1，当异常1的触发次数小于阈值1(即第一阈值)时，对应的异常恢复方式可以为重新拨号。当异常1的触发次数大于或等于阈值1且小于阈值2(即第二阈值)时，对应的异常恢复方式可以为SIM卡重置。当异常1的触发次数大于或等于阈值2时，对应的异常恢复方式可以为通信模块重启。阈值2大于阈值1，如阈值1为3，阈值2为6。基于预设的各种异常的触发次数与异常恢复方式之间的对应关系，Recovery模块可以基于异常统计表中目标异常的触发次数直接确定对应的异常恢复方式。

在一种可能的实现方式中，Recovery模块在基于异常统计表中目标异常的触发次数确定异常恢复方式时，还可以考虑目标异常的特性，也就是说，Recovery模块可以基于异常统计表中目标异常的触发次数和目标异常的特性确定异常恢复方式。其中，目标异常的特性可以包括目标异常的优先级，优先级越高，表示目标异常的严重程度越高，优先级越低，表示目标异常的严重程度越低。示例性的，假设目标异常的优先级分为2级，当目标异常的优先级为1，且目标异常的触发次数小于阈值3(第三阈值)时，对应的异常恢复方式可以为重新拨号。当目标异常的优先级为1，且目标异常的触发次数大于或等于阈值3且小于阈值4(第四阈值)时，对应的异常恢复方式可以为SIM卡重置。当目标异常的优先级为1，且目标异常的触发次数大于或等于阈值4时，对应的异常恢复方式可以为通信模块重启。当目标异常的优先级为2，且目标异常的触发次数小于阈值5(第五阈值)时，对应的异常恢复方式可以为重新拨号。当目标异常的优先级为2，且目标异常的触发次数大于或等于阈值5且小于阈值6(第六阈值)时，对应的异常恢复方式可以为SIM卡重置。当目标异常的优先级为2，且目标异常的触发次数大于或等于阈值6时，对应的异常恢复方式可以为通信模块重启。其中，阈值4可以大于阈值3，阈值6可以大于阈值5，且阈值6可以小于阈值4，阈值5可以小于阈值3，如阈值3为5，阈值4为8，阈值5为3，阈值6为6。基于预设的各种优先级的异常的触发次数与异常恢复方式之间的对应关系，Recovery模块可以基于异常统计表中目标异常的触发次数和目标异常的优先级确定异常恢复方式。

在另一种可能的实现方式中，可以预先定义多个执行等级(即异常执行等级)，每个执行等级对应不同的处理流程。示例性的，可以定义3个执行等级，分别为level-1(等级1)、level-2(等级2)和level-3(等级3)，这3个执行等级与重新拨号、SIM卡重置和通信模块重启这3种异常恢复方式相关。Recovery模块可以基于异常统计表中目标异常的触发次数、目标异常的特性和当前的执行等级确定目标执行等级，然后可以执行目标执行等级对应的处理流程，以确定对应的异常恢复方式。关于各个执行等级的处理流程更详细的描述，可以参见下述关于图3、图4和图5的相关描述。

需要说明的是，上述确定异常恢复方式的手段仅是示例性说明，在本申请另一些实施例中，还可以在上述方式的基础上进行改动或者通过其它方式确定异常恢复方式。例如，基于目标异常的发生频率确定异常恢复方式，再例如，基于目标异常的类型和目标异常的触发次数确定异常恢复方式，再例如，基于目标异常的优先级确定异常恢复方式，在此不作限定。

205.Recovery模块向Logging模块发送异常日志。

Recovery模块在确定异常恢复方式之后，可以向Logging模块(日志模块)发送异常日志。异常日志可以包括异常发生的时间、异常类型、确定的异常恢复方式等。

在一种可能的实现方式中，Recovery模块可以在接收到来自第一业务模块的异常消息之后，向Logging模块发送异常日志，也即是在步骤202之后，向Logging模块发送异常日志。

206.Logging模块保存异常日志。

Logging模块接收到来自Recovery模块的异常日志之后，可以保存异常日志。Logging模块可以将异常日志保存到本地，也可以上传到云端。

需要说明的是，上述步骤205和步骤206是可选地。

207.Recovery模块向PC Client发送确定的异常恢复方式。

Recovery模块确定异常恢复方式之后，可以调用PC Client提供的API接口向PCClient发送确定的异常恢复方式。

可以理解的是，步骤205与步骤207之间的执行顺序可以调整，如Recovery在执行步骤204之后，可以先执行步骤207，再执行步骤205。

208.PC Client根据接收到的异常恢复方式通知目标模块做相应的恢复动作。

PC Client接收到来自Recovery模块的异常恢复方式之后，可以向对应的目标模块发送第二指示信息，第二指示信息用于指示对应的目标模块做相应的恢复动作。相应地，目标模块可以接收到来自PC Client的第二指示信息，并可以基于第二指示信息做相应的恢复动作，如SIM卡重置。在一种可能的实现方式中，目标模块接收到来自PC Client的第二指示信息之后，可以向PC Client发送RSP(response，响应)，以告知PC Client自身接收到了第二指示信息。

示例性的，在确定的异常恢复方式为模块重启的情况下，PC Client可以向设备管理单元发送对应的指示信息，指示设备管理单元进行模块重启。

可以理解的是，第二阶段的异常自恢复主要可以解决通信模块的基础功能的异常，包括但不限于IoT拨号异常、注册异常、射频开关异常、GPS(global positioningsystem，全球定位系统)异常、SIM卡初始化异常、I2C(inter integrated circuit，集成电路总线)连接异常、系统异常等。

209.在异常恢复的情况下，PC Client向Recovery模块发送第一指示信息，第一指示信息用于指示异常恢复。

在目标模块执行相应的恢复动作之后，第一业务模块可以重新执行对应的处理流程，如果未出现目标异常，表明异常已经恢复，在一种可能的实现方式中，在第一业务模块确定异常恢复的情况下，第一业务模块可以向PC Client发送第三指示信息，如调用Recovery模块提供的API接口向Recovery模块发送第三指示信息，第三指示信息用于指示异常恢复。PC Client接收到第三指示信息之后，可以确定异常已经恢复，可以向Recovery模块发送第一指示信息，第一指示信息用于指示异常恢复。或者，在另一种可能的实现方式中，PC Client可以监测第一业务模块的处理流程，在监测到未出现目标异常的情况下，可以确定异常已经恢复，可以向Recovery模块发送第一指示信息，第一指示信息用于指示异常恢复。

210.Recovery模块清除异常统计表中存储的信息。

Recovery模块接收到第一指示信息之后，可以确定异常已经恢复，可以清除异常统计表中存储的信息。这里的清除异常统计表中存储的信息主要是将异常统计表恢复到初始状态，包括将各个异常的触发次数均归零。需要说明的是，在一些情况下，异常统计表中可以存储有多种异常的信息，而成功恢复的可能仅为其中一部分异常(如目标异常)，这种情况下，Recovery模块可以仅清除异常统计表中已经成功恢复的异常对应的信息，以便于之后可以继续基于异常统计表确定异常恢复方式。

下面结合图3、图4和图5分别对本申请中的3个执行等级的处理流程进行示例性说明。应理解，图3、图4和图5所示的处理流程主要是对上述步骤204中一种实现方式的详细描述，不应对本申请实施例造成限定。请先参阅图3，图3是level-1对应的流程示意图，如图3所示，该处理流程可以包括但不限于如下步骤：

301.Recovery模块接收到一条异常消息。

在第一业务模块通过自身的异常自恢复流程无法恢复时，第一业务模块可以向Recovery模块发送异常信息。相应地，Recovery模块可以接收到来自第一业务模块的异常消息。

302.Recovery基于目标异常的触发次数、目标异常的特性和当前的执行等级确定目标执行等级CurrentExectionLevel。

Recovery模块接收到异常消息之后，可以基于目标异常的触发次数、目标异常的特性和当前的执行等级确定目标执行等级CurrentExectionLevel。应理解，目标异常的触发次数等信息可以存储在异常统计表中，并且，在接收到异常消息之后，Recovery模块可以更新异常统计表，具体可以参考上述步骤202和203中的相关描述。

在一种可能的实现方式中，目标异常的特性包括目标异常的优先级。这种情况下，Recovery基于目标异常的触发次数、目标异常的特性和当前的执行等级确定目标执行等级CurrentExectionLevel具体包括：Recovery基于目标异常的触发次数、目标异常的优先级和当前的执行等级确定目标执行等级CurrentExectionLevel。其中，针对不同的优先级和触发次数，可以预先配置有对应的执行等级，也即是预先配置有各种优先级的异常的触发次数与执行等级之间的对应关系。例如，假设目标异常的优先级分为2级，当目标异常的优先级为1，且目标异常的触发次数小于阈值3时，对应的执行等级可以为level-1。当目标异常的优先级为1，且目标异常的触发次数大于或等于阈值3且小于阈值4时，对应的执行等级可以为level-2。当目标异常的优先级为1，且目标异常的触发次数大于或等于阈值4时，对应的执行等级可以为level-3。当目标异常的优先级为2，且目标异常的触发次数小于阈值5时，对应的执行等级可以为level-1。当目标异常的优先级为2，且目标异常的触发次数大于或等于阈值5且小于阈值6时，对应的执行等级可以为level-2。当目标异常的优先级为2，且目标异常的触发次数大于或等于阈值6时，对应的执行等级可以为level-3。其中，阈值4可以大于阈值3，阈值6可以大于阈值5，且阈值6可以小于阈值4，阈值5可以小于阈值3，如阈值3为5，阈值4为8，阈值5为3，阈值6为6。可见，基于上述预先配置的各种优先级的异常的触发次数与执行等级之间的对应关系，Recovery模块可以基于目标异常的触发次数和目标异常的优先级确定出一个执行等级(下述称为第一执行等级)。之后，Recovery模块可以将第一执行等级和当前的执行等级进行比较，将其中执行等级较高的确定为目标执行等级。例如，假设第一执行等级为level-3，当前的执行等级为level-2，这种情况下，Recovery模块可以将第一执行等级level-3确定为目标执行等级。应理解，在每一次确定目标执行等级之后，可以将当前的执行等级更新为确定得到的目标执行等级。

需要说明的是，在初始情况下，还未发生任何异常，此时，每一个执行等级默认的状态可以均为deactive(未激活)，并且，每一个执行等级对应的计数器的值默认为0。还需要说明的是，每一个执行等级对应的计数器可以为一个变量(如count)。

303.在目标执行等级为level-1的情况下，Recovery模块可以更新level-1的状态为active，并可以将level-1的计数器加1。

当Recovery模块确定的目标执行等级为level-1时，Recovery模块可以更新level-1的状态为active，并可以将level-1的计数器加1。其中，level-1的状态为active表示level-1处于激活状态，也即是正在执行level-1的处理流程。

在一些实施例中，在执行步骤303之前，可以先判断level-1的计数器的值，如果取值大于第八阈值(如4)，则表明已经进行过多次重新拨号，此时，可以直接跳转到level-2的处理流程进行处理，可以不用执行level-1的处理流程。

304.Recovery模块向主控发送拨号重置请求。

Recovery模块更新level-1的状态为active，并将level-1的计数器加1之后，可以向主控发送拨号重置请求。相应地，主控可以接收到来自Recovery模块的拨号重置请求，并可以基于拨号重置请求通知对应的目标模块重新拨号。

305.Recovery模块更新level-1的状态为deactive。

在向主控发送拨号重置请求之后，Recovery模块可以更新level-1的状态为deactive。

下面请参阅图4，图4是level-2对应的流程示意图，如图4所示，该处理流程可以包括但不限于如下步骤：

301.Recovery模块接收到一条异常消息。

302.Recovery基于目标异常的触发次数、目标异常的特性和当前的执行等级确定目标执行等级CurrentExectionLevel。

306.在目标执行等级为level-2的情况下，Recovery模块可以先判断level-3的状态是否为deactive，在为deactive的情况下，可以执行步骤307，在不为deactive的情况下，可以执行步骤318。

具体地，由于在当前执行等级为level-2，以及level-2对应的计数器大于第七阈值等情况下，可以通过通信模块重启进行异常恢复，相当于执行level-3对应的异常恢复方式。因此，当这些情况之后再次需要进行异常恢复时，没有必要再采用比通信模块重启恢复面较小的恢复方式，如level-2对应的SIM卡重置。

故而，当Recovery模块确定的目标执行等级为level-2时，Recovery模块可以先判断level-3的状态是否为deactive，如果level-3的状态为deactive，则表明level-3还处于未激活的状态，此时，可以执行level-2对应的处理流程，可以执行步骤307，如果level-3的状态不为deactive，也即是为active或active_not_running，则表明level-3处于已激活或者已激活但未执行的状态，这种情况下，没有必要再执行步骤307以及之后的相关步骤，可以直接执行level-3对应的相关处理流程，可以执行步骤318。可见，上述通过先判断level-3的状态是否为deactive可以避免不必要的处理，从而可以提高异常恢复的效率。

307.Recovery模块判断level-2的计数器是否大于第七阈值，在大于第七阈值的情况下，可以执行步骤316，在小于或等于第七阈值的情况下，可以执行步骤308。

Recovery模块判断出level-3的状态为deactive之后，可以继续判断level-2的计数器的取值是否大于第七阈值，如果大于第七阈值，则表明SIM卡重置次数已达到最大重试次数，可以通过模块重启进行异常恢复，可以执行步骤316。如果小于或等于第七阈值，则表明SIM卡重置次数未达到最大重试次数，可以继续尝试通过SIM卡重置进行异常恢复，可以执行步骤308。

308.Recovery模块判断level-2的状态是否为deactive，在为deactive的情况下，可以执行步骤309，在不为deactive的情况下，可以执行步骤312。

当Recovery模块确定level-2的计数器的取值小于或等于第七阈值之后，Recovery模块可以判断level-2的状态是否为deactive，如果level-2的状态为deactive，则表明level-2还处于未激活的状态，可以执行步骤309，如果level-2的状态不为deactive，也即是为active或active_not_running，则表明level-2处于已激活或者已激活但未执行的状态，这种情况下，可以执行步骤312。

309.Recovery模块更新level-2的状态为active，并可以将level-2的计数器加1。

当Recovery模块确定level-2的状态为deactive之后，Recovery模块可以更新level-2的状态为active，并可以将level-2的计数器加1。

310.Recovery模块向主控发送SIM卡重置请求。

Recovery模块更新level-2的状态为active，并将level-2的计数器加1之后，可以向主控发送SIM卡重置请求。相应地，主控可以接收到来自Recovery模块的SIM卡重置请求，并可以基于SIM卡重置请求通知对应的目标模块进行SIM卡。

311.Recovery模块更新level-2的状态为active_not_running。

在向主控发送SIM卡重置请求之后，Recovery模块可以更新level-2的状态为active_not_running。

312.Recovery模块判断level-2的状态是否为active，在为active的情况下，可以执行步骤314，在不为active的情况下，可以执行步骤313。

当Recovery模块确定level-2的状态不为deactive之后，Recovery模块可以进一步判断level-2的状态是否为active，如果为active，则表明level-2处于激活的状态，可以不用进行处理，如果不为active，也即是为active_not_running，则表明level-2处于已激活但未执行的状态，这种情况下，可以执行步骤313。

313.Recovery模块更新level-2的状态为active，并可以将level-2的计数器加1。

当Recovery模块确定level-2的状态为active_not_running之后，Recovery模块可以更新level-2的状态为active，并可以将level-2的计数器加1。

314.Recovery模块向主控发送SIM卡重置请求。

Recovery模块更新level-2的状态为active，并将level-2的计数器加1之后，可以向主控发送SIM卡重置请求。相应地，主控可以接收到来自Recovery模块的SIM卡重置请求，并可以基于SIM卡重置请求通知对应的目标模块进行SIM卡。

需要说明的是，由于SIM卡重置相较于重新拨号需要的时间较长，并且会导致通信的中断，因此，在一些实施例，为了降低影响，可以根据level-2的计数器的取值确定第一时长，然后启动第一时长的计时器。当第一时长的计时器超时之后，再向主控发送SIM卡重置请求。在一种可能的实现方式中，可以预先配置有level-2的异常恢复间隔表，该表中可以存储有不同的计数器取值对应的时长，Recovery模块可以直接基于level-2的计数器的取值从level-2的异常恢复间隔表中确定对应的第一时长。

315.Recovery模块更新level-2的状态为active_not_running。

在向主控发送SIM卡重置请求之后，Recovery模块可以更新level-2的状态为active_not_running。

316.Recovery模块更新level-3的状态为active_not_running，并将level-3的计数器加1，以及更新level-2的状态为deactive。

当Recovery模块确定level-2的计数器的取值大于第七阈值之后，则表明已经进行过多次SIM卡重置，此时，可以直接跳转到level-3的处理流程进行处理，可以更新level-3的状态为active_not_running，并将level-3的计数器加1，以及更新level-2的状态为deactive。

317.Recovery模块将各个level的计数器的取值保存NV，以及将各个level的恢复信息保存NV。

由于各个level的计数器的取值以及各个level的状态等信息一般保存在通信模块的易失性存储器中，而通信模块重启会导致通信模块的易失性存储器中的数据丢失，因此，为了避免数据丢失以及通信模块重启后恢复数据，可以将各个level的计数器的取值保存NV，以及将各个level的恢复信息保存NV。应理解，保存NV也即是将各个level的计数器的取值和各个level的恢复信息保存到通信模块的非易失性存储器中。各个level的恢复信息包括各个level的状态。

318.Recovery模块判断level-3的状态是否为active。

当Recovery模块确定level-3的状态不为deactive之后，Recovery模块可以进一步判断level-3的状态是否为active，如果为active，则表明level-3处于激活的状态，可以不用进行处理，如果不为active，也即是为active_not_running，则表明level-3处于已激活但未执行的状态，这种情况下，可以执行步骤319。

319.Recovery模块更新level-3的状态为active，并将level-3的计数器加1。

当Recovery模块确定level-3的状态为active_not_running之后，Recovery模块可以更新level-3的状态为active，并可以将level-3的计数器加1。

320.Recovery模块更新level-3的状态为active_not_running，并且将各个异常的计数器保存NV，以及将各个level的恢复信息保存NV。

Recovery模块更新level-3的状态为active，并将level-3的计数器加1之后，可以更新level-3的状态为active_not_running，并将各个level的计数器的取值保存NV，以及将各个level的恢复信息保存NV。

需要说明的是，由于一般通信模块重启相较于SIM卡重置和重新拨号需要的时间较长，因此，在一些实施例，为了降低影响，可以根据level-3的计数器的取值确定第二时长，然后启动第二时长的计时器。当第二时长的计时器超时之后，再向主控发送通信模块重启请求。在一种可能的实现方式中，可以预先配置有level-3的异常恢复间隔表，该表中可以存储有不同的计数器取值对应的时长，Recovery模块可以直接基于level-3的计数器的取值从level-3的异常恢复间隔表中确定对应的第二时长。

321.Recovery模块向主控发送通信模块重启请求。

Recovery模块将各个level的计数器的取值保存NV，以及将各个level的恢复信息保存NV之后，可以向主控发送通信模块重启请求。相应地，主控可以接收到来自Recovery模块的通信模块重启请求，并可以基于SIM卡重置请求通知对应的目标模块进行通信模块重启。

请先参阅图5，图5是level-3对应的流程示意图，如图5所示，该处理流程可以包括但不限于如下步骤：

301.Recovery模块接收到一条异常消息。

302.Recovery基于目标异常的触发次数、目标异常的特性和当前的执行等级确定目标执行等级CurrentExectionLevel。

322.在目标执行等级为level-3的情况下，Recovery模块可以先判断level-3的状态是否为deactive，在为deactive的情况下，可以执行步骤323，在不为deactive的情况下，可以执行步骤326。

当Recovery模块确定的目标执行等级为level-3时，Recovery模块可以先判断level-3的状态是否为deactive，如果level-3的状态为deactive，则表明level-3还处于未激活的状态，可以执行步骤323，如果level-3的状态不为deactive，也即是为active或active_not_running，则表明level-3处于已激活或者已激活但未执行的状态，这种情况下，可以执行步骤326。

323.Recovery模块更新level-3的状态为active_not_running，并将level-3的计数器加1。

Recovery模块判断出level-3的状态为deactive之后，表明是首次进入level-3的执行流程，可以更新level-3的状态为active_not_running，并将level-3的计数器加1。

324.Recovery模块将各个level的计数器的取值保存NV，以及将各个level的恢复信息保存NV。

325.Recovery模块向主控发送通信模块重启请求。

Recovery模块将各个level的计数器的取值保存NV，以及将各个level的恢复信息保存NV之后，可以向主控发送通信模块重启请求。相应地，主控可以接收到来自Recovery模块的通信模块重启请求，并可以基于SIM卡重置请求通知对应的目标模块进行通信模块重启。

326.Recovery模块判断level-3的状态是否为active。

当Recovery模块确定level-3的状态不为deactive之后，Recovery模块可以进一步判断level-3的状态是否为active，如果为active，则表明level-3处于激活的状态，可以不用进行处理，如果不为active，也即是为active_not_running，则表明level-3处于已激活但未执行的状态，这种情况下，可以执行步骤327。

327.Recovery模块更新level-3的状态为active，并将level-3的计数器加1。

328.Recovery模块更新level-3的状态为active_not_running，并且将各个异常的计数器保存NV，以及将各个level的恢复信息保存NV。

329.Recovery模块向主控发送通信模块重启请求。

上述流程中，当通信模块中的某一个或多个功能模块出现异常时，可以通过各个功能模块的异常自恢复和整个模块系统的异常自恢复两种方式解决异常，使通信模块恢复正常状态，可以提高用户体验。

需要说明的是，上述不同实施例中的相关信息(即相同信息或相似信息)和相关描述可以相互参考。

还需要说明的是，上述以电子设备或通信模块或通信模块中的功能模块作为执行主体来示意上述处理流程，但本申请并不限制该执行主体。例如，图2中Recovery模块执行的相关步骤实际上可以通过通信模块或通信模块中的处理器执行。

请参见图6，图6是本申请实施例提供的一种异常恢复装置的结构示意图，该异常恢复装置600可以为电子设备中的通信模块，异常恢复装置600可以包括第一执行模块601、更新模块602、确定模块603、第二执行模块604、清除模块605，其中，各个模块的详细描述如下：

第一执行模块601，用于在通信模块中的第一业务模块出现目标异常的情况下，执行该第一业务模块的异常自恢复流程；

更新模块602，用于当该第一业务模块的异常自恢复流程无法恢复正常时，基于该目标异常更新异常统计表；

确定模块603，用于基于该异常统计表确定相对应的异常恢复方式；

第二执行模块604，用于执行该异常恢复方式。

在一种可能的实现方式中，该异常统计表包括业务模块出现异常的统计信息。

在一种可能的实现方式中，该异常恢复方式为拨号重置、SIM卡重置、通信模块重启中的一种。

在一种可能的实现方式中，该第一业务模块的处理过程包括多个阶段，该多个阶段中的每个阶段均有对应的异常自恢复流程，该第一执行模块601执行该第一业务模块的异常自恢复流程具体包括：

确定该第一业务模块出现异常的目标阶段；

执行该目标阶段对应的异常自恢复流程。

在一种可能的实现方式中，该异常统计表包括异常的触发次数，该更新模块602基于该目标异常更新异常统计表具体包括：

将该异常统计表中该目标异常的触发次数加1；

该确定模块603基于该异常统计表确定相对应的异常恢复方式包括：

基于该更新后的所述目标异常的触发次数确定相对应的异常恢复方式。

在一种可能的实现方式中，该确定模块603基于该更新后的该目标异常的触发次数确定相对应的异常恢复方式包括：

在该更新后的该目标异常的触发次数小于第一阈值的情况下，确定该异常恢复方式为拨号重置；

在该更新后的该目标异常的触发次数大于或等于第一阈值，且小于第二阈值的情况下，确定该异常恢复方式为SIM卡重置；

在该更新后的该目标异常的触发次数大于或等于第二阈值的情况下，确定该异常恢复方式为通信模块重启。

在一种可能的实现方式中，该确定模块603，还用于确定该目标异常的优先级；

该确定模块603基于更新后的该目标异常的触发次数确定相对应的异常恢复方式包括：

基于该目标异常的优先级和该更新后的该目标异常的触发次数确定异常恢复方式。

在一种可能的实现方式中，该确定模块603基于更新后的该目标异常的触发次数确定相对应的异常恢复方式包括：

基于该目标异常的特性和该异常统计表中该更新后的该目标异常的触发次数确定第一执行等级；

将该第一执行等级和当前的执行等级中等级较高的确定为目标执行等级；

基于该目标执行等级确定异常恢复方式。

在一种可能的实现方式中，该异常恢复装置还可以包括：

清除模块605，用于在该目标异常恢复的情况下，清除该异常统计表中的信息。

在一种可能的实现方式中，该第一执行模块601具体用于：

执行该第一业务模块的异常自恢复流程；

当通过该第一业务模块的异常自恢复流程无法恢复正常时，向该更新模块602发送异常信息；

该更新模块602具体用于：基于该异常信息更新异常统计表；

该确定模块603具体用于：基于该异常统计表确定相对应的异常恢复方式；向该第二执行模块604发送该异常恢复方式；

该第二执行模块604具体用于：通知相应的模块执行该异常恢复方式。

请参阅图7，图7是本申请实施例公开的一种电子设备的结构示意图。其中，该电子设备700可以包括：处理器701、通信接口702和存储器703。处理器701、通信接口702以及存储器703可以相互连接或者通过总线704相互连接。

示例性的，存储器703用于存储电子设备700的计算机程序和数据，存储器703可以包括但不限于是随机存储记忆体(random access memory，RAM)、只读存储器(read-onlymemory，ROM)、可擦除可编程只读存储器(erasable programmable read only memory，EPROM)或便携式只读存储器(compact disc read-only memory，CD-ROM)、磁盘存储介质或者其它磁存储设备等。通信接口702用于支持电子设备700进行通信，例如接收或发送数据。

示例性的，处理器701可以是中央处理器(central processing unit，CPU)、复杂可编程逻辑器件、通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。处理器701也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，数字信号处理器和微处理器的组合等等。示例性的，存储器703可以是独立存在的，通过总线与处理器701相连接。存储器703和处理器701也可以集成在一起。

在一个实施例中，电子设备700可以为上述电子设备或上述电子设备中的通信模块，处理器701可以用于读取上述存储器703中存储的程序，执行上述图2、图3、图4或图5所示的方法实施例中电子设备或电子设备中的组件(如主控)执行的操作，可以参考上述相关描述，在此不再详细赘述。

需要说明的是，图7所示的电子设备700仅仅是本申请实施例的一种实现方式，实际应用中，电子设备700还可以包括更多或更少的部件，这里不作限制。

本申请实施例还公开一种计算机可读存储介质，其上存储有指令，该指令被执行时执行上述方法实施例中的方法。

本申请实施例还公开一种包括指令的计算机程序产品，该指令被执行时执行上述方法实施例中的方法。

本申请实施例提供了一种芯片系统，该芯片系统包括处理器，用于支持通信设备实现上述实施例及其各种可能方式中的方法所涉及的功能。

在一种可能的设计中，所述芯片系统还包括存储器，所述存储器用于保存通信设备必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其它分立器件。

应理解，本申请中的“通信”，可以理解为直接通信；也可以理解为间接通信，也即通过其它器件、模块、装置等进行通信。

显然，上述所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或者特性可以包含在本实施例申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是相同的实施例，也不是与其它实施例互斥的独立的或是备选的实施例。本领域技术人员可以显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。本申请的说明书和权利要求书及所述附图中术语“第一”、“第二”等是区别于不同的对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。例如，包含了一系列步骤或单元，或者可选地，还包括没有列出的步骤或单元，或者可选地还包括这些过程、方法、产品或设备固有的其它步骤或单元。

可以理解的是，附图中仅示出了与本申请相关的部分而非全部内容。应当理解的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作(或步骤)描述成顺序的处理，但是其中的许多操作可以并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

在本说明书中使用的术语“部件”、“模块”、“系统”、“单元”等用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件或执行中的软件。例如，单元可以是但不限于在处理器上运行的进程、处理器、对象、可执行文件、执行线程、程序和/或分布在两个或多个计算机之间。此外，这些单元可从在上面存储有各种数据结构的各种计算机可读介质执行。单元可例如根据具有一个或多个数据分组(例如来自与本地系统、分布式系统和/或网络间的另一单元交互的第二单元数据。例如，通过信号与其它系统交互的互联网)的信号通过本地和/或远程进程来通信。以上所述的具体实施方式，对本申请的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本申请的具体实施方式而已，并不用于限定本申请的保护范围，凡在本申请的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本申请的保护范围之内。

Claims (10)

1.一种异常恢复方法，其特征在于，所述方法包括：

在通信模块中的第一业务模块出现目标异常的情况下，执行所述第一业务模块的异常自恢复流程；

当通过所述第一业务模块的异常自恢复流程无法恢复正常时，基于所述目标异常更新异常统计表；

基于所述异常统计表确定相对应的异常恢复方式，并执行所述异常恢复方式。

2.根据权利要求1所述的方法，其特征在于，所述第一业务模块的处理过程包括多个阶段，所述多个阶段中的每个阶段均有对应的异常自恢复流程，所述执行所述第一业务模块的异常自恢复流程包括：

确定所述第一业务模块出现异常的目标阶段；

执行所述目标阶段对应的所述异常自恢复流程。

3.根据权利要求1或2所述的方法，其特征在于，所述异常统计表包括异常的触发次数，所述基于所述目标异常更新异常统计表包括：

将所述异常统计表中所述目标异常的触发次数加1；

所述基于所述异常统计表确定相对应的异常恢复方式包括：

基于更新后的所述目标异常的触发次数确定相对应的异常恢复方式。

4.根据权利要求3所述的方法，其特征在于，所述基于更新后的所述目标异常的触发次数确定相对应的异常恢复方式包括：

在所述更新后的所述目标异常的触发次数小于第一阈值的情况下，确定所述异常恢复方式为拨号重置；

在所述更新后的所述目标异常的触发次数大于或等于第一阈值，且小于第二阈值的情况下，确定所述异常恢复方式为SIM卡重置；

在所述更新后的所述目标异常的触发次数大于或等于第二阈值的情况下，确定所述异常恢复方式为通信模块重启。

5.根据权利要求3所述的方法，其特征在于，所述方法还包括：

确定所述目标异常的优先级；

所述基于更新后的所述目标异常的触发次数确定相对应的异常恢复方式包括：

基于所述目标异常的优先级和所述更新后的所述目标异常的触发次数确定异常恢复方式。

6.根据权利要求3所述的方法，其特征在于，所述基于更新后的所述目标异常的触发次数确定相对应的异常恢复方式包括：

基于所述目标异常的特性和所述更新后的所述目标异常的触发次数确定第一执行等级；

将所述第一执行等级和当前的执行等级中等级较高的确定为目标执行等级；

基于所述目标执行等级确定异常恢复方式。

7.根据权利要求1所述的方法，其特征在于，所述通信模块包括第一业务模块、异常恢复模块和主控，所述方法还包括：

当通过所述第一业务模块的异常自恢复流程无法恢复正常时，所述第一业务模块向所述异常恢复模块发送异常信息；

所述异常恢复模块基于所述异常信息更新异常统计表；

所述异常恢复模块基于更新后的所述异常统计表确定相对应的异常恢复方式；

所述异常恢复模块向所述主控发送所述异常恢复方式；

所述主控通知相应的模块执行所述异常恢复方式。

8.一种异常恢复装置，其特征在于，包括：

第一执行模块，用于在通信模块中的第一业务模块出现目标异常的情况下，执行所述第一业务模块的异常自恢复流程；

更新模块，用于当所述第一业务模块的异常自恢复流程无法恢复正常时，基于所述目标异常更新异常统计表；

确定模块，用于基于所述异常统计表确定相对应的异常恢复方式；

第二执行模块，用于执行所述异常恢复方式。

9.一种电子设备，其特征在于，所述电子设备包括处理器和存储器，所述处理器调用所述存储器中存储的计算机程序或计算机指令实现如权利要求1-7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序或计算机指令，当所述计算机程序或计算机指令被运行时，实现如权利要求1-7任一项所述的方法。