CN106789236A - 一种融合WiFiP2P的FOTA远程在线升级的方法 - Google Patents

Abstract

本发明公开了一种融合WiFi P2P的FOTA远程在线升级的方法，包括服务器，其特征在于，所述服务器连接Web后台、SQL和OSS，通过WLAN与策略分组的设备连接。本发明在充分结合现有的FOTA的技术的同时，创新性的将WiFi P2P（亦称WiFi Direct）技术，融合进来，充分发挥了当前的智能设备的潜力，为企业的设备维护节省了时间和成本，为客户提高效率的同时，降低了时间和费用成本，特别适合仓储，零售，物流等用户的移动终端FOTA管理。

Description

一种融合WiFiP2P的FOTA远程在线升级的方法

技术领域

本发明涉及FOTA远程在线升级系统更新方法，具体为一种融合WiFi P2P的FOTA远程在线升级的方法。

背景技术

近年，随着移动互联技术的快速发展，工业级的移动互联网设备也开始越发普及，在为各个行业带来信息化的同时，移动物联网设备本身的管理却成为一个越发重要的命题。当前对设备进行升级的主要都是通过FOTA（Firmware Over-The-Air）技术来实现，指通过云端升级技术，为具有连网功能的设备：例如手机、平板电脑、便携式媒体播放器和移动互联网设备等提供固件升级服务，用户使用网络以按需、易扩展的方式获取智能终端系统升级包，并通过FOTA进行云端升级，完成系统修复和优化。

传统FOTA只是强调“云-端”的数据升级，虽然解决了设备的升级问题，但在大规模的使用场景，尤其是对物流企业，不可避免的会造成流量和时间成本的浪费。典型的是Android系统升级，完整包达到GB的数据量即使是使用差分包，也达数十MB。FOTA是和OS紧密相连的，随着目前的智能系统愈发的庞大，以Android为例，一个完整的升级包动辄就500+MB，给用户增加了时间成本的同时，也增加了流量成本。

发明内容

本发明的目的在于提供一种融合WiFi P2P的FOTA远程在线升级的方法，具备提高效率，降低了时间和费用成本的优点，解决了流量和时间成本的浪费问题。

为实现上述目的，本发明提供如下技术方案：一种融合WiFi P2P的FOTA远程在线升级系统，包括服务器，所述服务器连接Web后台、SQL和OSS，通过WLAN与策略分组的设备连接,策略组的自动分配由ROM_UID决定，通过策略推送完成FOTA升级，其中每个策略组可以使用WiFi P2P进行离线升级。。

其方法步骤如下：

