CN112230968A - 固件更新方法、装置、服务器和计算机可读存储介质 - Google Patents

Abstract

本申请提供一种固件更新方法、装置、服务器和计算机可读存储介质，通过预先定义包含多个属性项的标题，服务器在获得固件数据包的属性信息后，生成固件更新通知并加载至标题以进行消息发布，其中，标题为从属于消息队列的任一标题。从而在接收到终端设备在监测到自身所订阅的标题有消息发布时发送的基于protobuf格式生成的更新请求时，服务器获得固件数据包，并将固件数据包发送给终端设备，以使终端设备根据接收到的固件数据包进行固件更新。本方案中，采用预先定义标题且利用protobuf消息格式以及消息队列的方式，可实现高效率、高扩展性的固件数据的管理。

Description

固件更新方法、装置、服务器和计算机可读存储介质

技术领域

本申请涉及物联网技术领域，具体而言，涉及一种固件更新方法、装置、服务器和计算机可读存储介质。

背景技术

随着传感器技术以及通讯技术的发展，物联网正在各个行业逐渐普及，例如电力物联网、智能家居、智能交通等。传感器是物联网的核心部件之一，构成了整个物联网的感知层。不同于互联网是人与人通过网络进行交流，物联网是实体与实体之间的数据交流，所以在大型物联网中，存在数量众多的，体积、功耗、功能各异的传感器，它们分布在我们生活的各个角落，例如城市智慧管囊、智能交通信号灯、智能手环等。由于位置的分散和数量的众多，大多数传感器在部署之后就很少会有人为现场操作的机会，一般都是通过数据中心远程操作。

为了给客户提供增值服务，或者修改一些程序错误，物联网***往往需要给传感器终端更新固件。在大规模物联网中，绝大多数固件只能通过计算机进行远程更新。传感器固件的远程更新已经成为物联网设备目前面临的难题。目前的固件更新方式中，一般是通过例如TCP/UDP等协议进行通讯进而实现固件更新。但是，这种方式需要自定义传输字节的工作模式，不具备良好的可扩展性且可读性差。

发明内容

本申请的目的包括，例如，提供了一种固件更新方法、装置、服务器和计算机可读存储介质，其能够实现高效率、高扩展性的固件数据管理。

本申请的实施例可以这样实现：

第一方面，本申请提供一种固件更新方法，应用于与多个终端设备通信连接的服务器，所述方法包括：

在获得固件数据包的属性信息后，根据所述属性信息生成固件更新通知，将所述固件更新通知加载至预先定义的包含多个属性项的标题以进行消息发布，所述标题为从属于消息队列的任一标题；

接收终端设备在监测到自身所订阅的标题有消息发布时所发送的更新请求，其中，所述固件更新通知和更新请求基于protobuf格式所生成；

根据所述更新请求获得固件数据包，并将所述固件数据包发送给所述终端设备，以使所述终端设备根据接收到的固件数据包进行固件更新。

在可选的实施方式中，所述根据所述更新请求获得固件数据包，并将所述固件数据包发送给所述终端设备，以使所述终端设备根据接收到的固件数据包进行固件更新的步骤，包括：

获得所述更新请求中携带的固件名称，根据所述固件名称查找获得对应的固件数据包；

根据预先定义的结构体信息将所述固件数据包写入至固件主体结构中并发送至所述终端设备，以使所述终端设备根据存储的结构体信息对接收到的固件主体结构进行解析，并根据解析后得到的固件数据包进行固件更新。

在可选的实施方式中，所述根据预先定义的结构体信息将所述固件数据包写入至固件主体结构中并发送至所述终端设备的步骤，包括：

从预先创建的固件库中加载所述固件数据包；

根据预先定义的结构体信息获得其中的固件主体信息，基于所述固件主体信息和固件数据包得到固件主体结构；

对所述固件主体结构进行序列化处理，将所述固件数据包写入至序列化之后的固件主体结构中并发送至所述终端设备。

在可选的实施方式中，所述结构体信息包含多种类型的固件结构体信息，各所述固件结构体由protobuf格式所生成。

在可选的实施方式中，所述更新请求为经过protobuf序列化的更新请求；所述获得所述更新请求中携带的固件名称的步骤，包括：

对所述更新请求进行protobuf反序列化处理；

获得反序列化处理后的更新请求中携带的固件名称。

