终端的更新方法、服务器及终端与流程

本发明涉及车辆控制技术领域，尤其涉及一种终端的更新方法、服务器及终端。

背景技术：

轨道交通列车中通常安装有乘客信息系统(passengerinformationsystem，pis)来提供语音广播播报、多媒体信息显示等服务，pis中流媒体的播放由播控器控制。播控器是一种嵌入式设备，用于接收视频数据并播放。为了提高播控器的适用性，需要对播控器进行不定期更新。

现有的播控器更新方法主要通过播控器中内置的应用程序对播控器进行更新，由服务器同时向所有的播控器下发更新指令，播控器中内置的应用程序下载更新文件，并在下载完成后重启操作系统，以完成更新过程。

由于现有的播控器更新方法在更新时，服务器同时向所有的播控器下发更新指令，容易导致大量的播控器在同一时刻下载更新文件，造成网络资源紧张，进而导致系统异常，收发数据失败或传输速度缓慢；此外，完成更新需要重启系统，耗时长，且频繁重启系统有损硬件使用寿命。

技术实现要素：

本发明旨在至少在一定程度上解决相关技术中的技术问题之一。

为此，本发明的第一个目的在于提出一种终端的更新方法，通过将更新消息添加到消息队列中，再通过消息队列将更新消息发送给待更新的终端，能够对更新消息的发送进行控制，实现分批次发送更新消息，进而实现对同时下载的更新文件的数量进行控制，大大减少同时下载的数量，从而减少对网络资源的占用，避免网络拥堵，解决现有技术中因大量终端同时下载更新文件导致的网络资源紧张的技术问题。

本发明的第二个目的在于提出另一种终端的更新方法。

本发明的第三个目的在于提出一种服务器。

本发明的第四个目的在于提出一种终端。

本发明的第五个目的在于提出另一种服务器。

本发明的第六个目的在于提出另一种终端。

本发明的第七个目的在于提出一种计算机程序产品。

本发明的第八个目的在于提出一种非临时性计算机可读存储介质。

为达上述目的，本发明第一方面实施例提出了一种终端的更新方法，包括：

获取待更新终端，形成待更新列表；

按照所述待更新列表生成更新消息，并将所述更新消息添加到消息队列中；

通过所述消息队列将所述更新消息发送给所述待更新终端。

本发明实施例的终端的更新方法，通过获取待更新终端，形成待更新列表，按照待更新列表生成更新消息，并将更新消息添加到消息队列中，通过消息队列将更新消息发送给待更新终端。通过将更新消息添加到消息队列中，再通过消息队列将更新消息发送给待更新的终端，能够对更新消息的发送进行控制，实现分批次发送更新消息，进而实现对同时下载的更新文件的数量进行控制，大大减少同时下载的数量，从而减少对网络资源的占用，避免网络拥堵，解决现有技术中因大量终端同时下载更新文件导致的网络资源紧张的技术问题。

为达上述目的，本发明第二方面实施例提出了另一种终端的更新方法，包括：

从消息队列中接收服务器下发的更新消息；

解析所述更新消息，获取下载地址；

登录与所述下载地址匹配的下载服务器，从中下载更新数据；

当下载成功后，利用所述更新数据对终端上的应用进行更新。

本发明实施例的终端的更新方法，通过从消息队列中接收服务器下发的更新消息，解析更新消息以获取下载地址，登录与下载地址匹配的下载服务器，并从中下载更新数据，在下载成功后利用更新数据对终端上的应用进行更新。通过由终端从下载服务器下载更新数据，并利用更新数据对终端上的应用进行更新，能够方便监控应用的更新状况，且无需重启系统即可实现应用更新，缩短了应用更新时长，减少了对其他硬件的损坏，解决了现有技术中需要重启系统才能完成更新导致的耗时长、损坏硬件的技术问题。

为达上述目的，本发明第三方面实施例提出了一种服务器，包括：

列表生成模块，用于获取待更新终端，形成待更新列表；

消息生成模块，用于按照所述待更新列表生成更新消息，并将所述更新消息添加到消息队列中；

发送模块，用于通过所述消息队列将所述更新消息发送给所述待更新终端。

本发明实施例的服务器，通过获取待更新终端，形成待更新列表，按照待更新列表生成更新消息，并将更新消息添加到消息队列中，通过消息队列将更新消息发送给待更新终端。通过将更新消息添加到消息队列中，再通过消息队列将更新消息发送给待更新的终端，能够对更新消息的发送进行控制，实现分批次发送更新消息，进而实现对同时下载的更新文件的数量进行控制，大大减少同时下载的数量，从而减少对网络资源的占用，避免网络拥堵，解决现有技术中因大量终端同时下载更新文件导致的网络资源紧张的技术问题。

为达上述目的，本发明第四方面实施例提出了一种终端，包括：

接收模块，用于从消息队列中接收服务器下发的更新消息；