(1）、登陆服务器平台，按照ROM的设备信息在后台生成ROM_UID，将ROM_UID写入到制作的ROM中去；

（2）、上传测试通过后的ROM包至云服务器的OSS存储服务器，经过产品经理审核通过，并将相关更新信息推送到用户管理员；（3）、系统会根据客户设备的ROM_UID自动将设备分组，例如KM2Q803SS00CN010000000为组1，KM2Q803SS00CN020000002为组2，用户根据需要升级的情况，可以全选，也可以选择其中一部分设备作为升级对象，确定升级对象后，在可用的ROM列表中选择要升级的版本，确认更新后开始升级；

（4）、开始推送升级后，系统根据用户网络类型优选WLAN升级，根据用户的网段，同一个网段中，根据请求的先后，选取数台优先下载，其他设备处于任务等待状态；

（5）、当上述组中设备完成升级后，可以通过WiFi P2P将版本信息广播给组内的设备，其他设备可以通过其热点实现离线升级；

其上方法在使用时，包括开启工程模式和不开启工程模式；

当不开启工程模式时，

S1、当使用用户权限进行登陆，确定存在定制策略或私有策略后，从获取后台版本信息；

S2、确定附近存在共享者之后，打开WiFi Direct，使用WiFi P2P进行下载差分包并安装，若确定附近没有共享者或没有打开WiFi Direct，则自动从云端OSS服务器进行下载差分包或完整安装包；

S3、下载完成校验通过设备进入Recovery模式完成升级；

当开启工程模式时；

S4、当使用工程师权限进行登陆时，可直接获取后台版本信息，确认版本详细信息；

S5.当选择直接跳转安装，输入ROM_UID和ROM_VER ，然后下载完整安装包进行安装；

S6、当选择不跳转安装时，搜索附近存在共享者之后，若存在打开WiFi Direct，使用WiFi P2P进行下载差分包并安装，若确定附近没有共享者或没有打开WiFi Direct，则自动从云端OSS服务器进行下载差分包或完整安装包进行安装；

S7、下载完成校验通过设备进入Recovery模式并完成升级。

优选的，所述ROM_UID包含第一标识和第二标识，第一标识有硬件层面，硬件层面按方案商、硬件平台（MT6572、MT6582……）、存储芯片、内存芯片、屏幕、扩展板进行区分，软件层面主要包括默认语言、客户定制、定制版本标识信息。硬件配置完全相同的一款终端设备，由于销售渠道、区域、客户的不同，定制需求千变万化，ROM_UID具备区分并唯一标识这些不同的定制需求。

优选的，所述ROM_UID 包括方案商（1 byte）、硬件平台（2 byte）、存储Flash ROM（2 byte）、内存RAM（2 byte）、屏幕（2 byte）、扩展板（2 byte）、语言代码（2 byte）、预留（2byte）、客户代码（5 byte）、定制版本号（2 byte，自递增）。

优选的，其方法中，需要对ROM进行升级，其ROM升级流程MDM对于ROM的维护主要由管理员来完成，分为版本发布管理员和版本测试管理员，可以分成以下几个步骤：

（1）版本发布管理员通过客户的基础信息和客户的定制需求来确定是否需要生成一个新的OS链条[由ROM_UID标识]，如果是新的OS需求，则通过Web后台生成一个新的且唯一的ROM_UID，如果是迭代更新，则需要提供目前已经存在的且唯一的ROM_UID，将这个ROM_UID和准确的ROM_VER告知方案商，方案商在编译生成新的ROM时需要写入ROM_UID和ROM_VER。

（2）版本发布管理员在收到方案商提供的ROM之后，在经过初步测试之后，上传到后台服务器。文件上传完成之后，这个版本标记为测试版，并通知版本测试管理员测试审核。MDM客户端在默认的正常模式下是看不到测试版本的。

（3）版本测试管理员在终端设备通过登录到工程模式，然后MDM客户端根据相应的规则确定更新包，下载之后并予以更新OS。

（4）版本测试管理员测试OK之后，登录到后台管理系统予以确认版本为测试通过版本，此时版本的标记为发布版，对用户可见并可以提供下载。

与现有技术相比，本发明的有益效果如下：

1、本发明在充分结合现有的FOTA的技术的同时，创新性的将WiFi P2P（亦称Wi-FiDirect）技术，融合进来，充分发挥了当前的智能设备的潜力，为企业的设备维护节省了时间和成本，通过将同型号的设备进行了分组，系统分组后可以由用户根据实际情况进行分配，当用户开启WiFi P2P功能以后，组内有一台完成OS的更新之后，可以通过WiFi P2P将版本信息广播给组内的设备，其他设备可以通过其热点实现离线升级；

2、本发明利用ROM_UID和VER两套编码规则将硬件设备进行分门别类，为使用WiFi P2P建立基础，通过WiFi P2P技术实现FOTA的离线升级，为客户提高效率的同时，降低了时间和费用成本，特别适合仓储，零售，物流等用户的移动终端FOTA管理；

3、本发明特别为WiFi P2P技术在FOTA中的实现而专门设计的ROM_UID和Ver的编码规则和将FOTA和WiFi P2P结合的设计。

编码细则为了确保ROM_UID的唯一性和准确性，避免手工输入错误，或者空格导致不规范，还有输入法状态导致英文字母的半角和全角差异，新建ROM_UID时，其组成部分都必须通过下拉框的形式进行选择，而不能通过手工直接输入，保证ROM_UID的规范性。下拉框显示内容来自于数据库表，前端系统需要有维护页面给管理员进行增删改维护。需要维护包括方案商Vendor、硬件Platform、存储Flash ROM、内存RAM、屏幕、扩展板、语言代码、客户代码；

ROM_VER 版本号，自递增的正整数，用于区分相同ROM_UID的前后不同时间发布的版本。这个也是生成差分升级包、进行版本差异比较时参照的版本号。相同ROM_UID可以平顺升降级ROM_VER，不会出现因为硬件原因导致的故障，而强制更新ROM_UID不同ROM镜像，轻则系统显示不正确，严重的话则完全无法启动，需要返厂维修。当跨ROM_UID进行FOTA系统更新时，需要确保满足硬件层面信息一致的前提条件下，才可以通过强制跨ROM_UID进行FOTA在线更新。

附图说明

图1为本发明的ROM UID生成流程图和ROM UID资料管理示意图；

图2为本发明的融合WiFi Direct的FOTA在线升级流程图；

图3为本发明的完整包和差分包示意图；

图4为本发明的系统结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

请参阅图4，一种融合WiFi P2P的FOTA远程在线升级系统，包括服务器，服务器连接Web后台、SQL和OSS，服务器通过WLAN与组策特定设备信号连接，组策特定设备分别与组策设备和特定设备电连接。

请参阅图1-4，一种融合WiFi P2P的FOTA远程在线升级的方法，

其方法步骤如下：

(1）、登陆服务器平台，按照ROM的设备信息在后台生成ROM_UID，将ROM_UID写入到制作的ROM中去；

（2）、上传测试通过后的ROM包至云服务器的OSS存储服务器，经过产品经理审核通过，并将相关更新信息推送到用户管理员；（3）、系统会根据用户设备的ROM_UID自动将设备分组，例如KM2Q803SS00CN010000000为组1，KM2Q803SS00CN020000002为组2，用户根据需要升级的情况，可以全选，也可以选择其中一部分设备作为升级对象，确定升级对象后，在可用的ROM列表中选择要升级的版本，确认更新后开始升级；

（4）、开始推送升级后，系统根据用户网络类型优选WLAN升级，根据用户的网段，同一个网段中，根据请求的先后，选取数台优先下载，其他设备处于任务等待状态；

（5）、当上述组中设备完成升级后，可以通过WiFi P2P将版本信息广播给组内的设备，其他设备可以通过其热点实现离线升级；

其上方法在使用时，包括开启工程模式和不开启工程模式；

当不开启工程模式时，

S1、当使用用户权限进行登陆，确定存在定制策略或私有策略后，从获取后台版本信息；

S2、确定附近存在共享者之后，打开WiFi Direct，使用WiFi P2P进行下载差分包并安装，若确定附近没有共享者或没有打开WiFi Direct，则自动从云端OSS服务器进行下载差分包或完整安装包；

S3、下载完成校验通过设备进入重启进入Recovery模式完成升级；

当开启工程模式时；

S4、当使用工程师权限进行登陆时，可直接获取后台版本信息，确认版本详细信息；

S5.当选择直接跳转安装，输入ROM_UID和ROM_VER ，然后下载完整安装包进行安装；

S6、当选择不跳转安装时，搜索附近存在共享者之后，若存在打开WiFi Direct，使用WiFi P2P进行下载差分包并安装，若确定附近没有共享者或没有打开WiFi Direct，则自动从云端OSS服务器进行下载差分包或完整安装包进行安装；

S7、下载完成校验通过设备进入重启进入Recovery模式完成升级。

（1）融合软件、硬件、客户、需求的ROMUID编码系统

终端设备由于空间限制，ROM仅包含必要的驱动，而且还受硬件地址、存储分区等等器件的影响，所以不存在一个ROM适配多个硬件平台的情况。为了对ROM进行唯一标识，引入ROM_UID和ROM_VER进行区分。

1.1 ROM_UID包含两方面标识信息：

① 硬件层面：硬件层面按方案商、硬件平台（MT6572、MT6582……）、存储芯片、内存芯片、屏幕、扩展板进行区分。

② 软件层面：软件层面主要包括默认语言、客户定制、定制版本标识信息。硬件配置完全相同的一款终端设备，由于销售渠道、区域、客户的不同，定制需求千变万化， ROM_UID具备区分并唯一标识这些不同的定制需求。

1.2 ROM_VER 版本号，自递增的正整数，用于区分相同ROM_UID的前后不同时间发布的版本。这个也是生成差分升级包、进行版本差异比较时参照的版本号。相同ROM_UID可以平顺升降级ROM_VER，不会出现因为硬件原因导致的故障，而强制更新ROM_UID不同ROM镜像，轻则系统显示不正确，严重的话则完全无法启动，需要返厂维修。当跨ROM_UID进行FOTA系统更新时，需要确保满足硬件层面信息一致的前提条件下，才可以通过强制跨ROM_UID进行FOTA在线更新，例如，某台刷了客户定制版OS的终端设备可以改刷为通用版的OS。

1.3编码细则为了确保ROM_UID的唯一性和准确性，避免手工输入错误，或者空格导致不规范，还有输入法状态导致英文字母的半角和全角差异，新建ROM_UID时，其组成部分都必须通过下拉框的形式进行选择，而不能通过手工直接输入，保证ROM_UID的规范性。下拉框显示内容来自于数据库表，前端系统需要有维护页面给管理员进行增删改维护。需要维护包括方案商Vendor、硬件Platform、存储Flash ROM、内存RAM、屏幕、扩展板、语言代码、客户代码。

ROM_UID = 方案商（1 byte） + 硬件平台（2 byte） + 存储Flash ROM（2 byte） +内存RAM（2 byte） + 屏幕（2 byte） + 扩展板（2 byte） + 语言代码（2 byte） + 预留（2byte） + 客户代码（5 byte） + 定制版本号（2 byte，自递增）。

(1)方案商：编号代码(1个字符)、显示方案商名称；

(2)硬件平台：编号代码(2个字符)、硬件平台名称(譬如MT6572)、注释；

(3)存储：编号代码(2个字符)、芯片型号、总容量、备注；

(4)内存：编号代码(2个字符)、芯片型号、总容量、备注；

(5)屏幕：编号代码(2个字符)、屏幕供应商名称(如信利、BCT)、BOM表器件编码、备注；

(6)扩展板：编号代码(2个字符)、显示名称、备注；

(7)语言代码：编号代码(2个字符)、显示名称；编号代码可参考这个页面https://www.iso.org/obp/ui/#search的定义，譬如代码编码CN，显示名称为“简体中文(中国大陆)”，代码编码TW，显示名称为“繁体中文”，代码编码JP，显示名称为“日文”，代码编码EN，显示名称为“英文(英国)”，代码编码US，显示名称为“英文(美国)”，等等。

（8）客户代码：编码代码（5个字符）、显示名称、备注。其中编码代码00000为内置，表示通用标准版，非客户定制版本。

总之，新增ROM_UID由管理员Admin负责，提交后台系统保存到数据库之后不允许修改，也不允许删除。删除ROM_UID可能导致很多同步、FOTA在线更新出现问题，所以必须由SysAdmin进行谨慎操作。每个ROM_UID都必须进行填写“备注”进行注释，方便后续维护管理.

1.4 ROM_VER同ROM_UID不同的是，ROM_VER由MDM后台自动维护，在ROM_UID相同的情况下，每在相同的ROM_UID相同的链条上添加新的OS，其ROM_VER均需要在自身的值的基础上加1.

1.5 ROM升级流程MDM对于ROM的维护主要由管理员来完成，分为版本发布管理员和版本测试管理员，可以分成以下几个步骤：

（1） 版本发布管理员通过客户的基础信息和客户的定制需求来确定是否需要生成一个新的OS链条[由ROM_UID标识]，如果是新的OS需求，则通过Web后台生成一个新的且唯一的ROM_UID，如果是迭代更新，则需要提供目前已经存在的且唯一的ROM_UID，将这个ROM_UID和准确的ROM_VER告知方案商，方案商在编译生成新的ROM时需要写入ROM_UID和ROM_VER。

（2） 版本发布管理员在收到方案商提供的ROM之后，在经过初步测试之后，上传到后台服务器。文件上传完成之后，这个版本标记为测试版，并通知版本测试管理员测试审核。MDM客户端在默认的正常模式下是看不到测试版本的。

（3） 版本测试管理员在终端设备通过登录到工程模式，然后MDM客户端根据相应的规则确定更新包，下载之后并予以更新OS。

（4） 版本测试管理员测试OK之后，登录到后台管理系统予以确认版本为测试通过版本，此时版本的标记为发布版，对用户可见并可以提供下载。

方案商制作ROM时，都会提供一个完整更新镜像（简称完整包）和一个与上一版本的差分更新镜像（简称差分包），发布第一版ROM时，只有完整包F_v1，第二次发布ROM时，提供完整包F_v2和版本2与版本1的差分包P_v2_1，第三次发布ROM时，提供完整包F_v3和版本3与版本2的差分包P_v3_2，如此类推，最新版本号为k时，提供完整包F_vk和差分包P_vk_k-1.

请参阅图3，当客户端从后台系统检测到可更新的OS版本升级时，假设终端设备OS当前版本号ROM_VER为1，后台系统该ROM_UID的OS最新版本号ROM_VER是3时，终端设备的升级方法为：下载P_v2_1差分包，重启到Recovery模式执行OS升级，升级完毕自动重启到正常模式，终端设备OS版本号ROM_VER更新为v2；继续下载P_v3_2差分包，重启到Recovery模式执行OS升级，升级完毕自动重启到正常模式，终端设备OS版本号ROM_VER更新为v3。由此可见，终端设备当前OS版本号ROM_VER与后台系统最新版本号ROM_VER相差N个时，需要重复下载并重启N-1次循环才能完成更新到最新版本，这会造成极差的客户体验，所以，采用差分升级实施系统更新需要进行限制，限制规则如下：

当后台系统当前OS最新版本号ROM_VER与当前终端设备OS版本号ROM_VER相差不超过3个（包括3个）；

需要下载更新的差分包所有文件累计大小不得超过最新版完整包文件大小的70%；

只有满足上述前提条件才通过下载差分包的方式实施OS更新，否则都通过直接下载最新版本的完整包实施OS更新。另外，上述条件两个变量 —— 差分更新的版本差阀值3、下载百分比阀值70%为默认设置，可通过后台系统修改设置

尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。

Claims (4)

1.一种融合WiFi P2P的FOTA远程在线升级的方法，包括服务器，其特征在于，所述服务器连接Web后台、SQL和OSS，通过WLAN与策略分组的设备连接，策略组的自动分配由ROM_UID决定，通过策略推送完成FOTA升级，其中每个策略组可以使用WiFi P2P进行离线升级;

其方法步骤如下：

（1）、登陆服务器平台，按照ROM的设备信息在后台生成ROM_UID，将ROM_UID写入到制作的ROM中去；

（2）、上传测试通过后的ROM包至云服务器的OSS存储服务器，经过产品经理审核通过，并将相关更新信息推送到用户管理员；（3）、系统会根据客户设备的ROM_UID自动将设备分组，例如KM2Q803SS00CN010000000为组1，KM2Q803SS00CN020000002为组2，用户根据需要升级的情况，可以全选，也可以选择其中一部分设备作为升级对象，确定升级对象后，在可用的ROM列表中选择要升级的版本，确认更新后开始升级；

（4）、开始推送升级后，系统根据用户网络类型优选WLAN升级，根据用户的网段，同一个网段中，根据请求的先后，根据用户终端基数智能选取数台优先下载，其他设备处于任务等待状态；

（5）、当上述组中设备完成升级后，可以通过WiFi P2P将版本信息广播给组内的设备，其他设备可以通过其热点实现离线升级；

其上方法在使用时，包括开启工程模式和不开启工程模式；

当不开启工程模式时，

S1、当使用用户权限进行登陆，确定存在定制策略或私有策略后，获取后台版本信息；

S2、确定附近存在共享者之后，打开WiFi Direct，使用WiFi P2P进行下载差分包并安装，若确定附近没有共享者或没有打开WiFi Direct，自动从云端OSS服务器进行下载差分包或完整安装包；

S3、下载完成校验通过设备进入Recovery模式完成升级；

当开启工程模式时；

S4、当使用工程师权限进行登陆时，可直接获取后台版本信息，确认版本详细信息；

S5.当选择直接跳转安装，输入ROM_UID和ROM_VER ，然后下载完整安装包进行安装；

S6、当选择不跳转安装时，搜索附近存在共享者之后，若存在打开WiFi Direct，使用WiFi P2P进行下载差分包并安装，若确定附近没有共享者或没有打开WiFi Direct，则自动从云端OSS服务器进行下载差分包或完整安装包进行安装；

S7、下载完成校验通过后，设备进入Recovery模式完成升级。

2.根据权利要求1所述的一种融合WiFi P2P的FOTA远程在线升级的方法，其特征在于：所述ROM_UID包含第一标识和第二标识，第一标识有硬件层面，硬件层面按方案商、硬件平台（MT6572、MT6582……）、存储芯片、内存芯片、屏幕、扩展板进行区分，软件层面主要包括默认语言、客户定制、定制版本标识信息;

硬件配置完全相同的一款终端设备，由于销售渠道、区域、客户的不同，定制需求千变万化，ROM_UID具备区分并唯一标识这些不同的定制需求。

3. 根据权利要求1所述的一种融合WiFi P2P的FOTA远程在线升级的方法，其特征在于：所述ROM_UID 包括方案商（1 byte）、硬件平台（2 byte）、存储Flash ROM（2 byte）、内存RAM（2 byte）、屏幕（2 byte）、扩展板（2 byte）、语言代码（2 byte）、预留（2 byte）、客户代码（5 byte）、定制版本号（2 byte，自递增）。

4. 根据权利要求1所述的一种融合WiFi P2P的FOTA远程在线升级的方法，其特征在于：其方法中，需要对ROM进行升级，其ROM升级流程MDM对于ROM的维护主要由管理员来完成，分为版本发布管理员和版本测试管理员，可以分成以下几个步骤：

（1）版本发布管理员通过客户的基础信息和客户的定制需求来确定是否需要生成一个新的OS链条[由ROM_UID标识]，如果是新的OS需求，则通过Web后台生成一个新的且唯一的ROM_UID，如果是迭代更新，则需要提供目前已经存在的且唯一的ROM_UID，将这个ROM_UID和准确的ROM_VER告知方案商，方案商在编译生成新的ROM时需要写入ROM_UID和ROM_VER;

（2）版本发布管理员在收到方案商提供的ROM之后，在经过初步测试之后，上传到OSS服务器，文件上传完成之后，这个版本标记为测试版，并通知版本测试管理员测试审核，MDM客户端在默认的正常模式下是看不到测试版本的;

（3）版本测试管理员在终端设备通过登录到工程模式， MDM客户端根据相应的规则确定更新包，下载之后并予以更新OS;

（4）版本测试管理员测试OK之后，登录到后台管理系统予以确认版本为测试通过版本，此时版本的标记为发布版，对用户可见并可以提供下载。