在可选的实施方式中，所述根据所述更新请求获得固件数据包，并将所述固件数据包发送给所述终端设备，以使所述终端设备根据接收到的固件数据包进行固件更新的步骤之后，所述方法还包括：

接收终端设备发送的更新反馈信息，所述更新反馈信息基于protobuf格式所生成；

获得所述更新反馈信息中所包含的所述终端设备经过更新后的固件版本号以及更新结果字段；

根据所述更新结果字段和所述更新后的固件版本号判断所述终端设备是否更新成功，并生成所述终端设备的固件更新记录。

在可选的实施方式中，预先定义的标题包括多个；

所述根据所述属性信息生成固件更新通知，将所述固件更新通知加载至预先定义的包含多个属性项的标题以进行消息发布的步骤，包括：

获得所述属性信息中包含的属性适用项；

根据各所述属性适用项所适用的属性项，对多个属性适用项进行组合；

利用组合后的属性适用项生成固件更新通知并进行序列化处理，将序列化处理后的固件更新通知加载至预先定义的包含多个属性项的标题以进行消息发布。

第二方面，本申请提供一种固件更新装置，应用于与多个终端设备通信连接的服务器，所述装置包括：

更新模块，用于在获得固件数据包的属性信息后，根据所述属性信息生成固件更新通知，将所述固件更新通知加载至预先定义的包含多个属性项的标题以进行消息发布，所述标题为从属于消息队列的任一标题；

接收模块，用于接收终端设备在监测到自身所订阅的标题有消息发布时所发送的更新请求，其中，所述固件更新通知和更新请求基于protobuf格式所生成；

发送模块，用于根据所述更新请求获得固件数据包，并将所述固件数据包发送给所述终端设备，以使所述终端设备根据接收到的固件数据包进行固件更新。

第三方面，本申请提供一种服务器，包括一个或多个存储介质和一个或多个与存储介质通信的处理器，一个或多个存储介质存储有处理器可执行的机器可执行指令，当服务器运行时，处理器执行所述机器可执行指令，以执行前述实施方式中任意一项所述的固件更新方法。

第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质存储有机器可执行指令，所述机器可执行指令被执行时实现前述实施方式中任意一项所述的固件更新方法。

本申请实施例的有益效果包括，例如：

本申请提供的固件更新方法、装置、服务器和计算机可读存储介质，通过预先定义包含多个属性项的标题，服务器在获得固件数据包的属性信息后，生成固件更新通知并加载至标题以进行消息发布，其中，标题为从属于消息队列的任一标题。从而在接收到终端设备在监测到自身所订阅的标题有消息发布时发送的更新请求时，服务器获得固件数据包，并将固件数据包发送给终端设备，以使终端设备根据接收到的固件数据包进行固件更新。本方案中，采用预先定义标题且利用protobuf消息格式以及消息队列的方式，可实现高效率、高扩展性的固件数据的管理。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的固件更新方法的应用场景示意图；

图2为本申请实施例提供的固件更新方法的流程图；

图3为本申请实施例提供的固件更新方法中，标题更新方法的流程图；

图4为本申请实施例提供的固件更新方法中，固件主体结构获得方法的流程图；

图5为本申请实施例提供的固件更新方法中，固件名称获得方法的流程图；

图6为本申请实施例提供的固件更新方法中，固件主体结构获得方法的另一流程图；

图7为本申请实施例提供的固件更新方法中，更新反馈方法的流程图；

图8为本申请实施例提供的服务器和终端设备之间的交互示意图；

图9为本申请实施例提供的固件更新装置的功能模块框图；

图10为本申请实施例提供的电子设备的结构框图。

图标：100-服务器；110-固件更新装置；111-更新模块；112-接收模块；113-发送模块；120-存储器；130-处理器；140-通信单元；200-网络；300-终端设备；400-数据库。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和展示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

在本申请的描述中，需要说明的是，若出现术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

需要说明的是，在不冲突的情况下，本申请的实施例中的特征可以相互结合。

请参阅图1，为本申请提供的固件更新方法的应用场景示意图，该场景中包括网络200、服务器100、终端设备300、数据库400中的一种或多种。其中，终端设备300可以包括多个，多个终端设备300分别与服务器100通信连接，以实现信息和数据的交互。终端设备300可以是各种类型的智能设备，例如智能交通信号灯、智能手环、智能家居等等。终端设备300可包含一个或多个传感器，可通过与服务器100进行信息和数据的交互，以实现其包含的传感器的固件升级。