获取模块，用于解析所述更新消息，获取下载地址；

下载模块，用于登录与所述下载地址匹配的下载服务器，从中下载更新数据；

更新模块，用于当下载成功后，利用所述更新数据对终端上的应用进行更新。

本发明实施例的终端，通过从消息队列中接收服务器下发的更新消息，解析更新消息以获取下载地址，登录与下载地址匹配的下载服务器，并从中下载更新数据，在下载成功后利用更新数据对终端上的应用进行更新。通过由终端从下载服务器下载更新数据，并利用更新数据对终端上的应用进行更新，能够方便监控应用的更新状况，且无需重启系统即可实现应用更新，缩短了应用更新时长，减少了对其他硬件的损坏，解决了现有技术中需要重启系统才能完成更新导致的耗时长、损坏硬件的技术问题。

为达上述目的，本发明第五方面实施例提出了一种服务器，包括：处理器和存储器；其中，所述处理器通过读取所述存储器中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，以用于实现如第一方面实施例所述的终端的更新方法。

为达上述目的，本发明第六方面实施例提出了一种终端，包括：处理器和存储器；其中，所述处理器通过读取所述存储器中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，以用于实现如第二方面实施例所述的终端的更新方法。

为达上述目的，本发明第七方面实施例提出了一种计算机程序产品，当所述计算机程序产品中的指令由处理器执行时实现如第一方面实施例所述的终端的更新方法或者第二方面实施例所述的终端的更新方法。

为达上述目的，本发明第八方面实施例提出了一种非临时性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如第一方面实施例所述的终端的更新方法或者第二方面实施例所述的终端的更新方法。

本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本发明实施例所提供的第一种终端的更新方法的流程示意图；

图2为本发明实施例所提供的第二种终端的更新方法的流程示意图；

图3为本发明实施例所提供的第三种终端的更新方法的流程示意图；

图4为本发明实施例一所提供的另一种终端的更新方法的流程示意图；

图5为执行本发明实施例的终端的更新方法的系统架构示意图；

图6为pis播控器的更新方法的实现过程示意图。

图7为本发明实施例所提供的第一种服务器的结构示意图；

图8为本发明实施例所提供的第二种服务器的结构示意图；

图9为本发明实施例所提供的第三种服务器的结构示意图；

图10为本发明实施例一所提供的一种终端的结构示意图；

图11为本发明实施例所提供的另一种服务器的结构示意图；以及

图12为本发明实施例所提供的另一种终端的结构示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本发明，而不能理解为对本发明的限制。

下面参考附图描述本发明实施例的终端的更新方法、服务器及终端。

现有的播控器更新方法中，通常是在触发自动更新服务后，由服务器一次性向所有的播控器下发更新指令，并监控所有播控器的更新进度。播控器中内置一个应用程序，该应用程序中集成了自动升级模块，由自动升级模块从本地默认的或者远端服务器发送来的文件服务器上，下载更新所需要的应用程序，并在下载完成后将新下载的应用程序改名为标准启动程序的名字，将原有的应用程序的名字改为标准回滚程序的名字，之后重启操作系统，并在重启完毕后，操作系统按照系统默认的启动脚本，根据设定好的规则启动标准启动程序或者回滚程序。

采用现有的播控器更新方法进行更新时，服务器未对更新指令的下发进行控制，导致大量的播控器同时下载播控器应用程序，占用较多的网络资源，造成网络资源紧张，使系统下发其他指令失败以及传输数据耗时较长。由于自动升级模块是内置在播控器中的，没有单独的自动更新应用程序，导致每次更新都需要重启系统，系统重启耗时过长，导致播控器更新速度慢，且频繁重启系统容易导致硬件损坏，缩短系统的使用寿命。

针对上述问题，本发明实施例提出一种终端的更新方法，能够在无需重启系统的情况下完成更新，在保证系统升级的平稳性以及灵活性的同时更加合理地利用系统网络资源，从而提高运营水平。

图1为本发明实施例所提供的第一种终端的更新方法的流程示意图，该方法在服务器侧执行。

如图1所示，该终端的更新方法包括以下步骤：

步骤101，获取待更新终端，形成待更新列表。

其中，待更新终端可以是pis播控器，用于控制pis中的流媒体播放。

为了使服务器能够向终端发送更新指令，以使终端根据更新指令进行更新，服务器需要掌握管控范围内所有的待更新的终端的信息，比如，需要获知所有终端的名称、唯一标识符等。

本实施例中，服务器可以获取待更新终端，并根据待更新中的信息形成待更新列表。

