OTA升级系统的制作方法

ota升级系统
技术领域
1.本发明涉及程序升级领域，特别是涉及一种ota升级系统。


背景技术：

2.现有的具备从属设备的智能机器人，其ota方式一般多采用全量升级的方式，即无论升级包的大小，直接全部下载到机器人中，机器人根据自身的版本判断，进行选择性升级(或者干脆全部替换掉，忽略版本号)，这样会导致几个问题：
3.1.下载冗余的程序，导致下载流程增加，进而导致了流程成本提升。
4.2.全量安装，降低了安装速度，且存在较大的失败风险，导致产品变砖。
5.3.从属设备与主设备没有形成良好的组网关系，往往各自为政，每个都是一个单独的主设备分别进行升级，这大大增加了升级失败的风险。
6.4.有些增量升级的设备，并没有考虑到兼容性问题，导致前面出货的机器人，由于长时间未使用或未升级，后续多个项目版本无法兼容工作。


技术实现要素：

7.鉴于以上所述现有技术的缺点，本发明的目的在于提供一种ota升级系统，用于解决现有技术中以上技术问题。
8.为实现上述目的及其他相关目的，本发明提供一种ota升级系统，所述系统包括：app端、第一服务器端、第二服务器端以及设备端；其中，所述app端，与所述第一服务器端以及第二服务器端建立通信连接，用于从所述第一服务器端获取所述设备端的设备版本信息，并判断所述设备端是否需要升级，并在需要升级且确定升级的情况下通过所述第二服务器端向所述设备端下发对应的ota升级信息；其中，所述设备版本信息包括：最新版本号、当前版本号以及升级包下载信息；所述ota升级信息包括：所述最新版本号以及升级包下载信息；所述设备端，与所述第一服务器端以及第二服务器端建立通信连接，用于接收由所述app端通过第二服务器端发送的ota升级信息，并在判断可升级时基于所述升级包下载信息从所述第一服务器端下载对应的ota升级包；对所述ota升级包进行内部处理以及升级安装，并将升级进度以及下载进度实时通过所述第二服务器端反馈给所述app端，以供所述app端进行显示；其中，所述升级安装的方式包括：对应从所述第一服务器端下载的增量ota升级包的增量升级安装或对应从所述第一服务器端下载的强制中间版本升级包的强制升级安装。
9.于本发明的一实施例中，所述设备端包括：一主设备端以及至少一从设备端。
10.于本发明的一实施例中，用于将接收由所述app端通过第二服务器端发送的ota升级信息；判断所述设备端可升级时，基于所述升级包下载信息从所述第一服务器端下载对应的ota升级包；对所述ota升级包进行内部处理；在当所述主设备端需要升级时，基于经过内部处理的ota升级包进行升级安装，并将对应的升级进度以及下载进度实时储存；在当从设备端需要升级时，则将经过内部处理的ota升级包发送至对应的从设备端；所述从设备
端，用于当接收到经过内部处理的ota升级包时，进行升级安装，并将对应的升级进度以及下载进度实时发送至所述主设备端；所述主设备端用于总结升级的主设备端以及从设备端的升级进度以及下载进度，并将总结的升级进度、下载进度以及升级结果通过所述第二服务器端反馈给所述app端，以供所述app端显示。
11.于本发明的一实施例中，所述在当从设备端需要升级时，则将经过内部处理的ota升级包发送至对应的从设备端包括：在当从设备端需要升级时，则将经过内部处理的ota升级包通过4g或wifi通信方式发送至所述第二服务器端，以供通过所述第二服务器端发送内部处理的ota升级包至对应的从设备端；或者，在当从设备端需要升级时，则将经过内部处理的ota升级包通过bt或zigbee通信方式发送至对应的从设备端。
12.于本发明的一实施例中，所述主设备端用于在需要升级时接收由所述app端通过第二服务器端发送的ota升级信息；判断所述设备端可升级时，基于所述升级包下载信息从所述第一服务器端下载对应的ota升级包；对所述ota升级包进行内部处理以及以及升级安装，并将升级进度以及下载进度通过所述第二服务器端实时反馈给所述app端，以供所述app端进行显示；所述从设备端用于在需要升级时接收由所述app端通过第二服务器端发送的ota升级信息；判断所述设备端可升级时，基于所述升级包下载信息从所述第一服务器端下载对应的ota升级包；对所述ota升级包进行内部处理以及以及升级安装，并将升级进度以及下载进度通过所述第二服务器端实时反馈给所述app端，以供所述app端进行显示。
13.于本发明的一实施例中，所述对所述ota升级包进行内部处理的方式包括：验证上所述ota升级包的完整性以及对所述ota升级包进行解压。
14.于本发明的一实施例中，若所述设备端的当前版本号的版本与所述最新版本号的版本不兼容，所述app端从所述第一服务器端获取所述设备端的包含由强制中间版本作为最新版本所对应的最新版本号、当前版本号以及对应所述强制中间版本的强制中间版本升级包的升级包下载信息，以供所述设备端基于所述升级包下载信息从所述第一服务器端下载对应的强制中间版本升级包并进行强制升级安装使所述设备端的当前版本号的版本与最新版本号的版本兼容；当强制升级安装完毕后，所述app端从所述第一服务器端获取所述设备端的最新版本号、当前版本号以及对应最新版本的增量ota升级包的升级包下载信息，以供所述设备端基于所述升级包下载信息从所述第一服务器端下载对应的增量ota升级包并进行增量升级安装。
15.于本发明的一实施例中，若所述设备端的当前版本号的版本与所述最新版本号的版本兼容，所述app端从所述第一服务器端获取所述设备端的最新版本号、当前版本号以及对应最新版本的增量ota升级包的升级包下载信息，以供所述设备端基于所述升级包下载信息从所述第一服务器端下载对应的增量ota升级包并进行增量升级安装。
16.于本发明的一实施例中，所述第二服务器端包括：mqtt服务器端或bt服务器端。
17.于本发明的一实施例中，所述升级包下载信息包括：升级包url地址以及md5值。
18.如上所述，本发明是一种ota升级系统，具有以下有益效果：本发明通过app端、第一服务器端、第二服务器端以及设备端之间的通信，打造一个轻量的且具备低版本兼容的升级方式，可最大限度的保证机器人的安全性、兼容性和扩展性。
附图说明
19.图1显示为本发明一实施例中的ota升级系统的结构示意图。
20.图2显示为本发明一实施例中的ota升级系统的结构示意图。
21.图3显示为本发明一实施例中的ota升级系统的结构示意图。
22.图4显示为本发明一实施例中的ota升级系统的结构示意图。
23.图5显示为本发明一实施例中的ota升级系统的结构示意图。
24.图6显示为本发明一实施例中的版本升级示意图。
25.图7显示为本发明一实施例中的ota升级系统的结构示意图。
具体实施方式
26.以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。
27.需要说明的是，在下述描述中，参考附图，附图描述了本发明的若干实施例。应当理解，还可使用其他实施例，并且可以在不背离本发明的精神和范围的情况下进行机械组成、结构、电气以及操作上的改变。下面的详细描述不应该被认为是限制性的，并且本发明的实施例的范围仅由公布的专利的权利要求书所限定。这里使用的术语仅是为了描述特定实施例，而并非旨在限制本发明。空间相关的术语，例如“上”、“下”、“左”、“右”、“下面”、“下方”、
““
下部”、“上方”、“上部”等，可在文中使用以便于说明图中所示的一个元件或特征与另一元件或特征的关系。
28.在通篇说明书中，当说某部分与另一部分“连接”时，这不仅包括“直接连接”的情形，也包括在其中间把其它元件置于其间而“间接连接”的情形。另外，当说某种部分“包括”某种构成要素时，只要没有特别相反的记载，则并非将其它构成要素，排除在外，而是意味着可以还包括其它构成要素。
29.其中提到的第一、第二及第三等术语是为了说明多样的部分、成分、区域、层及/或段而使用的，但并非限定于此。这些术语只用于把某部分、成分、区域、层或段区别于其它部分、成分、区域、层或段。因此，以下叙述的第一部分、成分、区域、层或段在不超出本发明范围的范围内，可以言及到第二部分、成分、区域、层或段。
30.再者，如同在本文中所使用的，单数形式“一”、“一个”和“该”旨在也包括复数形式，除非上下文中有相反的指示。应当进一步理解，术语“包含”、“包括”表明存在所述的特征、操作、元件、组件、项目、种类、和/或组，但不排除一个或多个其他特征、操作、元件、组件、项目、种类、和/或组的存在、出现或添加。此处使用的术语“或”和“和/或”被解释为包括性的，或意味着任一个或任何组合。因此，“a、b或c”或者“a、b和/或c”意味着“以下任一个：a；b；c；a和b；a和c；b和c；a、b和c”。仅当元件、功能或操作的组合在某些方式下内在地互相排斥时，才会出现该定义的例外。
31.本发明主要是为了解决当前智能机器人ota过程中，存在的诸多缺陷，从降本(降低流量，降低下载时间，降低安装时间)和增效(增加安装速度，降低升级风险)方面出发，通
过app端、第一服务器端、第二服务器端以及设备端之间的通信，打造一个轻量的且具备低版本兼容的升级方式，可最大限度的保证机器人的安全性、兼容性和扩展性。
32.下面以附图为参考，针对本发明的实施例进行详细说明，以便本发明所述技术领域的技术人员能够容易地实施。本发明可以以多种不同形态体现，并不限于此处说明的实施例。
33.如图1展示本发明实施例中的一种ota升级系统的结构示意图。
34.所述系统包括：
35.app端1、第一服务器端2、第二服务器端3以及设备端4；
36.其中，所述app端1，与所述第一服务器端2以及第二服务器3端建立通信连接，用于向所述第一服务器端2发送请求并从所述第一服务器端2获取所述设备端的设备版本信息；其中，所述设备版本信息包括：最新版本号、当前版本号以及升级包下载信息；将最新版本号以及当前版本号对比判断所述设备端是否需要升级，若一致则不需要升级，还可提示“已是最新版本”；若不一致则需要升级，可提示可升级；在需要升级且由用户确定升级的情况下通过所述第二服务器端3向所述设备端下发对应的ota升级信息；其中，所述设备版本信息包括：最新版本号、当前版本号以及升级包下载信息；所述ota升级信息包括：所述最新版本号以及升级包下载信息；
37.所述设备端4，与所述第一服务器端2以及第二服务器端3建立通信连接，用于接收由所述app端1通过第二服务器端3发送的ota升级信息，并在判断可升级时基于所述升级包下载信息从所述第一服务器端2下载对应的ota升级包；对所述ota升级包进行内部处理以及升级安装，并将升级进度以及升级包的下载进度实时通过所述第二服务器端3反馈给所述app端1，以供所述app端1进行显示；
38.其中，所述升级安装的方式包括：对应从所述第一服务器端1下载的增量ota升级包的增量升级安装或对应从所述第一服务器端1下载的强制中间版本升级包的强制升级安装。
39.可选的，所述设备端包括：一主设备端以及至少一从设备端。
40.可选的，将主设备端作为组网中心点进行ota升级；其中，所述主设备端连接所述第一服务器端以及第二服务器端；所述主设备端实现以下几个步骤：
41.步骤(1)：接收由所述app端通过第二服务器端3发送的ota升级信息。具体的，所述app端1将该ota升级信息发送至第二服务器端3，再由第二服务器端3发送至所述主设备端41；
42.步骤(2)：判断所述设备端可升级时，基于所述升级包下载信息从所述第一服务器端2下载对应的ota升级包；具体的，将接收到的升级包下载信息中的最新版本号与本设备端的当前版本号进行对比，若不一致则所述设备端可升级，若一直则为不可升级；判断所述设备端可升级时，基于所述升级包下载信息从所述第一服务器端2下载对应的ota升级包。
43.步骤(3)：对所述ota升级包进行内部处理；优选的，所述对所述ota升级包进行内部处理的方式包括：验证上所述ota升级包的完整性以及在验证为完整的情况下对所述ota升级包进行解压。
44.步骤(4)：在当所述主设备端需要升级时，基于经过内部处理的ota升级包进行升级安装，并将对应的升级进度以及下载进度实时储存；在当从设备端需要升级时，则将经过
内部处理的ota升级包发送至对应的从设备端，所述从设备端当接收到经过内部处理的ota升级包时，进行升级安装，并将对应的升级进度以及下载进度实时发送至所述主设备端；
45.步骤(5)：总结升级的主设备端以及从设备端的升级进度以及下载进度，并且获得升级结果，并将总结的升级进度、下载进度以及升级结果通过所述第二服务器端3反馈给所述app端1，以供所述app端1显示。需要说明的是，所述升级结果包括升级成功结果以及升级失败结果；若所有升级均成功则升级结果为成功升级结果，若不是所有升级都成功则升级结果为失败结果。
46.可选的，所述在当从设备端需要升级时，则将经过内部处理的ota升级包发送至对应的从设备端包括：
47.如图2所示，所述主设备端41连接所述第一服务器端2以及第二服务器端3；所述从设备端42连接第二服务器端3，在当从设备端42需要升级时，则将经过内部处理的ota升级包通过4g或wifi通信方式发送至所述第二服务器端3，以供通过所述第二服务器端3发送内部处理的ota升级包至对应的从设备端42；
48.或者，
49.如图3所示，所述主设备端41连接所述第一服务器端2、第二服务器端3以及所述从设备端42；在当从设备端42要升级时，则将经过内部处理的ota升级包通过bt或zigbee通信方式发送至对应的从设备端42。该方式主从设备组成星型网络，以主设备为中心，通过bt/zigbee通道，将升级包数据发送给从设备。
50.可选的，所有主设备端以及从设备端都具备自己的联网模块，或wifi或4g模组。如图4所示，所述所述主设备端41连接所述第一服务器端2以及第二服务器端3；所述从设备端41连接所述第一服务器端2以及第二服务器端3；
51.所述主设备端41用于在需要升级时接收由所述app端1通过第二服务器端3发送的ota升级信息；在不需要升级时不收到该信息；将接收到的升级包下载信息中的最新版本号与本设备端的当前版本号进行对比，若不一致则所述设备端可升级，若一直则为不可升级；判断所述设备端可升级时，基于所述升级包下载信息从所述第一服务器端2下载对应的ota升级包；对所述ota升级包进行内部处理以及以及升级安装，并将升级进度以及下载进度通过所述第二服务器端3实时反馈给所述app端1，以供所述app端1进行显示；所述从设备端42用于在需要升级时接收由所述app端1通过第二服务器端2发送的ota升级信息，在不需要升级时不收到该信息；判断所述设备端可升级时，基于所述升级包下载信息从所述第一服务器端2下载对应的ota升级包；对所述ota升级包进行内部处理以及以及升级安装，并将升级进度以及下载进度通过所述第二服务器端2实时反馈给所述app端1，以供所述app端1进行显示。
52.可选的，若所述设备端4的当前版本号的版本与所述最新版本号的版本不兼容，所述app端1从所述第一服务器端2获取所述设备端4的包含由与所述最新版本兼容的强制中间版本作为最新版本所对应的最新版本号、当前版本号以及对应所述强制中间版本的强制中间版本升级包的升级包下载信息，以供所述设备端4接收由所述app端1通过第二服务器端3发送的ota升级信息，并在判断可升级时基于所述升级包下载信息从所述第一服务器端2下载对应的强制中间版本升级包；对所述强制中间版本升级包进行内部处理并进行强制升级安装使所述设备端的当前版本号的版本与最新版本号的版本兼容；并将升级进度以及
下载进度实时通过所述第二服务器端反馈给所述app端1，以供所述app端1进行显示；强制ota包为永驻型，即无论何时何地，只要机器人连接上server，就会收到推送的强制ota，设备根据自身判断是否需要升级；
53.当强制升级安装完毕后，所述app端1从所述第一服务器端获取所述设备端的最新版本号、当前版本号以及对应最新版本的增量ota升级包的升级包下载信息，以供所述设备端4基于所述升级包下载信息从所述第一服务器端2下载对应的增量ota升级包并进行增量升级安装。
54.可选的，若所述设备端4的当前版本号的版本与所述最新版本号的版本兼容，所述app端1从所述第一服务器端2获取所述设备端的最新版本号、当前版本号以及对应最新版本的增量ota升级包的升级包下载信息，以供所述设备端4基于所述升级包下载信息从所述第一服务器端2下载对应的增量ota升级包并进行增量升级安装。
55.通过以上方法不仅解决了增量省流量问题，同时解决了增量无法兼容的问题，也使得每次升级更加轻量，不易出错。
56.可选的，系统采用增量升级方式，即哪一个程序需要升级，所述服务器端仅仅打包该程序的升级包，打包成固定的ota.bin形式；当设备端下载和验证成功后，直接执行该ota.bin文件，无需解压等操作，bin文件的具体执行步骤，由bin文件中包含的脚本决定，即将ota包的升级所有权完全交给了bin文件生成人(开发工程师)，这样可以应对任意方式的添加、删除、更换等的需求。
57.可选的，所述第二服务器端包括：mqtt服务器端或bt服务器端。
58.可选的，所述升级包下载信息包括：升级包url地址以及md5值。具体的，所述设备端基于升级包url地址，从与其连接的第一服务器端下载对应的ota升级包；判断可否升级的方式包括：检测当前设备的md5值与所述升级包下载信息中的md5值是否一致。
59.为了更好的说明上述ota升级系统，本发明提供以下具体实施例。
60.实施例1：一种ota升级系统。如图5所示为该系统的结构示意图；
61.系统包括：app、server、mqtt以及割草机(主设备端)和充电桩(从设备端)；
62.①
app进入到升级界面后，从server获取当前设备的最新版本号和当前版本号。
63.②
app对比当前版本和最新版本是否相同，相同提示“已是最新版本”，否则提示可升级。
64.③
用户点击升级后，app下发ota信息，包括：最新版本号，ota包的md5值，ota包下载的url等。
65.④
app通过mqtt，将ota信息推送到待升级的主设备中，主设备收到ota信息后，做升级判断(二次验证)。
66.⑤
主设备根据ota信息的url，通过https从server端下载ota升级包；
67.⑥
主设备对ota升级包做内部处理：验证包的完整性，解压ota包，判断从设备是否需要升级，需要升级，跳转到步骤
⑦
；否则，跳转到步骤
⑨
。
68.⑦
此时根据主从设备的硬件支持类型，有多重方式可选；
69.1)4g/wifi，因为可以连接到server，主设备可通过mqtt，以字节流的形式发送从设备的升级包。
70.2)bt/zigbee，主从设备组成星型网络，以主设备为中心，通过bt/zigbee通道，
71.将升级包数据发送给从设备。
72.⑧
从设备接受完成升级包后，进行升级，下载/升级过程中，实时反馈进度信息给主设备。
73.⑨
从设备升级成功/失败，都将升级结果告知主设备(通过mqtt/bt),主设备做结果汇总后(即即使有一个设备未升级成功，本次成功也宣布失败)，反馈给app。
74.⑩
app做升级结果的显示，成功或失败(显示失败原因)。
75.其中，升级包采用增量形式进行升级，如当前总共有3个程序，每次可能只有1-2个需要升级，此时无需将所有的程序升级包都打包进去，这样浪费了流量，针对增量升级，采用如下方式：
76.采用增量升级方式，即哪一个程序需要升级，仅仅打包该程序的升级包，打包成固定的ota.bin形式。
77.设备端下载和验证成功后，直接执行该ota.bin文件，无需解压等操作，bin文件的具体执行步骤，由bin文件中包含的脚本决定，即将ota包的升级所有权完全交给了bin文件生成人(开发工程师)，这样可以应对任意方式的添加、删除、更换等的需求。
78.增量升级，量累积到一定程度后，必然会产生质变，即后续最新的版本不再兼容最开始的版本(默认用户每次都跟随升级)，但实际用户可能并没有跟随升级，如图6所示，假设用户处于原始版本最新版本为n，中间迭代了1-m等多代ota，最新版本只是增量发布了程序b和程序c此时在兼容线以下加入一个强制升级ota包(全量包)，即兼容线以上的部分，想要升级到最新版，必须先经历强制ota升级这一步，保证升级完成后，继续升级到最新版以上，不仅解决了增量省流量问题，同时解决了增量无法兼容的问题，也使得每次升级更加轻量，不易出错。
79.本实施例的增量升级包，中间穿插这全量强制ota包，强制ota包为永驻型，即无论何时何地，只要机器人连接上server，就会收到推送的强制ota，设备根据自身判断是否需要升级。将设备角色分为主从两种，主设备负责协调所有的ota包、流程等，从设备只根据主设备的指令行事，避免了对多个服务器的多次请求，也避免了app需要针对每个从设备都点击一次升级，增加了升级的兼容性和全面性。
80.实施例2：一种ota升级系统。如图6所示为该系统的结构示意图；
81.系统包括：app、server、mqtt以及主设备和从设备端；每个设备都具备自己的联网模块，或wifi或4g模组。
82.①
app进入到升级界面后，从server获取当前设备的最新版本号和当前版本号。
83.②
对比当前版本和最新版本是否相同，相同提示“已是最新版本”，否则提示可升级。
84.③
用户点击升级后，app下发ota信息，包括：最新版本号，ota包的md5值，ota包下载的url等。
85.④
通过mqtt，将ota信息推送到待升级的待升级设备(无所谓主从)中，待升级设备收到ota信息后，做升级判断(二次验证)。
86.⑤
待升级设备根据ota信息的url，通过https从server端下载ota升级包。
87.⑥
对ota升级包做内部处理：验证包的完整性，解压ota包，进行升级。
88.⑦
升级时/后，实时反馈升级状态，供app显示。
89.综上所述，本发明的ota升级系统，通过app端、第一服务器端、第二服务器端以及设备端之间的通信，打造一个轻量的且具备低版本兼容的升级方式，可最大限度的保证机器人的安全性、兼容性和扩展性。所以，本发明有效克服了现有技术中的种种缺点而具高度产业利用价值。
90.上述实施例仅示例性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，但凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。