而服务器100可以是用于对终端设备300以及其包含的传感器进行数据管理的后台服务器100，在一些实施例中，服务器100可以包括处理器，处理器可以对终端设备300发送的信息进行分析处理，以执行本申请中描述的一个或多个功能。其中，服务器100可以是由多个服务器100构成的服务器集群，也可以是单独的服务器100。

在一些实施例中，数据库400可以连接到网络200以与该应用场景中的一个或多个组件通信，例如上述的服务器100。服务器100可以经由网络200访问存储在数据库400中的数据或指令。在一些实施例中，数据库400也可以直接连接至服务器100，或者数据库400也可以是服务器100的一部分。

在本实施例中，服务器100与各个终端设备300之间的通信，其通信协议可采用消息队列协议，例如MQTT（Message Queuing Telemetry Transport,消息队列遥测传输协议）、ApachePulsar等。

此外，考虑到存在有些终端设备300不具备远距离的网络传输功能，因此，在上述场景中还可增设中继设备，服务器100及各个终端设备300可分别与中继设备通信，从而服务器100和各个终端设备300可通过中继设备实现数据、信息的通信交互。

下面结合上述图1所示的应用场景中描述的内容，对本申请实施例提供的固件更新方法进行详细说明。

图2示出了本申请实施例提供的固件更新方法的流程示意图，本申请所提供的固件更新方法可应用于上述实施例中的服务器100。应当理解，在其它实施例中，本实施例所述的固件更新方法其中部分步骤的顺序可以根据实际需要相互交换，或者其中的部分步骤也可以省略或删除。该固件更新方法的详细步骤介绍如下。

步骤S110，在获得固件数据包的属性信息后，根据所述属性信息生成固件更新通知，将所述固件更新通知加载至预先定义的包含多个属性项的标题以进行消息发布，所述标题为从属于消息队列的任一标题。

步骤S120，接收终端设备300在监测到自身所订阅的标题有消息发布时所发送的更新请求，其中，所述固件更新通知和更新请求基于protobuf(Google Protocol Buffers)格式所生成。

步骤S130，根据所述更新请求获得固件数据包，并将所述固件数据包发送给所述终端设备300，以使所述终端设备300根据接收到的固件数据包进行固件更新。

本实施例中，上述数据库400可包括信息数据库和固件数据库，其中，信息数据库中可保存终端设备300的台账信息、固件详细信息、固件升级日志、固件请求日志等。其中，台账信息可包括设备类型、设备型号、生产日期、设备唯一标识码以及当前终端固件版本等。固件详细信息可包括固件版本、固件上传日期、固件所属设备类型、固件文件名及校验码等。

固件数据库中可存储所有的或部分版本的固件数据包。服务器100可具有对信息数据库中的数据的增加、删除、修改及查找等功能，此外，服务器100还可具有对固件数据库中数据的读写功能。

本实施例中，可预先定义包含多个属性项的标题，定义的标题可从属于消息队列。例如，定义的标题的形式可以为/upgrade/{传感器属性1}/{传感器属性2}/…/{传感器属性N}/{传感器唯一识别码}/{force}。

其中，upgrade表示用于固件升级所用，可以用其他任意字符替代，force表示是否强制升级，可以为1或0（或者为true或false）表示。而其中传感器属性可代表任意传感器属性，例如包括生产批次、传感器型号、传感器类型等。在定义的标题中，传感器属性的顺序也具备实际意义，即在标题中传感器属性的顺序确定之后，不可随意进行更改。其中的大括号表示取传感器的实际属性值。

上述的标题格式是以采用MQTT协议为例进行说明，若实施时采用其它消息协议，可对格式进行相应修改即可，例如，若采用ApachePulsar的消息协议，该消息协议中不能存在“/”符号，则在上述基础上，将上述标题格式中的“/”符号修改为“-”符号即可。

本实施例中，各个终端设备300可订阅其中的一个或多个标题。在终端设备300订阅其中的多个标题时，可以采用对多个标题进行枚举的方式进行订阅，也可以采用正则表达式的方式进行订阅，具体地本实施例不作限制。

服务器100在获得固件数据包的属性信息后，可根据属性信息生成固件更新通知，以通过将固件更新通知加载至预先定义的标题而进行消息发布。其中，该固件数据包为更新所需的数据包。如此，订阅有该标题的终端设备300在监测到其订阅的标题有消息发布时，可向服务器100发送更新请求。其中，本实施例中，固件更新通知和更新请求均基于protobuf格式所生成。