作为一种可能的实现方式，服务器可以接收第一消息，其中，第一消息中携带有待更新终端所属的路段的标识，第一消息可以由其中一个待更新终端发送。服务器接收到第一消息后，对第一消息进行解析，可以获取发送第一消息的待更新终端所属的路段的标识，进而，根据该路段的标识，服务器可以从数据库中查询隶属于该路段的终端，并作为待更新终端。本实施例中，可以在数据库中预先存储不同的路段的标识以及隶属于该路段的终端的对应关系，并预先设定一个待更新终端向服务器发送携带该待更新终端所属路段的标识的第一消息。当触发自动更新服务时，该待更新终端向服务器发送第一消息，服务器从接收的第一消息中提取出路段的标识，并从数据库中查询与该路段的标识对应的终端，将查询到的终端作为待更新终端，并形成待更新列表。其中，待更新列表中可以包含各个待更新终端的名称、唯一标识符、所属路段的标识等。

通过接收携带待更新终端所属的路段的标识的第一消息，进而根据路段的标识获取隶属于该路段的终端作为待更新终端，能够获得同一路段内所有的待更新终端，使同一路段内的终端均能够得到更新。

步骤102，按照待更新列表生成更新消息，并将更新消息添加到消息队列中。

服务器生成了待更新列表之后，即可根据待更新列表，为待更新终端生成更新消息，并将更新消息添加到消息队列中。

本实施例中，服务器可以针对待更新列表中的每个待更新终端生成对应的更新消息，更新消息中可以包含用于下载对该待更新终端进行更新的更新数据的地址、待下载文件的文件名、用于登录下载服务器的用户名和密码中的一种或多种。

由于一条线路跨越的区域较大，例如一条高铁线路往往跨越多个省域，而一个下载服务器的覆盖范围有限，可以将一条线路划分为多个路段，为每个路段设置一个下载服务器，以保证待更新终端需要更新时，能够成功连接至下载服务器。从而，作为一种可能的实现方式，服务器按照待更新列表生成更新消息时，可以先确定待更新终端所属的路段，其中，待更新终端所属的路段可以根据待更新终端最近一次播报的站点确定，或者，还可以根据服务器获取到待更新终端时，列车当前行驶的位置确定。服务器中可以预先存储每条线路所划分的路段，以及各个路段所覆盖的区域，服务器获取了列车当前行驶的位置或最新经过的站点后，通过查询各个路段所覆盖的区域，即可确定待更新终端所属的路段。进而，根据待更新终端所属的路段，确定待更新终端对应的下载服务器，利用下载服务器的地址和待更新终端的标识信息，生成更新消息。

服务器生成更新消息后，可以将更新消息添加至消息队列中，消息队列可以将从服务器接收的更新消息存储在特定的模式中，比如可以将更新消息存储在消息队列的主题消息(topic)模式中，等待终端收取更新消息。进一步地，还可以为消息队列中的更新消息设置时限，当更新消息存储在消息队列中的时长超过设置的时限时，消息队列向服务器上报一个返回值，以提醒服务器重新添加对应的更新消息。

步骤103，通过消息队列将更新消息发送给待更新终端。

本实施例中，服务器为每个待更新终端生成更新消息之后，可以通过消息队列将更新消息发送给待更新终端。

具体地，服务器向待更新终端下发更新消息时，可以按照预设的发送规则将更新消息发送给对应的待更新终端，以使待更新终端根据更新消息进行更新。比如，服务器可以将更新消息进行分组后发送，每次发送的更新消息的个数不超过预设的个数。

通过采用消息队列作为消息分发的手段，服务器无须处理大量的并发通信，增加了异步通信的能力，增加了数据可靠性，提高了更新过程的健壮性，降低了服务器与终端之间的耦合。

本实施例的终端的更新方法，通过获取待更新终端，形成待更新列表，按照待更新列表生成更新消息，并将更新消息添加到消息队列中，通过消息队列将更新消息发送给待更新终端。通过将更新消息添加到消息队列中，再通过消息队列将更新消息发送给待更新的终端，能够对更新消息的发送进行控制，实现分批次发送更新消息，进而实现对同时下载的更新文件的数量进行控制，大大减少同时下载的数量，从而减少对网络资源的占用，避免网络拥堵，解决现有技术中因大量终端同时下载更新文件导致的网络资源紧张的技术问题。

本发明实施例提供了两种通过消息队列将更新消息发送给待更新终端的可能实现方式，以使服务器下发更新消息的方式更加灵活。

作为其中一种可能的实现方式，当有多个待更新终端时，服务器可以通过消息队列分批次将更新消息传输到待更新终端上。当服务器生成的更新消息为多个时，表明待更新终端有多个，为了避免多个待更新终端同时下载更新数据占用较多的网络资源，服务器可以将更新消息分为多个批次，按照批次依次将更新消息发送给待更新终端。比如，由于带宽限制，服务器可以将每三个更新消息分为一组，逐组下发更新消息给对应的待更新终端，以保证同一时间处于更新数据下载状态的下载服务器的个数不超过三个，从而节省网络资源。通过分批次下发更新消息，能够有效利用系统的网络资源，减少对带宽资源的占用。

