一种基于异构通信模型及面向终端软件平台的APP管理方法

摘要

本发明提供一种基于异构通信模型及面向终端软件平台的APP管理方法，使得接入所述终端软件平台的各节点之间的通信均遵循基于异构通信模型的消息总线机制。所述APP管理方法包括步骤：响应于APP安装请求，对下载到智能终端的APP安装包进行认证，若验证通过，启动执行APP安装包；响应于APP注册信息，获取注册APP的待交互APP的消息接口信息，并根据所述待交互APP的消息接口信息定义注册APP的消息接口；启动APP保护机制。根据本发明，能够解决现有面向多种业务APP的统一终端软件平台的扩展灵活性差和系统可靠性差的问题。

说明书

技术领域

本发明属于APP管理方法，更具体地，涉及一种基于异构通信模型及面向终端软件平台的APP管理方法。

背景技术

近年来，在打造状态全面感知、信息高效处理及应用便捷灵活的泛在电力物联网的形式下，台区能源控制器终端技术得到了长足的发展与进步。能源控制器充分应用移动互联、边缘计算、数据处理等现代信息技术，能够实现低压电网台区信息智能感知和管理，满足日益增长的低压配电网台区的智能化和精益化管理需求。

能源控制器采用模组化设计，是智能电网的末端数据采集节点，是新一代用电台区智能感知和采集系统的核心，它可实现电能表数据的高频、全量采集，不仅全面支撑智能电表数据深化应用，而且将现有终端型式缩减为两种，大大提高了现场应用的适应性，其“产品模组化，模组产品化”的设计理念，也将有力提升运维效率。

能源控制器作为低压台区智能感知方案架构的中心节点，承担着本地核心的作用。能源控制器设计采用边缘计算和云计算的协同理念，基于“边”、“云”协同控制，实现本地数据分析、处理、决策，提高本地处理速度，保障业务实时效率，减少终端与云端之间的数据通信压力，提高系统响应性。

能源控制器业务功能实现为多个APP，业务APP运行在统一终端软件平台上。应用功能APP化的方案可以实现功能灵活扩展和配置，实现智能终端在低压台区的多重角色。例如：居民集抄APP实现集中器的功能，配变APP实现台区配电监测功能，专变APP实现大客户用电管理。未来还可以根据新的业务需求，设计新的APP运行于智能终端实现相应功能。

然而，现有面向多种业务APP的统一终端软件平台却存在以下问题：

一、采用基于单一通信协议的消息总线框架，而各种业务APP所支持的通信协议往往多种多样，这种消息总线机制无法满足不同类型业务APP的灵活扩展需求，使得平台系统的灵活性差。

二、现有面向多种业务APP的统一终端软件平台并未对业务APP的接入和运行进行管理，使得平台系统的可靠性差。

发明内容

本发明的目的在于解决现有面向多种业务APP的统一终端软件平台的扩展灵活性差和系统可靠性差的问题。

为了实现上述目的，本发明提供一种基于异构通信模型及面向终端软件平台的APP管理方法，该方法应用于系统管理器，使接入所述终端软件平台的各节点之间的通信均遵循基于异构通信模型的消息总线机制；

所述APP管理方法包括以下步骤：

响应于APP安装请求，对下载到智能终端的APP安装包进行认证，若验证通过，启动执行APP安装包；

响应于APP注册信息，获取安装到智能终端的APP的消息接口信息；

响应于APP交互匹配信息，获取能够与注册APP进行交互的待交互APP的消息接口信息，进行匹配，将匹配结果存储至交互信息列表；

启动APP保护机制。

作为优选的是，所述基于异构通信模型的消息总线机制所支持的通信协议包括IPC、TCP、UDP和MQTT。

作为优选的是，所述对下载到智能终端的APP安装包进行认证基于对APP安装包的标识码进行校验来实现。

作为优选的是，所述标识码包括注册识别码和MAC地址，所述标识码由APP所属的软件管理中心通过ESAM加密机添加于APP安装包。

作为优选的是，

在所述启动执行APP安装包之后，所述基于异构通信模型及面向终端软件平台的APP管理方法还包括：

检测APP是否发出注册信息，当APP未在预定的时限内发出注册信息时，终止APP。

作为优选的是，所述检测APP是否发出注册信息基于监听方式实现。

作为优选的是，所述获取能够与注册APP进行交互的待交互APP的消息接口信息，具体为：

通过注册APP的关键字，查询所述待交互APP的通信配置信息，所述通信配置信息包括IP地址、端口号、支持的消息类型和格式；

其中；所述的关键字包括组件名称和进程号。

作为优选的是，注册APP和所述待交互APP均通过基于异构通信模型的消息总线与系统管理器通信连接。

作为优选的是，所述APP保护机制具体为：

按照预定的广播频率向所有注册的APP发送保活确认消息，APP收到该保活确认消息后给予确认，当在连续的预定数量的周期内均未收到APP的确认时，判定该APP为异常状态。