服务器100在接收到终端设备300发送的更新请求后，基于更新请求可通过多种方式获得固件数据包，并将固件数据包发送给终端设备300，终端设备300将根据接收到的固件数据包进行固件更新。

本实施例中，采用定义包含多个属性项的标题，而定义的标题从属于消息队列，可在需要进行相关信息修改时，实现便捷修改，从而实现高效率、高扩展性的固件数据的管理。并且，服务器100和终端设备300之间的交互信息，基于protobuf格式生成，可降低数据体积。

请参阅图3，在本实施例中，在上述步骤S110中，服务器100根据获得的固件数据包的属性信息生成固件更新通知的步骤中，可通过以下方式实现：

步骤S111，获得所述属性信息中包含的属性适用项。

步骤S112，根据各所述属性适用项所适用的属性项，对多个属性适用项进行组合。

步骤S113，利用组合后的属性适用项生成固件更新通知并进行序列化处理，将序列化处理后的固件更新通知加载至预先定义的包含多个属性项的标题以进行消息发布。

本实施例中，获得的更新所需的固件数据包并非适用于所有的终端设备300所包含的传感器，各个固件数据包仅对其中的满足相应条件的传感器所适用。固件数据包的属性信息中可包含属性适用项，各个属性适用项表征该固件数据包所适用的传感器对应的条件。例如，属性适用项可以是如传感器类型A、生产批次B或生产批次C。也即表明该固件数据包可以适用于传感器类型为A、生产批次为B的传感器，或者是传感器类型为A、生产批次为C的传感器。

而在预先定义的各个标题中包含有多个属性项，终端设备300所订阅的标题所包含的属性项即对应终端设备300所包含的传感器的实际属性，例如终端设备300所订阅的标题中包含传感器类型A，即表明该终端设备300所包含的传感器其类型为A。

因此，在上述获得的固件数据包的属性信息中包含的属性适用项中存在可适用于相同属性项但不同属性值的属性适用项时，则可以对该多个属性适用项进行组合，利用组合后的属性适用项生成固件更新通知。

例如，预先定义的标题结构为/upgrade/传感器类型/传感器批次/传感器唯一识别码。获得的固件数据包的属性适用项包括传感器类型A、生产批次B、生成批次C，则可将生产批次B和生产批次C进行或逻辑组合，将传感器类型A与或逻辑组合的结果进行与逻辑组合，再结合其他的相关信息，从而对/upgrade/类型A/[批次B|批次C] /传感器唯一识别码的标题进行更新。

此外，若服务器100作为消息队列的发送者仅具有一次针对一个标题进行消息发布的功能，服务器100可以通过列举所有的需要消息发布的标题的方式进行消息发布。

服务器100在进行消息发布后，各个终端设备300在监测到自身所订阅的标题有消息发布时，即发起更新请求。

此外，在本实施例中，考虑到现有技术中还有采用json或XML等文本协议实现固件升级的方式，这类方式虽然解决了可扩展性的问题，但是却存在数据体积过大、解析时间过长、内存开销较大等问题。并且，这类方式还可能引起由于固件升级所带来的字段修改的兼容性问题。

基于上述考虑，本实施例中，采用了protobuf协议数据交换格式工具库以通过生成结构体的方式实现信息数据的管理。

本实施例中，预先基于protobuf定义结构体信息，结构体信息包含多种类型的固件结构体信息，各个固件结构体由protobuf工具所生成。例如，可以包括固件更新通知、更新请求、固件主体、固件更新结果等。其中，固件更新通知可包含新的固件版本信息，更新请求可包含所请求的固件名称，固件主体可包含固件名称、固件文件序列化信息、固件校验码等。而固件更新结果可包含终端设备300的唯一识别码和更新结果字段等。

上述所定义的结构体信息将保存至服务器100以及各个终端设备300，后续在进行相关信息数据的交互时，服务器100和各个终端设备300可具有统一的信息定义，从而实现信息的准确交互。并且，protobuf相比XML、json等具有更高的时间效率和空间效率，可降低数据体积，更适用于对数据大小和传输速率要求比较高的应用场景。

基于上述定义，本实施例中，在上述服务器100发布固件更新通知时，即可通过将固件更新通知进行protobuf序列化处理之后，得到序列化的固件更新通知并发布。