作为另一种可能的实现方式，当有多个待更新终端时，服务器可以先将更新消息发送给其中一个待更新终端进行更新测试，当该待更新终端更新成功后，再更新其他待更新终端，以有效避免同时更新多个待更新终端且更新失败时导致的资源浪费。从而，本发明实施例提出了另一种终端的更新方法，图2为本发明实施例所提供的第二种终端的更新方法的流程示意图。

如图2所示，在如图1所示实施例的基础上，步骤103可以包括以下步骤：

步骤201，当有多个待更新终端时，从所有的待更新终端中选取一个作为测试终端。

当服务器生成的待更新列表中的待更新终端为多个时，服务器可以从所有的待更新终端中选取一个作为测试终端。比如，服务器可以从待更新列表中随机选择一个待更新终端作为测试终端，或者，选择待更新列表中的第一个或最后一个待更新终端作为测试终端。

步骤202，通过消息队列将测试终端对应的更新消息发送给测试终端。

服务器选定测试终端之后，可以将与该测试终端对应的更新消息通过消息队列发送出去，以使测试终端根据接收到的更新消息下载更新数据，并利用更新数据进行更新。

步骤203，接收测试终端返回的状态信息。

其中，测试终端返回的状态信息比如可以是更新成功或者更新失败。

当测试终端更新完成后，测试终端将更新结果(更新成功或更新失败)作为状态信息返回给服务器。服务器接收到测试终端返回的状态信息后，可以根据状态信息判断是否继续下发更新消息以控制剩余的待更新终端进行更新。

比如，当测试终端返回的状态信息指示测试终端更新失败时，服务器停止下发更新消息；当状态信息指示测试终端更新成功时，服务器继续下发更新消息。

步骤204，如果状态信息指示测试终端更新成功，则通过消息队列分批次将更新消息发送给剩余的待更新终端。

当服务器接收的测试终端返回的状态信息指示测试终端更新成功时，服务器继续通过消息队列分批次将更新消息发送给剩余的待更新终端。

具体地，服务器可以先确定测试终端所在的车厢，进而通过消息队列将更新消息发送给属于该车厢的剩余的待更新终端。当属于该车厢的剩余的待更新终端均更新成功，则通过消息队列分批次将更新消息发送给剩余的非车厢内的待更新终端。

一个车厢内可能设置有不止一个终端，同一车厢内的多个终端所处的网络环境相同或相似，当其中一个终端更新成功时，其他的终端更新成功的概率也较大，从而，本实施例中，服务器可以先将更新消息发送给与测试终端处于同一车厢内的待更新终端，使该车厢内剩余的待更新终端先进行更新。当该车厢内的终端均更新成功时，服务器再通过消息队列分批次将更新消息发送给其他车厢内的待更新终端。比如，服务器将更新消息发送给其他车厢内的待更新终端时，可以以车厢为单位，将属于同一车厢的待更新终端划分为一个批次，按照车厢依次下发更新消息至待更新终端；或者，服务器也可以对剩余的更新消息进行分组，保证每组更新消息的数量不超过预设的个数阈值(比如3个)，逐组下发更新消息至对应的待更新终端。

本实施例的终端的更新方法，通过在有多个待更新终端时，先从中选择一个作为测试终端，通过消息队列向测试终端下发对应的更新消息，并接收测试终端返回的状态信息，当状态信息指示测试终端更新成功时，再通过消息队列分批次将更新消息发送给剩余的待更新终端。通过测试终端更新成功后再更新其他的待更新终端，能够节省网络资源，进一步提高网络资源利用的有效性。

在本发明实施例一种可能的实现方式中，服务器还可以对待更新终端的更新结果进行统计，以了解待更新终端的更新状态。从而，本发明实施例还提出了另一种终端的更新方法，图3为本发明实施例所提供的第三种终端的更新方法的流程示意图。

如图3所示，在前述实施例的基础上，向待更新终端下发更新消息之后，还可以包括以下步骤：

步骤301，接收待更新终端返回的状态信息。

其中，待更新终端返回的状态信息比如可以包括：下载中、下载失败、下载成功、更新成功和更新失败等。

步骤302，根据状态信息，更新待更新终端的当前状态。

待更新终端接收到服务器下发的更新消息之后，根据更新消息下载更新数据，并在下载完成后向服务器返回状态信息。如果待更新终端成功下载更新数据，则待更新终端向服务器返回下载成功的状态信息；如果待更新终端未能成功下载更新数据，则待更新终端向服务器返回下载失败的状态信息。

服务器接收到待更新终端返回的状态信息后，可以根据状态信息更新待更新终端的当前状态。比如，服务器向待更新终端下发更新消息后，将该待更新终端的当前状态修改为“发送中”，如果服务器接收到该待更新终端返回的下载成功的状态信息，则服务器将该待更新终端的当前状态从“发送中”更新为“更新完成”。