作为优选的是，在所述判定该APP为异常状态之后，所述基于异构通信模型及面向终端软件平台的APP管理方法还包括：

执行APP异常恢复策略。

本发明的有益效果在于：

本发明的基于异构通信模型及面向终端软件平台的APP管理方法，使得接入所述终端软件平台的各节点之间的通信均遵循基于异构通信模型的消息总线机制，APP之间的交互全部通过消息总线进行数据通信。APP可以根据可靠性和性能要求等设计需求对通信模式进行灵活选择或配置。所述APP管理方法基于系统管理器实现，负责所有用户App以及其他系统级App的接入以及管理，根据交互信息列表直接进行APP之间的信息交互，无需在每次通信之前进行查询匹配，有效提升终端APP之间的数据通信效率。该机制可以满足不同类型APP的灵活扩展需求，保证系统可靠性的同时也保证了系统的灵活性。

本发明的其它特征和优点将在随后具体实施方式部分予以详细说明。

附图说明

通过结合附图对本发明示例性实施方式进行更详细的描述，本发明的上述以及其它目的、特征和优势将变得更加明显，其中，在本发明示例性实施方式中，相同的参考标号通常代表相同部件。

图1示出了根据本发明的实施例的基于异构通信模型及面向终端软件平台的APP管理方法的实现流程图。

图2示出了根据本发明的实施例的基于异构通信模型的消息总线示意图。

图3示出了根据本发明的实施例的APP间的数据交互过程示意图。

图4示出了根据本发明的实施例的APP注册请求流程图。

图5示出了根据本发明的实施例的APP注册查询流程图。

图6示出了根据本发明的实施例的APP心跳检测流程图。

图7示出了根据本发明的实施例的APP接入和运行流程图。

具体实施方式

下面将更详细地描述本发明的优选实施方式。虽然以下描述了本发明的优选实施方式，然而应该理解，可以以各种形式实现本发明而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本发明更加透彻和完整，并且能够将本发明的范围完整地传达给本领域的技术人员。

实施例：图1示出了本实施例的基于异构通信模型及面向终端软件平台的APP管理方法的实现流程图。参照图1，本实施例的基于异构通信模型及面向终端软件平台的APP管理方法，应用于系统管理器，使接入所述终端软件平台的各节点之间的通信均遵循基于异构通信模型的消息总线机制；

所述APP管理方法包括以下步骤：

响应于APP安装请求，对下载到智能终端的APP安装包进行认证，若验证通过，启动执行APP安装包；

响应于APP注册信息，获取安装到智能终端的APP的消息接口信息；

响应于APP交互匹配信息，获取能够与注册APP进行交互的待交互APP的消息接口信息，进行匹配，将匹配结果存储至交互信息列表；

启动APP保护机制。

本实施例中，所述基于异构通信模型的消息总线机制所支持的通信协议包括IPC、TCP、UDP和MQTT。

本实施例中，所述对下载到智能终端的APP安装包进行认证基于对APP安装包的标识码进行校验来实现。

本实施例中，所述标识码包括注册识别码和MAC地址，所述标识码由APP所属的软件管理中心通过ESAM加密机添加于APP安装包。

本实施例中，在所述启动执行APP安装包之后，还包括：

检测APP是否发出注册信息，当APP未在预定的时限内发出注册信息时，终止APP。

本实施例中，所述检测APP是否发出注册信息基于监听方式实现。

本实施例中，所述获取能够与注册APP进行交互的待交互APP的消息接口信息，具体为：

通过注册APP的关键字，查询所述待交互APP的通信配置信息，所述通信配置信息包括IP地址、端口号、支持的消息类型和格式；

其中；所述的关键字包括组件名称和进程号。

本实施例中，业务APP需符合消息驱动规范和接口定义方可接入终端软件平台。

本实施例中，注册APP和所述待交互APP均通过基于异构通信模型的消息总线与系统管理器通信连接。

本实施例中，所述APP保护机制具体为：

按照预定的广播频率向所有注册的APP发送保活确认消息，APP收到该保活确认消息后给予确认，当在连续的预定数量的周期内均未收到APP的确认时，判定该APP为异常状态。

本实施例中，在所述判定该APP为异常状态之后，还包括：

执行APP异常恢复策略。

图2示出了本实施例的基于异构通信模型的消息总线示意图。参照图2，本实施例使用基于异构通信模型的消息总线框架，APP之间的交互全部通过消息总线进行数据通信。消息驱动支持IPC、TCP、UDP和MQTT等多种模式。APP可以根据可靠性和性能要求等设计需求进行灵活选择或配置。由服务提供方(服务器/生产者)定义消息接口，服务使用方(客户机/消费者)根据定义的消息接口访问相应的服务。一个APP既可以是服务提供方，同时也可以是某些服务的使用方，同时具有服务器与客户机多重角色。

图3示出了本实施例的APP间的数据交互过程示意图。参照图3，APP之间的数据交换借助于消息实现。消息的传输可支持IPC、TCP、UDP或MQTT等方式。由服务提供方(服务器角色)定义消息接口，服务使用方(客户机角色)根据定义的消息接口访问相应的服务。一个APP既可以是服务提供方，同时也可以是某些服务的使用方，同时具有服务器与客户机多重角色。