而各个终端设备300可对固件更新通知进行protobuf反序列化处理，获得反序列化处理后的信息中服务器100所发布的固件版本号。终端设备300可比较自身当前固件版本号和固件版本号。若终端设备300自身的固件版本号不低于发布的固件版本号，终端设备300可无需进行固件升级。若终端设备300自身的固件版本号低于发布的固件版本号，则终端设备300可发送更新请求以进行固件升级。

此外，由上述可知，在标题中包含是否需要强制升级的字段force，若终端设备300所订阅的标题中，force字段为1（或为true），则即使终端设备300自身的固件版本号不低于发布的固件版本号，也需要进行固件升级。而若force字段为0（或为false），则可以按上述的处理逻辑处理即可。

本实施例中，通过在标题中添加是否强制升级的字段force，可以用于纠正在一些场景下的升级出错的现象。例如，若终端设备300在前一次的固件升级过程中由于网络原因或设备原因等导致实际未成功完成升级，但是自身的固件版本号已更新为新的固件版本号。在这种情形下，若终端设备300以自身的固件版本号与服务器100所发布的固件版本号进行比较以判断是否进行升级，则终端设备300用于比较的自身的固件版本号并不准确（实际固件的版本号可能比用于比较的自身的固件版本号低），因此，造成终端设备300难以顺利完成升级的问题。

因此，在上述情形下，则可将标题中的force字段设置为1（或true），如此，可以使终端设备300进行强制升级，从而解决上述问题。

在上述基础上，终端设备300在判定需要进行固件升级时，可向服务器100发送更新请求，该更新请求可以是经过protobuf序列化的更新请求后，服务器100在接收到该更新请求后，可通过以下方式基于更新请求进行相关信息处理，请结合参阅图4：

步骤S131，获得所述更新请求中携带的固件名称，根据所述固件名称查找获得对应的固件数据包。

步骤S132，根据预先定义的结构体信息将所述固件数据包写入至固件主体结构中并发送至所述终端设备300，以使所述终端设备300根据存储的结构体信息对接收到的固件主体结构进行解析，并根据解析后得到的固件数据包进行固件更新。

本实施例中，服务器100在获得终端设备300发送的更新请求后，可通过以下方式获得所请求的固件名称，请参阅图5：

步骤S1311，对所述更新请求进行protobuf反序列化处理。

步骤S1312，获得反序列化处理后的更新请求中携带的固件名称。

本实施例中，Protobuf可采用二进制字节的序列化方式，可利用字段索引和字段类型通过相关算法计算得到字段之间的关系映射，protobuf是通过算法生成二进制流，序列化与反序列化不需要解析相应的节点属性和多余的描述信息，所以序列化和反序列化时间效率较高。

服务器100在接收到终端设备300的更新请求后，可相应地对更新请求进行protobuf反序列化处理，进而获得其中所请求的固件名称。基于获得的固件名称查找对应的固件数据包。在此基础上，请参阅图6，服务器100可通过以下方式对固件数据包进行处理并发送至终端设备300：

步骤S1321，从预先创建的固件库中加载所述固件数据包。

步骤S1322，根据预先定义的结构体信息获得其中的固件主体信息，基于所述固件主体信息和固件数据包得到固件主体结构。

步骤S1323，对所述固件主体结构进行序列化处理，将所述固件数据包写入至序列化之后的固件主体结构中并发送至所述终端设备300。

本实施例中，服务器100和终端设备300之间的信息传输通过预先基于protobuf定义的结构体信息进行传输，因此，可根据预先定义的结构体信息中的固件主体信息，基于固件主体信息将固件数据包写入至固件主体结构中。其中，得到的固件主体结构至少可包含固件名称、固件数据包序列化结果、固件校验码等。

然后将得到的固件主体结构进行序列化处理并发送至终端设备300。终端设备300在接收到服务器100发送的固件主体结构后，对接收到的固件主体结构进行protobuf反序列化处理。此外，终端设备300还可基于其中包含的固件校验码对接收到的固件数据包进行完整性校验。在校验通过后，终端设备300可基于接收到的信息进行固件更新。

终端设备300在固件更新后，可向服务器100反馈相应的更新结果，请参阅图7，服务器100在接收到更新结果后可通过以下方式判断终端设备300是否更新成功：

步骤S210，接收终端设备300发送的更新反馈信息。

步骤S220，获得所述更新反馈信息中所包含的所述终端设备300的更新后的固件版本号以及更新结果字段。