在本发明实施例一种可能的实现方式中，如果服务器接收的状态信息指示待更新终端在下载完更新数据后未重启成功，则服务器通过消息队列将回滚到上一版本的指示消息发送给待更新终端，并接收待更新终端在回滚待上一版本的过程中生成的状态消息。如果待更新终端成功回滚至上一版本，则待更新终端向服务器返回回滚至上一版本成功的状态消息；如果待更新终端未能成功回滚至上一版本，则向服务器返回回滚至上一版本失败的状态消息。

通过在更新数据未重启成功时，由服务器向待更新终端下发回滚至上一版本的指示消息，以使待更新终端重新启动上一版本，能够保证在终端更新失败时仍能采用旧版本的终端对pis进行控制，保证pis的正常使用。

在本发明实施例一种可能的实现方式中，如果服务器接收的状态信息指示待更新终端未成功下载更新数据，则服务器重新通过消息队列将更新消息发送给待更新终端。如果服务器向同一个待更新终端发送更新消息的重复的次数达到预设的次数，则服务器将该待更新终端的当前状态确定为需要人工干扰的状态，进而将该待更新终端从待更新列表中删除，并将其加入到需要人工干扰的状态对应的状态列表中。

步骤303，根据待更新终端的当前状态，确定待更新终端所属的状态列表。

服务器对待更新终端的当前状态进行更新后，即可根据当前状态确定待更新终端所属的状态列表。比如，对于当前状态为“下载成功”的待更新终端，所属的状态列表为更新完成列表；对于当前状态为“下载失败”的待更新终端，所属的状态列表为更新失败列表。

步骤304，将待更新终端从之前所属的状态列表中删除，并添加到当前确定出的所属的状态列表中。

本实施例中，服务器确定了待更新终端所属的状态列表之后，即可将待更新终端从之前的状态列表中删除，并添加到当前确定出的所属的状态列表中。比如，服务器向待更新终端下发更新消息后，将该待更新终端添加至“发送中”列表中，如果服务器接收到该待更新终端返回的下载成功的状态信息，则服务器将该待更新终端从“发送中”队列中移除，并添加至“更新完成”列表中。

在本发明实施例一种可能的实现方式中，当服务器接收到待更新终端返回的回滚至上一版本失败的状态消息时，服务器可以将该待更新终端从当前所属的状态列表中删除，并添加至需要人工干扰的状态对应的状态列表中，以等待工作人员手动干预终端的更新过程，保证终端成功启动更新数据或成功回滚至上一版本。

在本发明实施例一种可能的实现方式中，服务器还可以对待更新列表进行监控，当待更新列表中不存在待更新终端时，则输出需要人工干扰的状态对应的状态列表，以使工作人员对需要人工干扰的状态对应的状态列表中的待更新终端进行干预，保证终端成功启动更新数据或成功回滚至上一版本。

本实施例的终端的更新方法，通过接收待更新终端返回的状态信息，根据状态信息更新待更新终端的当前状态，并根据待更新终端的当前状态确定待更新终端所属的状态列表，进而将待更新终端从当前所属的状态列表中删除，并添加到当前确定出的所属的状态列表中，能够对待更新终端的状态进行监控并更新，方便工作人员根据状态列表对待更新终端进行干预。

上述实施例从服务器侧解释说明了本发明实施例的终端的更新方法，为了更加清楚地描述本发明实施例的终端的更新方法，本发明实施例还提出了另一种终端的更新方法。

图4为本发明实施例一所提供的另一种终端的更新方法的流程示意图，该方法由终端侧执行，终端中可以包括播控器应用程序和自动更新应用程序，由自动更新应用程序对播控器应用程序进行更新。通过设置一个独立于播控器应用程序的自动更新应用程序，由自动更新应用程序控制播控器应用程序更新，使得更新时不必重启整个系统，减少了不必要的操作，保证了系统的平稳性。

如图4所示，该终端的更新方法包括以下步骤：

步骤401，从消息队列中接收服务器下发的更新消息。

消息队列作为下发更新消息的中转站，服务器将更新消息下发至消息队列，由终端从消息队列中接收服务器下发的更新消息，降低了服务器与终端之间的耦合。

步骤402，解析更新消息，获取下载地址。

终端接收到更新消息后，对更新消息进行解析，可以获取更新数据的下载地址。其中，下载地址用于指示更新数据所在的下载服务器。

在本发明实施例一种可能的实现方式中，终端对接收到的更新消息进行解析后，除了可以获取到更新数据的下载地址外，还可以获取待下载的更新数据的名称、登录下载服务器所需的用户名以及密码等信息，以登录下载服务器下载对应名称的更新数据。

步骤403，登录与下载地址匹配的下载服务器，从中下载更新数据。

终端获取到下载地址之后，链接至该下载地址即可与下载服务器连接，并自动登录下载服务器，终端可以从中下载更新数据。

在本发明实施例一种可能的实现方式中，为保证下载服务器的数据安全，可以将登录下载服务器的用户名和密码封装在更新消息中，终端通过对接收的更新消息进行解析，可以获取到下载地址以及登录与下载地址匹配的下载服务器所需的用户名和密码，进而在登录成功后从下载服务器下载更新数据。

步骤404，当下载成功后，利用更新数据对终端上的应用进行更新。

具体地，当更新数据下载成功后，终端可以对更新数据进行安装并对与更新数据匹配的应用进行重启，当重启成功后完成应用的更新。

本实施例中，终端下载完成更新数据后，即可安装新下载的更新数据，安装完成后终端中的应用即更新为与更新数据匹配的版本，终端重新启动新版本的应用，若重启成功，则应用更新过程完成。

在本发明实施例一种可能的实现方式中，终端还可以在从开始下载更新数据到更新结束的过程中，实时监控待更新终端当前状态，并根据当前状态生成状态信息发送给服务器，以使服务器实时掌握待更新终端的当前状态，并根据待更新终端的当前状态对待更新终端所属的状态列表进行调整。

在本发明实施例一种可能的实现方式中，当更新数据重启失败时，终端还可以从消息队列中接收服务器发送的回滚到上一版本的指示消息，其中，指示消息是由服务器在待更新终端利用更新数据重启应用失败时下发的。终端执行指示消息，并对待更新终端的当前状态进行监控，根据当前状态，生成状态消息发送给服务器。比如，终端下载完成更新数据后，可以先进行改名操作，将下载的更新数据的名称修改为标准启动程序名称，将原有的旧版本的应用程序的名称修改为标准回滚程序名称，之后再对更新数据进行重启。当重启失败后，根据指示消息，对被修改为标准回滚程序名称的应用程序进行重启，并监控重启结果上报给服务器，以使服务器在接收到回滚至上一版本失败的状态消息时，将待更新终端添加至需要人工干扰的状态对应的状态列表中。

本实施例的终端的更新方法，通过从消息队列中接收服务器下发的更新消息，解析更新消息以获取下载地址，登录与下载地址匹配的下载服务器，并从中下载更新数据，在下载成功后利用更新数据对终端上的应用进行更新。通过由终端从下载服务器下载更新数据，并利用更新数据对终端上的应用进行更新，能够方便监控应用的更新状况，且无需重启系统即可实现应用更新，缩短了应用更新时长，减少了对其他硬件的损坏，解决了现有技术中需要重启系统才能完成更新导致的耗时长、损坏硬件的技术问题。

图5为执行本发明实施例的终端的更新方法的系统架构示意图。如图5所示，该系统由服务器、消息队列和终端组成。其中，消息队列为计算机设备；终端中设置有播控器应用程序和自动更新应用程序，自动更新应用程序用于对播控器应用程序进行自动更新。对播控器应用程序进行更新的具体实现过程为：服务器生成待更新播控器应用程序的待更新列表以及用于对播控器应用程序进行更新的更新消息，并按照预设的发送策略将更新消息分批次下发至消息队列。终端从消息队列中获取更新消息，并对更新消息进行解析，获取下载地址、待下载的更新数据的文件名等信息，并利用解析的信息登录下载服务器，从中下载更新数据。终端中的自动更新应用程序判断更新数据是否下载成功，并将判断结果上报给服务器，同时，当更新数据下载失败时，服务器根据预先设置的更新策略判断更新数据下载失败的次数是否达到预设的次数，并在达到预设次数时将终端添加至需要人工干扰的状态对应的状态列表中；当更新数据下载成功时，自动更新应用程序安装更新数据并重启播控器应用程序，如果重启成功，则更新过程结束，自动更新应用程序向服务器上报更新成功的状态信息；如果重启失败，则自动更新应用程序向服务器上报重启失败的状态信息。服务器接收到终端返回的重启失败的状态信息后，通过消息队列向终端返回回滚至上一版本的指示消息。终端根据指示消息安装上一版本的播控器应用程序，并监控安装结果，将安装结果反馈至服务器。当待更新列表中没有待更新播控器应用程序时，服务器输出需要人工干扰的状态对应的状态列表，以使工作人员根据列表采取相应的补救措施。采用本发明实施例的终端的更新方法，在更新播控器应用程序时无需重启整个系统，节省了更新时间，通过分批次下发更新消息，节省了更新过程中对网络资源的占用。

下面以待更新终端为pis播控器为例详细说明本发明实施例的终端的更新方法，图6为pis播控器的更新方法的实现过程示意图。如图6所示，该终端的更新方法可以包括以下步骤：

步骤501，服务器获取待更新的pis播控器，形成待更新列表。

步骤502，服务器按照待更新列表生成更新消息，并将更新消息添加到消息队列中。

步骤503，服务器通过消息队列将更新消息发送给待更新的pis播控器。

步骤504，待更新的pis播控器解析接收的更新消息，获取下载地址。

步骤505，待更新的pis播控器登录与下载地址匹配的下载服务器，从中下载更新数据。

