CN114879991B - 一种软件升级方法、系统及存储介质 - Google Patents
一种软件升级方法、系统及存储介质 Download PDFInfo
- Publication number
- CN114879991B CN114879991B CN202210442206.4A CN202210442206A CN114879991B CN 114879991 B CN114879991 B CN 114879991B CN 202210442206 A CN202210442206 A CN 202210442206A CN 114879991 B CN114879991 B CN 114879991B
- Authority
- CN
- China
- Prior art keywords
- time
- restarting
- application
- application program
- upgrading
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
本申请公开一种软件升级方法、系统及存储介质,涉及应用软件更新领域,包括以下步骤:在应用端重启后,基础程序记录重启时间,并判断在预设时间内的重启次数是否超过第一预设值,若在预设时间内的重启次数超过第一预设值,则进入升级状态;在升级状态下:应用端接收升级包,并根据升级包对所述应用程序进行更新;完成应用程序的更新后,进入正常工作模式。应用程序在升级出错后会出现频繁重启的情况,基础程序通过对重启次数进行统计,再通过于第一预设值的比较即可判断出应用程序当前是否需要升级,若需要升级则可以无需对应用程序的升级标志位进行检测而直接进入到升级状态,从而实现对升级错误的应用程序再次升级的实际需要。
Description
技术领域
本申请涉及应用软件更新的领域,尤其是涉及一种软件升级方法、系统及存储介质。
背景技术
智能仪表是在仪表中安装具有一定数据处理能力的应用程序,在仪表采集监控对象的数据后应用程序可直接对该数据进行处理,再将处理后地数据传输给后台,而无需将大量的原始数据传输给后台,有效降低了数据传输量。
随着对数据处理需求地不断增长,智能仪表中的应用软件也需要不断地进行升级。现有的升级方式是先通过移动终端将升级指令传输给智能仪表中。智能仪表接受升级指令后,是由正在运行的应用软件根据升级指令写入升级标志位,然后自动重启智能仪表。重启后智能仪表中的基础程序先运行,基础程序检测到应用软件中的升级标志位,则将智能仪表的工作状态切换到升级状态。移动终端再将已经编写好的升级包传输到智能仪表中,基础程序根据升级包对应用程序进行升级。升级结束后,应用程序再进入到正常工作。
针对上述中的相关技术,发明人认为一旦升级出错,应用程序在运行时容易发生卡死、跑飞的情况,导致智能仪表无法正常工作。此时若想要通过移动终端重新对应用软件进行升级,程序混乱的应用程序也无法接收升级指令,导致基础程序无法检测到升级标志位,无法使智能仪表进入到升级状态,从而导致无法再次对应用程序进行升级。
发明内容
为了使升级出错的应用程序能够再次进入升级状态,本申请提供一种软件升级方法、系统及存储介质。
第一方面,本申请提供一种软件升级方法,采用如下的技术方案:
一种软件升级方法,应用在应用端上,所述应用端包括基础程序和应用程序,包括以下步骤:
在应用端重启后,基础程序记录重启时间,并根据所记录的重启时间判断在预设时间内的重启次数是否超过第一预设值,
若在预设时间内的重启次数超过第一预设值,则进入升级状态;
若在预设时间内的重启次数小于或等于第一预设值,则进入正常工作状态;
在升级状态下:
应用端接收升级包,并根据升级包对所述应用程序进行更新;
完成应用程序的更新后,进入正常工作模式。
通过采用上述技术方案,应用程序在跑飞或卡死时会触发看门狗,导致自动重启,而应用程序本身即使重启也仍由于出错而导致再次跑飞或卡死,因此会出现频繁重启的情况,基础程序通过对重启次数进行统计,再通过于第一预设值的比较即可判断出应用程序当前是否需要升级,若需要升级则可以无需对应用程序的升级标志位进行检测而直接进入到升级状态,从而实现对升级错误的应用程序再次升级的实际需要。
可选的,在预设时间内的重启次数,通过以下步骤获取:
从所记录的重启时间筛选出最晚一次的重启时间并作为结尾时间;
根据结尾时间和预设时间确定起始时间;
统计出处在起始时间和结尾时间之间的重启时间并形成时间集合,所述时间集合中的重启时间按照记录的先后顺序进行排列,所述时间集合中所存储的重启时间的个数为总次数;
依次判断时间集合中相邻重启时间的时间间隔是否超过第二预设值,时间集合中每有一组相邻重启时间的时间间隔超过第二预设值,则将总次数扣除一次,并将扣除后的结果作为重启次数。
可选的,应用端接收升级包,并根据升级包对所述应用程序进行更新,包括以下步骤:
应用端每接收外界的数据包,则判断数据包中是否存在特定信息,若数据包中存在特定信息,则该数据包为升级包,将升级包中的数据写入到应用程序中,并判断应用程序中的数据量是否达到预设的个数,
若应用程序中的数据量达到预设的个数,则退出升级状态;
若应用程序中的数据量没有达到预设的个数,则维持升级状态。
可选的,还包括:在正常工作状态下:
应用端每接收外界的通讯指令,则判断该通讯指令中是否存在与预设地址一致的地址信息,
若该通讯指令中存在与预设地址一致的地址信息,则应用程序写入升级标志位,并重新启动应用端。
可选的,若在预设时间内的重启次数小于或等于第一预设值,则进入正常工作状态,还包括以下步骤:
若在预设时间内的重启次数小于或等于第一预设值,则基础程序判断应用程序中是否存在升级标志位,
若应用程序中存在升级标志位,则进入升级状态;
若应用程序中不存在升级标志位,则进入正常工作状态。
可选的,所述应用端具有多个用于与控制端通信的通信通道;
若该通讯指令中存在与预设地址一致的地址信息,还包括获取通讯指令中的通道信息,根据通道信息维持对应通信通道的开启,并在下一次退出升级状态前关闭其他通信通道。
可选的,统计出处在起始时间和结尾时间之间的重启时间并形成时间集合,包括以下步骤:
建立空的时间集合,并根据重启时间的存储顺序以从后往前的方式依次判断重启时间是否处在起始时间和结尾时间之间,
若重启时间处在起始时间和结尾时间之间,则将该重启时间存储到时间集合中;
若重启时间不处在起始时间和结尾时间之间,则结束对后续重启时间是否处在起始时间和结尾时间之间的判断。
第二方面,本申请提供一种软件升级系统,采用如下的技术方案:
一种软件升级系统,包括控制端和应用端,所述控制端用于发送升级包,其中,升级包包括地址信息;
所述应用端包括基础程序和应用程序,且应用端具有升级状态和正常工作状态;
基础程序用于在应用端重启后记录重启时间,并根据所记录的重启时间判断在预设时间内的重启次数是否超过第一预设值,若在预设时间内的重启次数超过第一预设值,则应用端进入升级状态;若在预设时间内的重启次数小于或等于第一预设值,则应用端进入正常工作状态;
应用端用于在升级状态下接收升级包,并根据升级包对应用程序进行更新。
可选的,所述控制端还用于发送升级指令;
所述应用端用于在正常工作状态下接收升级指令,以及根据升级指令在应用程序中写入升级标志位并重启;
基础程序用于在应用端重启后判断应用程序是否存在升级标志位;
若应用程序存在升级标志位,则应用端进入升级状态;
若应用程序不存在升级标志位,则应用端进入正常工作状态。
第三方面,本申请提供一种计算机可读存储介质,存储有能够被处理器加载并执行上述任一种方法的计算机程序。
综上所述,本申请包括以下至少一种有益技术效果:应用程序在跑飞或卡死时会触发看门狗,导致自动重启,而应用程序本身即使重启也仍由于出错而导致再次跑飞或卡死,因此会出现频繁重启的情况,基础程序通过对重启次数进行统计,再通过于第一预设值的比较即可判断出应用程序当前是否需要升级,若需要升级则可以无需对应用程序的升级标志位进行检测而直接进入到升级状态,从而实现对升级错误的应用程序再次升级的实际需要。
附图说明
图1是本申请实施例的步骤流程图。
图2是本申请实施例的系统框图。
图3是本申请实施例的应用端的工作流程图。
图4是本申请实施例的控制端的工作流程图。
附图标记说明:1、控制端;2、应用端。
具体实施方式
以下结合附图1至图4对本申请作进一步详细说明。
本申请实施例公开一种软件升级方法,应用在应用端和控制端中。
应用端是指内部设置有应用程度且能够根据外界指令对应用程序进行升级的设备,例如智能流量计、智能电表等等,本实施例中以智能流量计来作为例子进行具体介绍。另外,为了实现对应用程序升级,应用端中还需要设置基础程序,常见的基础程序为bootloader。基础程序用于对应用程序的内容进行判断,以分辨应用程序是否需要进行升级,从而控制应用端进入到相应的工作状态。
控制端是指能够向外发送升级指令以及后续升级包的设备,控制端可以是智能手机等移动终端,也可以是PC端。
而控制端和应用端之间的通讯方式既可以是无线传输方式,如蓝牙通讯;也可以是有线传输方式,如采用485通讯线来连接控制端和应用端。
应用端的工作状态包括正常工作状态和升级状态,当应用端处在正常工作状态时,运行应用程序,基础程序不工作;当应用端处在升级状态时,运行基础程序,而应用程序暂停工作。另外,应用端重启后基础程序先运行,基础程序判断应用程序是否满足升级要求,并根据判断结果控制应用端进入相应的工作状态。
应用端一般的升级流程是:在应用端处在正常工作状态时,控制端发出升级指令,则应用程序接受到升级指令后与升级指令结合并重启应用端,此时基础程序识别到应用程序与升级指令结合,则基础程序控制应用端进入升级状态,然后基础程序接受控制端发出的升级包,将升级包写入到应用程序中,当所有升级包均写入完毕后,解除应用程序与升级指令的结合,并再次重启应用端。此次重启后,基础程序将控制应用端进入正常工作状态,基础程序关闭,应用程序启动。
而除了上述的正常进入升级状态或是退出升级状态时所触发的重启以及由人工操作引起的重启外,还存在一种重启方式:因应用程序更新出错而导致应用程序运行时发出跑飞,进而触发看门狗所引起的复位重启,但应用程序重启并进入正常工作状态后,应用程序仍会再次跑飞,导致应用端陷入到重启-跑飞-再重启的循环中。另外,后一种重启方式中,由于应用程序的不正常,同样会导致应用程序无法与升级指令结合,从而导致基础程序无法控制应用端进入升级状态,进而使得无法正常地重新升级应用程序。本申请公开的一种软件升级方法正是为了解决由于应用程序出错而出现地频繁重启。
一种软件升级方法,参见图1,包括以下步骤:
S100、在应用端重启后,基础程序记录重启时间,并根据所记录的重启时间判断在预设时间内的重启次数是否超过第一预设值。
由于应用程序出错而引起的重启比其余常规的重启显得更加频繁,因此通过记录重启时间以及统计重启次数,即能够较为有效地区分出是否发生了因应用程序出错而引起的重启。预设时间由人工设置,且预设时间一般要覆盖三次以上因应用程序出错而引起的重启所需花费的时间,因此,第一预设值至少为三。
另外,在应用端重启后,由基础程序记录重启时间,而不是在重启前记录重启时间,也是考虑到一旦应用程序出错,应用程序无法执行特定的操作,而在正常工作状态下基础程序不工作而无法做到记录重启时间,因此是在应用端重启后,基础程序开始工作后,由基础程序记录重启时间,其本质是只要基础程序从不工作转变到工作时,就会自动记录一次当前时间,该当前时间就是重启时间。
S200、若在预设时间内的重启次数小于或等于第一预设值,则进入正常工作状态。
需注意的是,上述步骤中基础程序并不是单纯地依靠判断出在预设时间内地重启时间小于或等于第一预设值,就会控制应用端进入到正常工作状态。在预设时间内地重启时间小于或等于第一预设值,仅仅是将重启的原因是应用程序跑飞这一原因给排除掉,应用端若要进入正常工作状态,还需要基础程序对应用程序的状态进一步做出判断。
S300、若在预设时间内的重启次数超过第一预设值,则进入升级状态。
若预设时间内的重启次数超过第一预设值,则基础程序判断存在频繁的重启,那么,基础程序将控制应用端进入升级状态,以应对可能存在的应用程序跑飞的情况。
在一个实施例中,在预设时间内的重启次数,通过以下步骤获取:
S310、从所记录的重启时间筛选出最晚一次的重启时间并作为结尾时间。
在记录重启时间时,为了方便筛选,应用端按照记录的先后顺序来存储重启时间。筛选时,只需调取最后一个重启时间作为结尾时间即可。
另外,筛选出最晚一次的重启时间在绝大多数情况下就是基础程序在该次重启后所记录的时间。因此也可以在基础程序记录当前时间作为重启时间的同时,将该次的重启时间直接作为结尾时间。
S320、根据结尾时间和预设时间确定起始时间。
结尾时间减去预设时间即为起始时间。
S330、统计出处在起始时间和结尾时间之间的重启时间并形成时间集合,所述时间集合中的重启时间按照记录的先后顺序进行排列,所述时间集合中所存储的重启时间的个数为总次数。
统计出处在起始时间和结尾时间之间的重启时间并形成时间集合,具体包括以下步骤:
S331、建立空的时间集合,并根据重启时间的存储顺序以从后往前的方式依次判断重启时间是否处在起始时间和结尾时间之间。
S332、若重启时间处在起始时间和结尾时间之间,则将该重启时间存储到时间集合中。
S333、若重启时间不处在起始时间和结尾时间之间,则中断对后续重启时间是否处在起始时间和结尾时间之间的判断,并跳转到步骤S240。
相较于无序地判断每个重启时间是否处在起始时间和结尾时间之间,按照存储顺序的从后往前来对重启时间进行判断具有减少一定数据比较的作用,因为一旦出现某一重启时间不处在起始时间和结尾时间之间,则早于该重启时间的其余重启时间必然也不处在起始时间和结尾时间之间,不需要在对这些重启时间进行比较。
S340、依次判断时间集合中相邻重启时间的时间间隔是否超过第二预设值,时间集合中每有一组相邻重启时间的时间间隔超过第二预设值,则将总次数扣除一次,并将扣除后的结果作为重启次数。
第二预设值是根据日常中检测到的应用程序因跑飞而出现连续两次重启所需时间中的众数来设定,当然第二预设值要略微高于众数以囊括更多的重启时间。
由于人工重启、应用程序正常运行时重启也存在频繁出现的可能性,那么先进一步明确重启是正常重启还是应用程序跑飞而导致的重启,再统计认为是应用程序跑飞而导致的重启的次数,将该重启次数与第一预设值进行比较,使得比较结果更加准确。
在一个实施例中,若在预设时间内的重启次数小于或等于第一预设值,则进入正常工作状态,还包括以下步骤:
若在预设时间内的重启次数小于或等于第一预设值,则基础程序判断应用程序中是否存在升级标志位。
若应用程序中存在升级标志位,则进入升级状态。
若应用程序中不存在升级标志位,则进入正常工作状态。
判断应用程序中是否存在升级标志位就是判断应用程序是否接收升级指令并与升级指令结合。因此,若应用程序中存在升级标志位,则表明应用程序接收升级指令并与升级指令结合,应用端进入升级状态。若应用程序中不存在升级标志位,则表明应用程序未接收到升级指令,或是接收到升级指令却没有和升级指令结合,应用端进入正常工作状态。
在升级状态下:
S400、应用端接收升级包,并根据升级包对所述应用程序进行更新。
升级包由控制端发出。若应用端不处在升级状态,应用端即使接收到升级包,也不会将升级包中含有的数据写入到应用程序中,而是丢弃升级包。只有应用端处在升级状态时,应用端在接收到升级包后,才会根据升级包对应用程序进行更新。
在一个实施例中,应用端接收升级包,并根据升级包对所述应用程序进行更新,包括以下步骤:
S410、应用端每接收外界的数据包,则判断数据包中是否存在特定信息,若数据包中存在特定信息,则该数据包为升级包,将升级包中的数据写入到应用程序中,并判断应用程序中的数据量是否达到预设的个数。
升级包是对控制端发出的且应用在对应用端中应用软件升级的数据包的称呼,但是控制端并不是只发送升级包,且应用端也并不是只会接收升级包。因此升级包需要额外设置特定信息来区分于其他数据包。
另外,应用端在将升级包中的数据写入应用程序后,判断应用程序中的数据量是否达到预设的个数,以判断是否已经完成升级工作,预设的个数是由升级包传递给应用端的,即升级包发出时,控制端会将整个软件升级所需的数据个数添加到升级包中。
S420、若应用程序中的数据量达到预设的个数,则退出升级状态。
S430、若应用程序中的数据量没有达到预设的个数,则维持升级状态。
一旦应用程序的数据量达到预设的个数,则应用端会直接从升级状态切换到正常工作状态。
S500、完成应用程序的更新后,进入正常工作模式。
假设在完成应用程序更新后,再次执行步骤S100,由于更新所花费的时间较长,导致在预设时间内基本不会出现几次重启时间,此次基础程序会判断在预设时间内的重启次数小于或等于第一预设值。再加上应用程序刚完成更新,基础程序也不会判断出应用程序与升级指令结合,因此应用端最终会进入正常工作状态并运行应用程序。所以在完成应用程序的更新后,直接进入正常工作模式,能够减少不必要的数据处理。
控制端和应用端的通讯方式可以是通过一对一匹配的方式来传输数据,也可以通过一对多群发的方式来传输数据包。前一通讯方式下控制端发出的数据包能够稳定被相匹配的应用端接收到,确保数据不会传输到错误的应用端,但该通讯方式需要应用端和控制端之间先完成匹配才行。后一通讯方式则无需提前对控制端和应用端进行配对,但需要解决应用端如何匹配到正确的升级指令这一问题。
为了使应用端能够匹配到正确的升级指令,软件升级方法还包括以下步骤:
在正常工作状态下:
S600、应用端每接收外界的通讯指令,则判断该通讯指令中是否存在与预设地址一致的地址信息。
外界的通讯指令并不一定就是控制端所发出的升级指令,因此为了方便应用端识别,控制端发出的升级指令中包含地址信息。预设地址是指应用端中所预设的地址信息,且不同应用端预设的地址信息各不相同。控制端想要对某一应用端进行升级时,只要在升级指令中添加上该应用端中预设的地址信息即可。
由于升级指令以及上述的升级包在传输过程中会进行加密设置,为了快速获取升级指令中的地址信息或是升级包中的特定信息,地址信息和特定信息均为被控制端写入到加密的数据包的固定包头上,另外,为了减少所占用的包头位置,特定信息和地址信息将共用相同的包头位置。例如,当一个控制器要对8个应用端进行升级时,应用端的地址信息分别为1-8,那么将特定信息设置为9,即可避免地址信息和特定信息出现混乱。
S610、若该通讯指令中存在与预设地址一致的地址信息,则应用程序写入升级标志位,并重新启动应用端。
若该通讯指令中存在与预设地址一致的地址信息,则认为该通讯指令为升级指令,且应用程序写入升级标志位,并重新启动应用端。
若该通讯指令中不存在与预设地址一致的地址信息,则应用程序抛弃该通讯指令。
在一个实施例中,若该通讯指令中存在与预设地址一致的地址信息,还包括获取通讯指令中的通道信息,根据通道信息维持对应通信通道的开启,并在下一次退出升级状态前关闭其他通信通道。
应用端可以具有多个用于与控制端通信的通信通道。在正常工作状态下,应用端的所有通信通道都是开启的,以便于接收以各个通信方式传输的升级指令。而一旦应用端接收到升级指令,应用端随着重启并进入到升级状态后,为了避免其他通信通道传输的数据包对升级过程造成干扰,将关闭其他通信通道,仅保留所接收的升级指令所传输的通信通道。
通讯指令中的通信信息是控制端在选择通信方式发出升级指令时,自动将该通信方式对应的通信信息添加到升级指令中。
本申请实施例还公开一种软件升级系统,参见图2,包括控制端1和应用端2,控制端1用于发送升级包和升级指令,其中,升级包包括地址信息,升级指令包括特殊信息。
应用端2包括基础程序和应用程序。
其中,应用端2具有升级状态和正常工作状态。在应用端2重启后,基础程序用于记录重启时间,并根据所记录的重启时间判断在预设时间内的重启次数是否超过第一预设值,若在预设时间内的重启次数超过第一预设值,则应用端2进入升级状态;若在预设时间内的重启次数小于或等于第一预设值,则应用端2进入正常工作状态。
在升级状态下:
应用端2用于接收升级包,并根据升级包对应用程序进行更新。
完成应用程序的更新后,应用端2进入正常工作模式。
在正常工作状态下:
应用端2用于接收升级指令,并根据升级指令在应用程序上写入升级标识符。
具体的,参见图3,应用端2的工作流程为:在应用端2重启后,基础程序先运行,应用程序暂停。基础程序在运行后记录当前的时间作为重启时间,并统计出在预设时间内的重启次数,判断重启次数是否超过第一预设值,若重启次数超过第一预设值,则进入升级状态。
若重启次数小于或等于第一预设值,则基础程序判断应用程序中是否存在升级标志位。
若应用程序中不具有升级标志位,则进入正常工作状态。
若应用程序中具有升级标志位,则进入升级状态。
在升级状态下,应用端2开始等待升级所需的数据包。并且等待升级的过程中,应用端每隔固定时间向外发出带有预设信息的应答包,应答包包括进度数据和总长度数据。固定时间一般为10秒。当然在应用端还未接收到第一个升级包前,应答包中的进度数据和总长度数据均为0。
当应用端接收到数据包后,基础程序先判断数据包的固定包头上是否存在特殊信息,以及整个数据包的格式是否正确。当数据包的固定包头上不存在特殊信息或整个数据包的格式不正确时丢弃数据包。
当数据包的固定包头上存在特殊信息且整个数据包的格式正确时,该数据包为升级包。基础程序对升级包进行解密,记录数据包中携带的数据总长度和当前接收到的所有数据的个数,并根据当前接收到的所有数据的个数来判断该数据包是否为第一个数据包,当前接收到的所有数据的个数就是该数据包内数据个数时,该数据包为第一个数据包;反之,该数据包不是第一个数据包。
当应用端2接收到第一个数据包时,基础程序需进一步获取该数据包中的升级版本,并与应用软件当前的升级版本进行比较,若数据包的升级版本低于或等于应用软件当前的升级版本,则认为该数据包的升级版本是应用程序的合法升级软件版本。然后将数据包中的数据写入到应用程序中,并再次发出应答包,此时应答包中的进度数据和总长度数据均有具体数值。
当应用端2接收到除第一个外的数据包时,则可跳过对升级版本的验证,直接将数据包的数据写入到应用程序中。
每个数据包完成写入后,基础程序判断该数据包是否为最后一个数据包,判断方式同样是比较进度数据与总长度数据,若进度数据与总长度数据一致,则认为该数据包为最后一个,基础程序擦除升级标志位,跳转到应用程序,且应用端进入到正常工作模式。
在正常工作模式下,运行应用程序,且应用程序定期判断是否接收到升级指令,定期时间一般为10秒。若应用程序接收到升级指令,则在应用程序中写入升级标志位,并重启应用端。
参见图4,控制端1的工作流程为:控制端1读取升级文件,基于人工输入的地址信息生成软件升级指令,并根据人工所选择的通信通道发出该升级指令。发出升级指令后,控制器经过预设时间后判断是否接收到与地址信息一致的应用端所传输的应答包,其中,预设时间大于应用端在接收到升级指令到发出对应应答包所需的时间。
若控制端1未接收到与地址信息一致的应用端所传输的应答包,则控制器重新发出升级指令。
若控制端1接收到与地址信息一致的应用端所传输的应答包,则判断应答包中所携带的总长度数据是否和升级文件总长度相等。
若应答包中所携带的总长度数据和升级文件总长度不相等,则将当前升级文件的进度清零,并重新读取文件总长度。再按顺序读取当前升级文件,每次读取的数据大小一般为2k。然后加密读取出的数据,并构建成数据包后发出数据包。数据包包括文件总长度以及当前读取的升级文件数据。
若应答包中所携带的总长度数据和升级文件总长度相等,则判断应答包中所携带的进度数据是否和升级文件的读取进度相等。
若应答包中所携带的进度数据和升级文件的读取进度不相等,则将升级文件的读取进度重新定位到应答包中所携带的进度数据。再按顺序读取当前升级文件。然后加密读取出的数据,并构建成数据包后发出数据包。
若应答包中所携带的进度数据和升级文件的读取进度相等,则判断升级文件的读取进度是否已至结尾。
若升级文件的读取进度已至结尾,则结束整个流程。
若升级文件的读取进度没有到结尾,则按顺序读取当前升级文件。然后加密读取出的数据,并构建成数据包后发出数据包。
每个数据包发出后,控制端经过预设时间后判断是否接收到与地址信息一致的应用端所传输的应答包。
本申请实施例还公开一种计算机可读存储介质,存储有能够被处理器加载并执行上述方法的计算机程序。
以上均为本申请的较佳实施例,并非依此限制本申请的保护范围,故:凡依本申请的结构、形状、原理所做的等效变化,均应涵盖于本申请的保护范围之内。
Claims (6)
1.一种软件升级方法,其特征在于,应用在应用端上,所述应用端包括基础程序和应用程序,包括以下步骤:
在应用端重启后,基础程序记录重启时间,并根据所记录的重启时间判断在预设时间内的重启次数是否超过第一预设值,
若在预设时间内的重启次数超过第一预设值,则进入升级状态;
若在预设时间内的重启次数小于或等于第一预设值,则进入正常工作状态;
其中,所述预设时间内的重启次数,通过以下步骤获取:
从所记录的重启时间筛选出最晚一次的重启时间并作为结尾时间;
根据结尾时间和预设时间确定起始时间;
统计出处在起始时间和结尾时间之间的重启时间并形成时间集合,所述时间集合中的重启时间按照记录的先后顺序进行排列,所述时间集合中所存储的重启时间的个数为总次数;
依次判断时间集合中相邻重启时间的时间间隔是否超过第二预设值,时间集合中每有一组相邻重启时间的时间间隔超过第二预设值,则将总次数扣除一次,并将扣除后的结果作为重启次数;
在升级状态下:
应用端接收升级包,并根据升级包对所述应用程序进行更新;
具体的,
应用端每接收外界的数据包,则判断数据包中是否存在特定信息,若数据包中存在特定信息,则该数据包为升级包,将升级包中的数据写入到应用程序中,并判断应用程序中的数据量是否达到预设的个数,
若应用程序中的数据量达到预设的个数,则退出升级状态;
若应用程序中的数据量没有达到预设的个数,则维持升级状态;
完成应用程序的更新后,进入正常工作模式;
在正常工作状态下:
应用端每接收外界的通讯指令,则判断该通讯指令中是否存在与预设地址一致的地址信息,
若该通讯指令中存在与预设地址一致的地址信息,则应用程序写入升级标志位,并重新启动应用端;
所述应用端具有多个用于与控制端通信的通信通道;
若该通讯指令中存在与预设地址一致的地址信息,还包括获取通讯指令中的通道信息,根据通道信息维持对应通信通道的开启,并在下一次退出升级状态前关闭其他通信通道。
2.根据权利要求1所述的一种软件升级方法,其特征在于,若在预设时间内的重启次数小于或等于第一预设值,则进入正常工作状态,还包括以下步骤:
若在预设时间内的重启次数小于或等于第一预设值,则基础程序判断应用程序中是否存在升级标志位,
若应用程序中存在升级标志位,则进入升级状态;
若应用程序中不存在升级标志位,则进入正常工作状态。
3.根据权利要求1所述的一种软件升级方法,其特征在于,统计出处在起始时间和结尾时间之间的重启时间并形成时间集合,包括以下步骤:
建立空的时间集合,并根据重启时间的存储顺序以从后往前的方式依次判断重启时间是否处在起始时间和结尾时间之间,
若重启时间处在起始时间和结尾时间之间,则将该重启时间存储到时间集合中;
若重启时间不处在起始时间和结尾时间之间,则结束对后续重启时间是否处在起始时间和结尾时间之间的判断。
4.一种软件升级系统,其特征在于,包括控制端和应用端,所述控制端用于发送升级包,其中,升级包包括地址信息;
所述应用端包括基础程序和应用程序,且应用端具有升级状态和正常工作状态;
基础程序用于在应用端重启后记录重启时间,并根据所记录的重启时间判断在预设时间内的重启次数是否超过第一预设值,若在预设时间内的重启次数超过第一预设值,则应用端进入升级状态;若在预设时间内的重启次数小于或等于第一预设值,则应用端进入正常工作状态;
其中,所述预设时间内的重启次数,通过以下步骤获取:
基础程序从所记录的重启时间筛选出最晚一次的重启时间并作为结尾时间;
根据结尾时间和预设时间确定起始时间;
统计出处在起始时间和结尾时间之间的重启时间并形成时间集合,所述时间集合中的重启时间按照记录的先后顺序进行排列,所述时间集合中所存储的重启时间的个数为总次数;
依次判断时间集合中相邻重启时间的时间间隔是否超过第二预设值,时间集合中每有一组相邻重启时间的时间间隔超过第二预设值,则将总次数扣除一次,并将扣除后的结果作为重启次数;
应用端用于在升级状态下接收升级包,并根据升级包对应用程序进行更新;
具体的,
应用端每接收外界的数据包,则判断数据包中是否存在特定信息,若数据包中存在特定信息,则该数据包为升级包,将升级包中的数据写入到应用程序中,并判断应用程序中的数据量是否达到预设的个数,
若应用程序中的数据量达到预设的个数,则退出升级状态;
若应用程序中的数据量没有达到预设的个数,则维持升级状态;
完成应用程序的更新后,进入正常工作模式;
在正常工作状态下:
应用端每接收外界的通讯指令,则判断该通讯指令中是否存在与预设地址一致的地址信息,
若该通讯指令中存在与预设地址一致的地址信息,则应用程序写入升级标志位,并重新启动应用端;
所述应用端具有多个用于与控制端通信的通信通道;
若该通讯指令中存在与预设地址一致的地址信息,还包括获取通讯指令中的通道信息,根据通道信息维持对应通信通道的开启,并在下一次退出升级状态前关闭其他通信通道。
5.根据权利要求4所述的一种软件升级系统,其特征在于:所述控制端还用于发送升级指令;
所述应用端用于在正常工作状态下接收升级指令,以及根据升级指令在应用程序中写入升级标志位并重启;
基础程序用于在应用端重启后判断应用程序是否存在升级标志位;
若应用程序存在升级标志位,则应用端进入升级状态;
若应用程序不存在升级标志位,则应用端进入正常工作状态。
6.一种计算机可读存储介质,其特征在于,存储有能够被处理器加载并执行如权利要求1至3中任一种方法的计算机程序。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210442206.4A CN114879991B (zh) | 2022-04-25 | 2022-04-25 | 一种软件升级方法、系统及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210442206.4A CN114879991B (zh) | 2022-04-25 | 2022-04-25 | 一种软件升级方法、系统及存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN114879991A CN114879991A (zh) | 2022-08-09 |
CN114879991B true CN114879991B (zh) | 2023-05-02 |
Family
ID=82672264
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210442206.4A Active CN114879991B (zh) | 2022-04-25 | 2022-04-25 | 一种软件升级方法、系统及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114879991B (zh) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2021039651A (ja) * | 2019-09-05 | 2021-03-11 | 本田技研工業株式会社 | ソフトウェア更新装置、ソフトウェア更新方法、およびプログラム |
WO2021223658A1 (zh) * | 2020-05-07 | 2021-11-11 | 支付宝(杭州)信息技术有限公司 | 小程序的更新 |
CN113672297A (zh) * | 2021-07-23 | 2021-11-19 | 荣耀终端有限公司 | 一种recovery模式升级过程中的重启方法及终端 |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105094875A (zh) * | 2014-05-19 | 2015-11-25 | 中兴通讯股份有限公司 | 一种软件升级方法及装置 |
CN108650193A (zh) * | 2018-03-30 | 2018-10-12 | 青岛海信智慧家居系统股份有限公司 | 一种数据包发送的方法和设备 |
CN109375940A (zh) * | 2018-08-15 | 2019-02-22 | 广州南方卫星导航仪器有限公司 | 一种数传电台的升级方法、系统及存储介质 |
CN110262838A (zh) * | 2019-06-14 | 2019-09-20 | 深圳乐信软件技术有限公司 | 一种程序崩溃的处理方法、装置、终端及存储介质 |
CN110837389A (zh) * | 2019-11-01 | 2020-02-25 | 北京云迹科技有限公司 | 设备升级方法、装置、物联网设备和存储介质 |
CN111078471B (zh) * | 2019-12-06 | 2023-09-05 | 深圳创维-Rgb电子有限公司 | 显示设备的系统故障恢复方法、设备及计算机存储介质 |
CN113127029A (zh) * | 2021-03-05 | 2021-07-16 | 深兰科技(上海)有限公司 | 固件更新方法、装置、电子设备及存储介质 |
CN113032183A (zh) * | 2021-03-24 | 2021-06-25 | 西安闻泰信息技术有限公司 | 系统管理方法、装置、计算机设备和存储介质 |
CN113138791A (zh) * | 2021-05-18 | 2021-07-20 | 拉扎斯网络科技(上海)有限公司 | 基于嵌入式系统的升级处理方法、装置及电子设备 |
-
2022
- 2022-04-25 CN CN202210442206.4A patent/CN114879991B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2021039651A (ja) * | 2019-09-05 | 2021-03-11 | 本田技研工業株式会社 | ソフトウェア更新装置、ソフトウェア更新方法、およびプログラム |
WO2021223658A1 (zh) * | 2020-05-07 | 2021-11-11 | 支付宝(杭州)信息技术有限公司 | 小程序的更新 |
CN113672297A (zh) * | 2021-07-23 | 2021-11-19 | 荣耀终端有限公司 | 一种recovery模式升级过程中的重启方法及终端 |
Non-Patent Citations (4)
Title |
---|
lulian Neamtiu等.Practical dynamic software updating for C.《ACM SIGPLAN Notices》.2006,第72-83页. * |
李春生等.水质监测网络中RTU在线软件升级的安全措施.《气象水文海洋仪器》.2006,第15-19页. * |
李权等.高可靠性的嵌入式软件现场更新方法.《计算机应用》.2010,第2228-2231页. * |
赵冬晖.软件动态更新中错误状态的修复.《计算机工程》.2008,第46-48页. * |
Also Published As
Publication number | Publication date |
---|---|
CN114879991A (zh) | 2022-08-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN107634859B (zh) | 一种固件升级方法及装置 | |
CN104025047B (zh) | 信息处理装置、信息处理方法以及计算机程序 | |
JP5347997B2 (ja) | 故障診断用情報収集装置 | |
EP3291086A1 (en) | Method and device for downloading software version, and storage medium | |
JP2006264877A (ja) | エレベータ制御装置 | |
CN107357614A (zh) | 参数更新方法及参数更新装置、种植箱和存储介质 | |
EP3128247A1 (en) | Air conditioner, air conditioner system, and rewrite control program | |
CN112631628A (zh) | 单片机升级方法、单片机、存储介质 | |
CN104991800A (zh) | 一种未联网设备固件升级方法、装置和系统 | |
CN114879991B (zh) | 一种软件升级方法、系统及存储介质 | |
JP4883314B2 (ja) | Plcを用いたデータトレースシステム | |
JP3493772B2 (ja) | 制御ソフトウェア仕様変更システム | |
CN103809502A (zh) | 控制器及程序 | |
US20040249988A1 (en) | Attribute reporting over a ps/2 protocol | |
KR100888538B1 (ko) | 자기 테이프 장치의 제어 장치, 제어 방법 및 기록매체 | |
CN112527203B (zh) | 闪存存储器的数据重写方法、系统、终端设备及存储介质 | |
JP3385844B2 (ja) | 自動販売機 | |
JP6727472B1 (ja) | プログラマブルロジックコントローラ、設定ツール、及びプログラム | |
EP1560154A1 (en) | Entertainment system, information processing unit and portable storage device | |
KR100615123B1 (ko) | 메모리 재기록 장치 | |
JP3687565B2 (ja) | ログデータ保存方式、ログデータ保存方法およびログデータ保存用プログラム | |
JP2014041390A (ja) | 設計・開発支援システム | |
CN115098138A (zh) | 电池管理系统的功能升级方法、装置、电子设备及介质 | |
JP2003271410A (ja) | プログラムデータ書替システム | |
CN114153709B (zh) | 一种服务器测试行为分析方法、装置及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |