名称：
软件更新方法、系统及设备
摘要：
公开了软件更新方法、设备及系统。软件更新方法包括：客户端向其他客户端发送本地更新软件广播信息；判断是否收到更新软件存在的应答，若是，则通过发送所述应答的客户端更新本地软件，若否，则通过远端服务器更新本地软件。本发明可以解决软件更新过程中传输速度受到OTA服务器的制约及传输数据中拥堵的问题，从而提高了下载速度，因此可以同时为大量的设备更新软件，避免了服务器因大量的设备需求导致拥塞或者瘫痪的可能性。
权利要求：
软件更新方法、 系统及设备 技术领域
本发明涉及数据传输领域， 特别涉及软件更新的方法、 系统及设备。 背景技术
随着电子和通信技术的发展， 越来越多的电子设备应用到日常生活中的 各个方面。 目前， 这些电子设备的硬软件更新过程中不能实现兼容， 而给使 用者带来不便。 为解决这一问题， 已经提出了可重构设备 （ Reconfigurable Devices) 技术。 在实现可重构设备技术的过程中， 在对硬件进行改进的基础 上也必须得到软件的支持。 可支持可重构设备的硬件包括 FPGA 或者 rDPA 处理器。 这些处理器可以通过编程来调节其功能。
软件重构是有效实现硬件多种功能的方法。 常用的操作方式是将编写好 的软件放到一个服务器上， 然后可重构设备从服务器下载并更新。 下载可以 通过有线和无线两种方式。 由于智能手机的普遍应用， 通过空中下载 (Over-The-Air: OTA)成了主要的方式。 由于空中下载有很多益处， 因此世界 上几个主要的机构形成了一个工作组叫做 Open Mobile Alliance (OMA) 来制 定空中下载的技术标准。其制定的标准 OMA DM (Device Management)被 IBM 微软和 Motive以及其它大的厂商采用。 据统计新近发行的移动设备中， 80。 的固件可以重构。 OMA DM不仅可以用来下载、 更新软件和修正软件中的错 误， 还可以用于车辆的管理， 监控设备的信号和质量控制。 近几年来， 人们 还做了 大量的工作来提高 OMA DM 的性能， 如设计新的管理代理 (management agent)等。所有的这些方法都是基于传统的客户/服务器模式。 这种模式不适合为大量的设备同时提供下载和更新。
国内相关 OTA的专利主要集中在四个方面， 即 OTA技术的新方法， OTA 实现的新方法， OTA的应用以及有关 OTA的测试。
在专利文献 CN101247416中公布了固件下载方法"基于 OTA的固件下载 方法、 预处理方法、 完整性验证方法"。 该专利文献提出的是固件下载的预处 理方法、 固件完整性验证方法、 以及固件下载方法， 但还是基于传统的客户
/服务器模式。
在专利文献 CN102625288A"多处理器终端空中下载的方法及多处理器终 端"中公开了多处理器终端空中下载的方法及多处理器终端。 所述多处理器终 端包括应用处理器 AP、 通信处理器 CP和通用集成电路卡 UICC。 其中 AP承 担了 UICC和 OTA服务器的中继站。 当 UICC向空中下载 OTA服务器发起数 据下载请求时， 将所述数据下载请求发送给 AP; AP 收到所述数据下载请求 后， 将所述数据下载请求发送至所述 OTA服务器； AP接收到 OTA服务器响 应所述数据下载请求而发送的响应数据， 并将所述响应数据发送至 UICC , 以 实现数据下载。 该文献通过 AP进行 OTA服务器与 UICC之间的数据交互， 提高了下载速度。 该方案突破了传统的客户/服务器模式， 提高了 OTA下载 的 OTA 下载方法， 都还是直接或者间接的从 OTA服务器上下载软件， 因此 对 OTA服务器提出了很高的要求， 其性能和处理及数据传输速度将直接影响 到各个客户端的使用， 在客户端数量级高及待处理数据容量大的情况下， 将 不能满足客户的使用需求。 发明内容
本发明人注意到， 上述现有技术中， 由于现有的数据及软件更新方法都 是通过与 OTA服务器进行数据交互实现的， 因此， 在服务终端数量众多且传 输数据量大， 客户请求密集的情况下， 难以满足各个服务终端客户的需要。 同时， 在网络中大量相同数据的发送， 也造成了系统中数据传输资源的浪费， 提高了使用成本。
因此， 本发明的目的之一是解决软件更新过程中传输速度受到 OTA服务 器的制约及传输数据中拥塞的问题。
为此， 本发明的一方面提供了软件更新方法， 包括以下步骤： 向多个客 户端发送本地更新软件广播信息； 判断是否有客户端发出应答信息， 所述应 答信息包括存在更新软件的信息， 若是， 则通过发送所述应答的客户端更新 其它客户端本地软件， 若否， 则通过远端服务器更新本地软件。
在一些实施方式中， 在客户端设置 DL代理和 CIC (中央信息控制器） 模 块。 当某个客户端要更新本地软件时， 其 DL代理向 CIC模块发送请求； CIC 模块配置为发送本地更新软件广播信息， 并注册和管理发出应答信息的客户 端信息， 确定下载更新软件的方式， 由 DL代理根据 CIC模块确定的方式， 与客户端或服务器连接进行软件下载和更新。
本发明的另一方面还提供了软件更新系统， 包括广播发送单元及更新单 元， 其中， 所述广播发送单元配置为向多个客户端发送本地更新软件广播信 息；所述更新单元配置为判断是否有客户端发出更新软件存在的应答，若是， 则通过发送所述应答的客户端更新本地软件， 若否， 则通过远端服务器更新 本地软件。
本发明又一方面还提供了软件更新设备， 包括： 发送模块和更新模块， 其中， 所述发送模块配置为向其他客户端发送本地更新软件广播信息； 所述 更新模块配置为判断是否收到更新软件存在的应答， 若是， 则通过发送所述 应答的客户端更新本地软件， 若否， 则通过远端服务器更新本地软件。
本发明的上述实施方式具有以下优点： 通过在一定的区域范围内， 使客 户终端通过相互交流确认所储存软件的信息。 如果某一客户端储存其它客户 端所需要的软件， 则从该客户端下载。 否则从 OTA服务器下载。 利用这种分 散式的下载方式能让设备既能够从服务器下载， 也可以从相邻节点下载。 从 而提高了下载速度， 因此可以同时为大量的设备更新软件， 还避免了服务器 因大量的设备需求导致拥塞或者瘫痪的可能性。
本领域技术人员可以理解， 本发明的方法虽然描述为以软件更新为对象， 但实际上还可用于下载安装本机没有的新软件。 因此， 在本申请中所述的"软 件更新" 既包括了"更新旧软件"， 也包括了"下载新的软件"。 附图说明 以下结合附图详细说明本发明实施方式。 这些附图仅仅是用于描述本发 明的一些具体实施例以利于对本发明的精神和构思以及保护范围的理解， 而 非对本发明的限定。 其中：
图 1 为本发明一实施方式的软件更新方法的流程图；
图 2 为本发明一实施方式的分散式下载的示意图；
图 3 为本发明一实施方式的客户端设备中代理的编程设计层级示意图； 图 4 为本发明一实施方式的 FUMO代理模块的设计示意图；
图 5 为本发明一实施方式的 DL Agent代理模块的设计示意图；
图 6 为本发明一实施方式的 CIC的设计模块示意图；
图 7 为本发明一实施方式的软件更新系统的结构示意图；
图 8 为本发明一实施方式的软件更新设备的结构示意图。 具体实施方式
下面结合附图和实施例， 对本发明的具体实施方式作详细描述。
图 1 所示为本发明一实施方式的软件更新方法的流程示意图。 该软件更 新方法包括以下步骤：
步骤 S101 : 发送要更新软件的广播信息。 在该步骤中， 客户端的 CIC向 临近的多个客户端发送本身需要更新的软件广播信息。 该广播信息包括软件 名称和软件版本信息等。
步骤 S102 : 进行本地软件的更新。 临近的客户端 CIC在收到该 CIC广播 信息后， 立即应答。 发出广播信息的客户端 CIC从收到的应答信息中寻找哪 个客户端设备储存有所需要的软件， 并注册该设备的 ID , 以获得该设备所带 有软件的信息， 并通过该 ID和该设备交流。 随后向该设备发出下载软件的请 求， 并在设备确认下载请求后直接下载。 如果所收到的应答信息中没有包含 所需要更新的软件， 那么发出广播信息的客户端直接联系 OTA服务器， 将按 照传统的方法从服务器上下载更新软件。 作为一种实施方式， 在步骤 S102中， 通过发送应答的客户端更新本地软 件的步骤可包括： 将发送应答的客户端地址注册到本地客户端软件读取列表 中； 根据本地客户端软件读取列表更新本地软件。
在一实施方式中， 通过发送应答的客户端更新本地软件的步骤还包括： 判断发送所述应答客户端的数量是否为多个。 若有多个， 则根据多个应答客 户端的忙碌度确定空闲的应答客户端， 并通过空闲的应答客户端来更新本地 软件； 若只有一个， 则通过发送应答的客户端更新本地软件。
上述根据多个应答客户端的忙碌度确定空闲应答客户端的步骤可包括： 通过测量数据流量和节点的容量获取多个应答客户端中的最高数据交换速度 将所述最高数据交换速度对应的应答客户端确定为空闲应答客户端。 从而， 在发送存在更新软件的应答的客户端数量为多个时， 可根据应答客户端的忙 碌度选择要下载的客户端， 优化了客户端间的负载均衡性。
在本实施方式中， 结合了传统的客户/服务器模式和提出的分散式模式 两种下载方式。 本实施方式中下载方法如图 2 所示。 在客户设备中设置一个 新的模块， 称之为 DL代理。 DL代理、 DM代理和 FUMO代理几个模块在客 户设备中共存。 可以根据实际情况， 智能地选取下载方式。
在 DL代理中， 设置一个 CIC(Central Information Controller： 中央信息控 制器)模块。 该模块通过和其它客户设备中的 CIC模块交流来实现客户设备间 软件的下载。 CIC 模块记录设备中软件的信息， 发布信息到其它的客户设备 并且管理软件下载。
当一个客户设备要更新软件时， 首先以广播消息的方式向区域网络内其 它设备的 CIC模块发出请求。 如果某一个设备的 CIC模块中存在所需求的软 件， 那么发出请求的这个设备就会和存在该软件的设备建立联系并从后者下 载所需软件。 如果区域网络中的客户端都没有所需要的软件， 那么该设备就 和服务器相连接并从服务器下载软件。 这里， 客户端下载软件与从服务器下 载软件的方式都是常规的手段， 不再赘述。
如果一个设备离开某区域（例如通过与该设备的无线连接的断开来判定） 那么这个设备所带有相关软件的信息将从其它设备的 CIC模块中删除。 以下具体说明在客户端设备中代理的实现方式。 从编程的角度来看， 客 户端的逻辑设计分为四个层次。 如图 3所示， 从顶到底， 分别为应用层， DM 核心层， 硬件抽象层和操作系统。
本发明的主要部分都在应用层和 DM核心层实现， 如下所述。 硬件和操 作系统只是基础。 以手机为例， 手机的硬件及 Android系统、 iOS等为其中运 行的应用软件提供了操作环境。 虽然对每个系统下所做的软件开发不同， 但 是对方法本身没有影响。 也就是说， 本领域技术人员对于此处描述的本发明 的方法，可以利用常规的手段在不同的硬件和操作系统上相应地实现。 因此， 本说明书中对硬件抽象层和操作系统这两部分不再说明。
其中， 应用层直接处理软件更新时的管理操作。 从 DM核心层接收操作 指令并实现所指定的管理操作， 如软件下载、 更新等。 此外， 它还向 DM核 心层发回操作的结果以进行进一步的处理。 然后， 其结果可以被发送回服务 器端。 FUMO (Firmware Update Management Object: 固件更新管理对象） 代 理和 DL代理都在应用层。
其中， FUMO代理是 OMA DM中固件下载和更新的核心模块， 是已经标 准 化 的 固 有 模 块 。 FUMO 代 理 主 要 由 两 个 包 构 成 ， 即 dm. client. downloadmanager和 dm.client.updatemanager0
dm.client.downloadmanager负责处理由 DM核心层解析来的软件更新并且 和 DL代理一起管理软件的下载。 当采用传统的客户/服务器下载方式时， 它 也负责软件下载。 dm. client.updatemanager主要负责软件的更新。 图 4显示了 这两个包的详细设计。 它们是常规的设计， 因此不再赘述。
DL代理是本发明中提出的软件下载机制。 和 FUMO代理协同工作， 在 不同的情况下实现软件的下载。 DL代理在这里起着管理员的作用， 负责联系 协调调度各个模块， 包括系统中原有的下载管理模块。 它根据 CIC 中的信息 来确定以何种方法下载软件。 因此， DL代理具有和 CIC通信的能力， 以获取 相关的软件信息。 另外， 它也可以从邻近的客户端上下载软件。 DL代理是由 一个包来实现的,称之为 dm.client.dlagent。 dm.client.dlagent由五个代表不同 功能的类组成。 DlManager类是 DL代理的主要部分， 它负责管理其它类的操作并且通知
FUMO代理采用下载的方法。
RspforSwRQ类用来从 CIC中获取软件的信息。
DlMethodDecider根据 CIC中所获取的信息来决定哪种下载方法。
Communication类负责实现 DL代理和其它设备的通信。
decentralizedDownloader类负责分散下载 （即从其它客户端下载） 时软件 的下载。
各个类的详细设计图如图 5 所示。 CIC是决定下载方法的控制中心。 从 编写代码的角度来看，它由 5个类组成，以实现五个不同的功能，即 Broadcast (广播) , Register (注册) , DeviceManager (设备管理) , SoftwareManager (软 件管理) 和 Communication (通信)。 详细设计如图 6所示。
其中， Broadcast使用 Req4SW向它相邻的客户端广播所请求的软件。 如 果相邻的客户端设备有这个软件的话， 将利用 Req4Register把设备和软件的 信息返回到 CIC中。 CIC将利用 Register模块中的 AddDev功能注册该设备。 注册完成后， CIC将用 DeviceManager和 SoftwareManager来管理特定的设 备和软件。 例如以软件管理为例， 该管理包括注册、 取消软件信息、 获取软 件的名称和获取软件等。
当某一设备要更新软件时， 将利用 Communication向 CIC模块发出请求 信息。 如果 CIC模块响应该请求而在 Register中找到与该更新软件相关的信 息 （如名称和版本号）， 那么就通知发出请求的设备， 该发出请求的设备和拥 有要更新的软件的设备直接连接， 并通过 DL代理下载和更新软件。如果 CIC 中没有相关的信息， 那么发出请求的设备就与内容服务器进行通信， 采用传 统的 OMA DM下载方法通过 FUMO代理下载和更新软件。
图 7 所示为本发明一实施方式的软件更新系统的结构示意图。 该软件更 新系统包括广播发送单元 201及更新单元 202。 其中， 广播发送单元 201用于 向其他客户端发送本地更新软件广播信息； 更新单元 202 用于判断是否收到 更新软件存在的应答，若收到应答，则通过发送应答的客户端更新本地软件； 若未收到应答， 则通过远端服务器更新本地软件。 同时， 更新单元 202 还用于将应答的客户端地址注册到本地客户端软件 读取列表中； 根据所述本地客户端软件读取列表更新本地软件。
当应答客户端数量为多个时， 所述更新单元 202 还用于判断所述应答客 户端的数量是否为多个。 若有多个， 则根据多个应答客户端的忙碌度确定空 闲应答客户端， 通过所述空闲应答客户端更新本地软件， 若否， 则通过发送 所述应答的客户端更新本地软件。 其中获取多个应答客户端中的最高数据交 换速度， 将所述最高数据交换速度对应的应答客户端确定为空闲应答客户端。
图 8 所示为本发明一实施方式的软件更新设备结构示意图。 该软件更新 设备包括发送模块 301和更新模块 302。 其中，
发送模块 301用于向其他客户端发送本地更新软件广播信息；
更新模块 302判断是否收到更新软件存在的应答， 若是， 则通过发送所 述应答的客户端更新本地软件， 若否， 则通过远端服务器更新本地软件。
更新模块 302还包括： 注册模块 3021及通讯下载模块 3022 , 其中， 注册模块 3021将所述应答的客户端地址注册到本地客户端软件读取列表 中；
通讯下载模块 3022根据所述本地客户端软件读取列表， 更新本地软件。 在此设备中还可包括： 设备管理模块 303、 软件管理模块 304。 设备管理 模块 303生成所述应答客户端的设备信息。 软件管理模块 304生成更新软件 的名称、 版本及容量信息。
该设备的工作方式如前文关于软件更新方法的实施方式中所述。 在此不 再赘述。
以上公开的仅为本发明的几个具体实施例，但是，本发明并非局限于此， 任何本领域技术人员能够根据这些公开内容想到的变化都属于本发明的范畴 并落入所附权利要求书限定的保护范围。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