步骤506，待更新的pis播控器利用下载完成的更新数据对pis播控器上的应用进行更新。

本实施例中，服务器可以获取每个待更新的pis播控器，并利用pis播控器的唯一标识符、所属路段等信息中的至少一个生成待更新列表，进而，根据待更新列表，针对每个待更新的pis播控器生成更新消息并添加至消息队列中，消息队列可以分批次地将更新消息发送给对应的pis播控器。pis播控器接收到更新消息后，可以对接收的更新消息进行解析，从中获取更新数据的下载地址，并根据下载地址登录对应的下载服务器，从下载服务器中下载所需的更新数据，进而，利用成功下载的更新数据对pis播控器中的应用进行更新。由此，能够在无需重启系统的条件下实现应用更新，缩短更新时长。

此处需要说明的是，前述实施例中对终端的更新方法的描述也适用于本实施例中对待更新的pis播控器进行更新的过程的描述，其实现原理类似，此处不再赘述。

本实施例中，通过由消息队列作为中转站发送更新消息，便于对更新消息的发送进行控制，减少对网络资源的占用，避免网络拥堵。通过由pis播控器利用更新数据对应用进行更新，无需重启系统即可实现应用更新，缩短了应用更新时长，减少了对其他硬件的损坏。

为了实现上述实施例，本发明还提出一种服务器。

图7为本发明实施例一所提供的一种服务器的结构示意图。

如图7所示，该服务器60包括：列表生成模块610、消息生成模块620，以及发送模块630。其中，

列表生成模块610，用于获取待更新终端，形成待更新列表。

其中，待更新终端可以为pis播控器。

具体地，列表生成模块610获取待更新终端时，具体用于接收第一消息，其中，第一消息中携带待更新终端所属的路段的标识；根据路段的标识，从数据库中查询隶属于路段的终端作为待更新终端。

消息生成模块620，用于按照待更新列表生成更新消息，并将更新消息添加到消息队列中。

具体地，消息生成模块620为待更新终端生成更新消息时，具体用于确定待更新终端所属的路段；根据待更新终端所属的路段，确定待更新终端对应的下载服务器；利用下载服务器的地址和待更新终端的标识信息，生成更新消息。

发送模块630，用于通过消息队列将更新消息发送给待更新终端。

作为一种可能的实现方式，当有多个待更新终端时，发送模块630还用于通过消息队列分批次将更新消息传输到待更新终端上。通过分批次下发更新消息，能够有效利用系统的网络资源，减少对带宽资源的占用。

作为一种可能的实现方式，如图8所示，在如图7所示实施例的基础上，发送模块630可以包括：

选取单元631，用于当有多个待更新终端时，从所有的待更新终端中选取一个作为测试终端。

发送单元632，用于通过消息队列将测试终端对应的更新消息发送给测试终端；以及，接收测试终端返回的状态信息，并在状态信息指示测试终端更新成功，通过消息队列分批次将更新消息发送给剩余的待更新终端。

具体地，当状态信息指示测试终端更新成功时，发送单元632具体用于确定测试终端所在的车厢；通过消息队列将更新消息，发送给属于该车厢的剩余的待更新终端；当属于该车厢的剩余的待更新终端均更新成功，则通过消息队列分批次将更新消息，发送给剩余的非该车厢内的待更新终端。

通过在有多个待更新终端时，先从中选择一个作为测试终端，通过消息队列向测试终端下发对应的更新消息，并接收测试终端返回的状态信息，当状态信息指示测试终端更新成功时，再通过消息队列分批次将更新消息发送给剩余的待更新终端。通过测试终端更新成功后再更新其他的待更新终端，能够节省网络资源，进一步提高网络资源利用的有效性。

在本发明实施例一种可能的实现方式中，如图9所示，在如图7所示实施例的基础上，该服务器60还可以包括：

接收模块640，用于接收待更新终端返回的状态信息。

状态更新模块650，用于根据状态信息，更新待更新终端的当前状态。

在本发明实施例一种可能的实现方式中，状态更新模块650还可以用于当状态信息指示待更新终端未成功下载更新数据时，则重新通过消息队列将更新消息发送给待更新终端；如果重复的次数到达预设的次数，则将待更新终端的当前状态确定为需要人工干扰的状态；将待更新终端从待更新列表中删除，并加入到需要人工干扰的状态对应的状态列表中。

在本发明实施例一种可能的实现方式中，状态更新模块650还可以用于当状态信息指示待更新终端在下载完更新数据后未重启成功时，则通过消息队列将回滚到上一版本的指示消息发送给待更新终端；接收待更新终端在回滚到上一版本的过程中生成的状态消息。

通过在更新数据未重启成功时，由服务器向待更新终端下发回滚至上一版本的指示消息，以使待更新终端重新启动上一版本，能够保证在终端更新失败时仍能采用旧版本的终端对pis进行控制，保证pis的正常使用。