步骤S230，根据所述更新结果字段和所述更新后的固件版本号判断所述终端设备300是否更新成功，并生成所述终端设备300的固件更新记录。

在本实施例中，预先可基于protobuf进行更新反馈信息的形式的定义，定义的更新反馈信息中可包含终端设备300唯一识别码、更新结果字段和终端设备300更新后的固件版本号。因此，终端设备300所发送的更新反馈信息即为按照上述的定义格式所定义的，服务器100在获得该更新反馈信息后，即可基于其中包含的终端设备300的更新后的固件版本号和更新结果字段以判断终端设备300是否更新成功。

可选地，若终端设备300的更新后的固件版本号与服务器100所发布的固件版本号一致，且更新结果字段表征更新成功，则可确定终端设备300的固件更新成功。

为了对本申请实施例所提供的固件更新方法的具体过程进行说明，以下将结合图8所示，对本实施例中的固件更新方法的交互流程进行说明：

步骤S301，服务器100基于protobuf定义结构体信息。

其中，定义的结构体信息包括固件更新通知、固件请求、固件主体结构及更新反馈结果等等。

步骤S302，各个终端设备300基于protobuf定义结构体信息。

服务器100和各个终端设备300预先定义统一的结构体信息并分别保存至服务器100和终端设备300中。

步骤S303，服务器100获得固件数据包的属性信息，对从属于消息队列标题进行消息发布。

其中，各个标题包含多个属性项。

步骤S304，终端设备300监测到订阅的标题有消息发布时，判断是否需要升级。

其中，各个终端设备300可预先订阅与自身相关的标题，在订阅的标题有所消息发布时，通过比较发布的固件版本号和自身的固件版本号判断是否需要进行升级，此外，还需结合标题中的强制更新字段以判断是否需要进行升级。

步骤S305，终端设备300在判定需要升级后，发送更新请求至服务器100。

步骤S306，服务器100解析更新请求，获得对应的固件数据包。

其中，终端设备300发送至服务器100的更新请求为经过protobuf序列化处理后的更新请求，服务器100可对该更新请求进行protobuf反序列化处理，获得其中的固件名称，基于固件名称获得对应的固件数据包。

步骤S307，服务器100基于固件数据包生成固件结构体。

其中，服务器100根据预先定义的结构体信息中的固件主体结构信息，基于固件数据包生成固件结构体。

步骤S308，服务器100发送固件结构体至终端设备300。

步骤S309，终端设备300对接收到的固件结构体进行完整性校验，在校验通过后进行升级。

步骤S3110，终端设备300反馈更新反馈信息至服务器100。

步骤S311，服务器100基于更新反馈信息判断是否升级成功。

其中，服务器100可基于更新反馈信息中的终端设备300的更新后的固件版本号和其中的更新结果字段判断终端设备300是否升级成功。

本实施例所提供的固件更新方案，通过服务器100以protobuf的文件协议以及消息队列通讯协议来实现终端设备300的固件更新，且服务器100和终端设备300之间的所有通信过程均基于protobuf协议以实现，能够进行统一高效的更新与维护，提高了终端设备300固件更新的完整性，具有高效率、高扩展等优点。并且可以快捷地实现终端设备300中传感器的分批固件更新功能，适应了物联网发展的未来需求。

如图9所示，为本申请实施例提供的一种固件更新装置110的功能模块框图，该装置应用于上述服务器100。所述装置包括更新模块111、接收模块112和发送模块113。

更新模块111，用于在获得固件数据包的属性信息后，根据所述属性信息生成固件更新通知，将所述固件更新通知加载至预先定义的包含多个属性项的标题以进行消息发布，所述标题为从属于消息队列的任一标题；

在本实施例中，关于更新模块111的描述具体可参考对图2所示的步骤S110的详细描述，即步骤S110可以由更新模块111执行。

接收模块112，用于接收终端设备300在监测到自身所订阅的标题有消息发布时所发送的更新请求，其中，所述固件更新通知和更新请求基于protobuf格式所生成；

在本实施例中，关于接收模块112的描述具体可参考对图2所示的步骤S120的详细描述，即步骤S120可以由接收模块112执行。

发送模块113，用于根据所述更新请求获得固件数据包，并将所述固件数据包发送给所述终端设备300，以使所述终端设备300根据接收到的固件数据包进行固件更新。

在本实施例中，关于发送模块113的描述具体可参考对图2所示的步骤S130的详细描述，即步骤S130可以由发送模块113执行。

在一种可能的实现方式中，预先定义的标题包括多个，上述更新模块111可以用于通过以下方式进行消息发布：

获得所述属性信息中包含的属性适用项；

根据各所述属性适用项所适用的属性项，对多个属性适用项进行组合；

利用组合后的属性适用项生成固件更新通知并进行序列化处理，将序列化处理后的固件更新通知加载至预先定义的包含多个属性项的标题以进行消息发布。

在一种可能的实现方式中，上述发送模块113可以用于通过以下方式得到固件数据包：

获得所述更新请求中携带的固件名称，根据所述固件名称查找获得对应的固件数据包；

根据预先定义的结构体信息将所述固件数据包写入至固件主体结构中并发送至所述终端设备300，以使所述终端设备300根据存储的结构体信息对接收到的固件主体结构进行解析，并根据解析后得到的固件数据包进行固件更新。

在一种可能的实现方式中，所述结构体信息包含多种类型的固件结构体信息，各所述固件结构体由protobuf格式所生成。

在一种可能的实现方式中，所述更新请求为经过protobuf序列化的更新请求，上述发送模块113可以用于通过以下方式获得固件名称：

对所述更新请求进行protobuf反序列化处理；

获得反序列化处理后的更新请求中携带的固件名称。

在一种可能的实现方式中，上述发送模块113可以用于通过以下方式得到固件主体结构：

从预先创建的固件库中加载所述固件数据包；

根据预先定义的结构体信息获得其中的固件主体信息，基于所述固件主体信息和固件数据包得到固件主体结构；

对所述固件主体结构进行序列化处理，将所述固件数据包写入至序列化之后的固件主体结构中并发送至所述终端设备300。

在一种可能的实现方式中，上述固件更新装置110还可包括判断模块，该判断模块可以用于：

接收终端设备300发送的更新反馈信息，所述更新反馈信息基于protobuf格式所生成；

获得所述更新反馈信息中所包含的所述终端设备300经过更新后的固件版本号以及更新结果字段；

根据所述更新结果字段和所述更新后的固件版本号判断所述终端设备300是否更新成功，并生成所述终端设备300的固件更新记录。

如图10所示，本申请实施例还提供一种电子设备，该电子设备可以是上述服务器100。该电子设备包括固件更新装置110、存储器120、处理器130以及通信单元140。

所述存储器120、处理器130以及通信单元140各元件相互之间直接或间接地电性连接，以实现信息的传输或交互。例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。存储器120中存储有以软件或固件(Firmware)的形式存储于所述存储器120中的软件功能模块，所述处理器130通过运行存储在存储器120内的软件程序以及模块，如本申请实施例中的固件更新装置110，从而执行各种功能应用以及数据处理，即实现本申请实施例中的固件更新方法。

其中，所述存储器120可以是，但不限于，随机存取存储器（Random AccessMemory，RAM），只读存储器（Read Only Memory，ROM），可编程只读存储器（ProgrammableRead-Only Memory，PROM），可擦除只读存储器（Erasable Programmable Read-OnlyMemory，EPROM），电可擦除只读存储器（Electric Erasable Programmable Read-OnlyMemory，EEPROM）等。其中，存储器120用于存储程序，所述处理器130在接收到执行指令后，执行所述程序。所述通信单元140用于建立服务器100与终端设备300之间的通信。

所述处理器130可能是一种集成电路芯片，具有信号的处理能力。上述的处理器130可以是通用处理器，包括中央处理器（Central Processing Unit， CPU）、网络处理器（Network Processor， NP）等。还可以是数字信号处理器（DSP）、专用集成电路（ASIC）、现场可编程门阵列（FPGA）或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器130也可以是任何常规处理器等。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器130运行时执行上述固件更新方法的步骤。

综上所述，本申请提供的固件更新方法、装置、服务器100和计算机可读存储介质，通过预先定义包含多个属性项的标题，服务器100在获得固件数据包的属性信息后，生成固件更新通知并加载至标题以进行消息发布，其中，标题为从属于消息队列的任一标题。从而在接收到终端设备300在监测到自身所订阅的标题有消息发布时发送的更新请求时，获得固件数据包，并将固件数据包发送给终端设备300，以使终端设备300根据接收到的固件数据包进行固件更新。本方案中，采用预先定义标题且利用protobuf消息格式以及消息队列的方式，可实现高效率、高扩展性的固件数据的管理。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种固件更新方法，其特征在于，应用于与多个终端设备通信连接的服务器，所述方法包括：

在获得固件数据包的属性信息后，根据所述属性信息生成固件更新通知，将所述固件更新通知加载至预先定义的包含多个属性项的标题以进行消息发布，所述标题为从属于消息队列的任一标题；

接收终端设备在监测到自身所订阅的标题有消息发布时所发送的更新请求，其中，所述固件更新通知和更新请求基于protobuf格式所生成；

根据所述更新请求获得固件数据包，并将所述固件数据包发送给所述终端设备，以使所述终端设备根据接收到的固件数据包进行固件更新。

2.根据权利要求1所述的固件更新方法，其特征在于，所述根据所述更新请求获得固件数据包，并将所述固件数据包发送给所述终端设备，以使所述终端设备根据接收到的固件数据包进行固件更新的步骤，包括：

获得所述更新请求中携带的固件名称，根据所述固件名称查找获得对应的固件数据包；

根据预先定义的结构体信息将所述固件数据包写入至固件主体结构中并发送至所述终端设备，以使所述终端设备根据存储的结构体信息对接收到的固件主体结构进行解析，并根据解析后得到的固件数据包进行固件更新。

3.根据权利要求2所述的固件更新方法，其特征在于，所述根据预先定义的结构体信息将所述固件数据包写入至固件主体结构中并发送至所述终端设备的步骤，包括：

从预先创建的固件库中加载所述固件数据包；

根据预先定义的结构体信息获得其中的固件主体信息，基于所述固件主体信息和固件数据包得到固件主体结构；

对所述固件主体结构进行序列化处理，将所述固件数据包写入至序列化之后的固件主体结构中并发送至所述终端设备。

4.根据权利要求2所述的固件更新方法，其特征在于，所述结构体信息包含多种类型的固件结构体信息，各所述固件结构体由protobuf格式所生成。

5.根据权利要求2所述的固件更新方法，其特征在于，所述更新请求为经过protobuf序列化的更新请求；

所述获得所述更新请求中携带的固件名称的步骤，包括：

对所述更新请求进行protobuf反序列化处理；

获得反序列化处理后的更新请求中携带的固件名称。

6.根据权利要求1所述的固件更新方法，其特征在于，所述根据所述更新请求获得固件数据包，并将所述固件数据包发送给所述终端设备，以使所述终端设备根据接收到的固件数据包进行固件更新的步骤之后，所述方法还包括：

接收终端设备发送的更新反馈信息，所述更新反馈信息基于protobuf格式所生成；

获得所述更新反馈信息中所包含的所述终端设备经过更新后的固件版本号以及更新结果字段；

根据所述更新结果字段和所述更新后的固件版本号判断所述终端设备是否更新成功，并生成所述终端设备的固件更新记录。

7.根据权利要求1所述的固件更新方法，其特征在于，预先定义的标题包括多个；

所述根据所述属性信息生成固件更新通知，将所述固件更新通知加载至预先定义的包含多个属性项的标题以进行消息发布的步骤，包括：

获得所述属性信息中包含的属性适用项；

根据各所述属性适用项所适用的属性项，对多个属性适用项进行组合；

利用组合后的属性适用项生成固件更新通知并进行序列化处理，将序列化处理后的固件更新通知加载至预先定义的包含多个属性项的标题以进行消息发布。

8.一种固件更新装置，其特征在于，应用于与多个终端设备通信连接的服务器，所述装置包括：

更新模块，用于在获得固件数据包的属性信息后，根据所述属性信息生成固件更新通知，将所述固件更新通知加载至预先定义的包含多个属性项的标题以进行消息发布，所述标题为从属于消息队列的任一标题；

接收模块，用于接收终端设备在监测到自身所订阅的标题有消息发布时所发送的更新请求，其中，所述固件更新通知和更新请求基于protobuf格式所生成；

发送模块，用于根据所述更新请求获得固件数据包，并将所述固件数据包发送给所述终端设备，以使所述终端设备根据接收到的固件数据包进行固件更新。

9.一种服务器，其特征在于，包括一个或多个存储介质和一个或多个与存储介质通信的处理器，一个或多个存储介质存储有处理器可执行的机器可执行指令，当服务器运行时，处理器执行所述机器可执行指令，以执行权利要求1-7中任意一项所述的固件更新方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有机器可执行指令，所述机器可执行指令被执行时实现权利要求1-7中任意一项所述的固件更新方法。

Images