APP间数据交互类型分为APP注册请求、APP保活、事件通知和消息分发/响应。

本实施例的基于异构通信模型及面向终端软件平台的APP管理方法采用APP认证机制：

每个APP(package)在提交软件中心时，由软件管理中心通过ESAM加密机自动在APP末尾增加RN以及MAC，APP在下载到终端后，由系统管理器通过本体ESAM芯片对MAC进行校验，校验通过方可执行。

图4示出了本实施例的APP注册请求流程图。参照图4，APP下载到终端后，经终端校验通过，加入到启动列表，由系统管理器负责启动执行，如果APP在启动后N分钟内仍未发送注册消息到系统管理器完成注册，将会被系统管理器kill。注册请求由APP发起，系统管理器给与确认。

系统管理器提供了注册机制，APP运行时需要先注册到系统管理器，通过系统管理器的认证后才可以运行。

图5示出了本实施例的APP注册查询流程图。参照图5，APP可以向系统管理器查询已注册APP信息，支持通过关键词查询，获取待交互APP信息(如IP地址及端口号等)，无论APP如何部署，均可达成互相通信目的。

图6示出了本实施例的APP心跳检测流程图。参照图6，系统管理器按设定间隔自动向所有注册的APP发送Keepalive消息，APP收到该消息后给予确认，如果连续多个周期(间隔)未收到APP的确认，系统管理器认为该APP为异常状态，将执行后续异常恢复策略。

图7示出了本实施例的APP接入和运行流程图。基于统一终端软件平台的APP系统管理器，负责所有用户APP以及其他系统级APP的接入以及管理。APP下载到终端后，经终端校验通过，加入到启动列表，由系统管理器负责启动执行，如果APP在启动后一段时间内仍未发送注册消息到系统管理器完成注册，将会被系统管理器kill。注册请求由APP发起，系统管理器给予确认。

本实施例中，系统管理器具有软、硬件看门狗双重保护，异常可自动恢复。其他APP的生命周期，由消息中心的保活机制负责监控并管理。系统管理器按设定间隔自动向所有注册的APP发送Keepalive消息，APP收到该消息后给予确认，如果连续多个周期(间隔)未收到APP的确认，系统管理器认为该APP为异常状态，将执行后续异常恢复策略。

本实施例提出的多APP的系统架构可以实现终端功能的灵活扩展和配置，但是带来的问题有多种，其中最重要的就是系统可靠性的风险。由于不同APP的设计和实现来源可能是多样的，包括不同的团队和厂家，APP的不规范设计或实现会给系统带来风险，甚至影响系统基本功能的实现。注册和保活机制可以避免接入系统的APP影响系统的可靠性，也可以保证新接入APP自身的稳定运行和恢复。

本实施例使用基于异构通信模型的消息总线框架，APP之间的交互全部通过消息总线进行数据通信；APP可以根据可靠性和性能要求等设计需求对通信模式进行灵活选择或配置。系统设计了系统管理器，负责所有用户APP以及其他系统级APP的接入以及管理。该机制可以满足不同类型APP的灵活扩展需求，保证系统可靠性的同时也保证了系统的灵活性。

本实施例基于统一系统平台的多APP系统架构可以实现智能终端功能的灵活扩展和配置。在原有硬件和软件平台基础上，为了实现一个新的业务需求，可以增加一个新的APP即可满足。基于注册和保活机制的终端APP管理方法，在该框架范围内保证了对APP的灵活、有效管理。注册机制可以随时接入合规的APP进入系统，兼顾了系统的灵活性和可靠性。

本实施例提出的异构通信模型可以灵活适应终端APP的各种需求和应用场景，对于实时性要求高的APP可以采用基于IPC的模式。而对于需要按照接口规范灵活接入和快速扩展的功能模块，可以实现为基于MQTT等模式的消息总线机制。该机制可以根据需求灵活裁剪，解决了传统用电管理终端软件框架可扩展性差、业务接入灵活性不好、不同APP不能互联互通的问题。

本实施例的基于异构通信模型及面向终端软件平台的APP管理方法，为实现多APP的管理，设计了系统管理器。系统管理器负责所有用户APP以及其他系统级APP的接入以及管理。系统管理器具有软、硬件看门狗双重保护，异常可自动恢复。其他APP的生命周期，由系统管理器的保活机制负责监控并管理。

本实施例中，系统管理器提供了注册机制，APP运行时需要先注册到系统管理器，通过系统管理器的认证后才可以运行。该机制可以满足不同类型APP的灵活扩展需求，保证了系统的灵活性。

本实施例的基于异构通信模型及面向终端软件平台的APP管理方法可以保证系统中的APP符合设计规范并在系统中可靠运行，同时对发生故障的APP进行有效生命周期管理，有效避免不符合设计规范的业务APP对系统可能存在的影响。

以上已经描述了本发明的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。