确定模块660，用于根据待更新终端的当前状态，确定待更新终端所属的状态列表。

添加模块670，用于将待更新终端从之前所属的状态列表中删除，并添加到当前确定出的所属的状态列表中。

通过接收待更新终端返回的状态信息，根据状态信息更新待更新终端的当前状态，并根据待更新终端的当前状态确定待更新终端所属的状态列表，进而将待更新终端从当前所属的状态列表中删除，并添加到当前确定出的所属的状态列表中，能够对待更新终端的状态进行监控并更新，方便工作人员根据状态列表对待更新终端进行干预。

在本发明实施例一种可能的实现方式中，该服务器60还可以用于对待更新列表进行监控，当待更新列表中不存在待更新终端时，则输出需要人工干扰的状态对应的状态列表。

需要说明的是，前述对终端的更新方法实施例的解释说明，也适用于本实施例的服务器，其实现原理类似，此处不再赘述。

本实施例的服务器，通过获取待更新终端，形成待更新列表，按照待更新列表生成更新消息，并将更新消息添加到消息队列中，通过消息队列将更新消息发送给待更新终端。通过将更新消息添加到消息队列中，再通过消息队列将更新消息发送给待更新的终端，能够对更新消息的发送进行控制，实现分批次发送更新消息，进而实现对同时下载的更新文件的数量进行控制，大大减少同时下载的数量，从而减少对网络资源的占用，避免网络拥堵，解决现有技术中因大量终端同时下载更新文件导致的网络资源紧张的技术问题。

为了实现上述实施例，本发明还提出一种终端。

图10为本发明实施例一所提供的一种终端的结构示意图。

如图10所示，该终端90包括：接收模块910、获取模块920、下载模块930，以及更新模块940。其中，

接收模块910，用于从消息队列中接收服务器下发的更新消息。

获取模块920，用于解析更新消息，获取下载地址。

下载模块930，用于登录与下载地址匹配的下载服务器，从中下载更新数据。

更新模块940，用于当下载成功后，利用更新数据对终端上的应用进行更新。

具体地，更新模块940用于安装更新数据并对应用进行重启；当重启成功后完成应用的更新。

在本发明实施例一种可能的实现方式中，该终端90还用于从开始下载到更新结束的过程中，实时监控待更新终端的当前状态；根据当前状态，生成状态信息发送给服务器。

在本发明实施例一种可能的实现方式中，该终端90还用于从消息队列中接收服务器发送的回滚到上一版本的指示消息；其中，指示消息是由服务器在待更新终端利用更新数据重启应用失败时下发的；执行指示消息，并对待更新终端的当前状态进行监控；根据当前状态，生成状态消息发送给服务器。

需要说明的是，前述对终端的更新方法实施例的解释说明也适用于该实施例的终端，其实现原理类似，此处不再赘述。

本实施例的终端，通过从消息队列中接收服务器下发的更新消息，解析更新消息以获取下载地址，登录与下载地址匹配的下载服务器，并从中下载更新数据，在下载成功后利用更新数据对终端上的应用进行更新。通过由终端从下载服务器下载更新数据，并利用更新数据对终端上的应用进行更新，能够方便监控应用的更新状况，且无需重启系统即可实现应用更新，缩短了应用更新时长，减少了对其他硬件的损坏，解决了现有技术中需要重启系统才能完成更新导致的耗时长、损坏硬件的技术问题。

为了实现上述实施例，本发明还提出另一种服务器。

图11为本发明实施例所提供的另一种服务器的结构示意图。如图11所示，该服务器600包括：处理器601和存储器602；其中，处理器601通过读取存储器602中存储的可执行程序代码来运行与可执行程序代码对应的程序，以用于实现如前述实施例所述的由服务器侧执行的终端的更新方法。

为了实现上述实施例，本发明还提出另一种终端。

图12为本发明实施例所提供的另一种终端的结构示意图。如图12所示，该终端900包括：处理器901和存储器902；其中，处理器901通过读取存储器902中存储的可执行程序代码来运行与可执行程序代码对应的程序，以用于实现如前述实施例所述的由终端侧执行的终端的更新方法。

为了实现上述实施例，本发明还提出一种计算机程序产品，当所述计算机程序产品中的指令由处理器执行时实现如前述实施例所述的由服务器侧执行的终端的更新方法，或者实现如前述实施例所述的由终端侧执行的终端的更新方法。

为了实现上述实施例，本发明还提出一种非临时性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如前述实施例所述的由服务器侧执行的终端的更新方法，或者实现如前述实施例所述的由终端侧执行的终端的更新方法。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，“计算机可读介质”可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(ram)，只读存储器(rom)，可擦除可编辑只读存储器(eprom或闪速存储器)，光纤装置，以及便携式光盘只读存储器(cdrom)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(pga)，现场可编程门阵列(fpga)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本发明各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。