CN110798331B - 一种设备升级方法和装置 - Google Patents
一种设备升级方法和装置 Download PDFInfo
- Publication number
- CN110798331B CN110798331B CN201810869281.2A CN201810869281A CN110798331B CN 110798331 B CN110798331 B CN 110798331B CN 201810869281 A CN201810869281 A CN 201810869281A CN 110798331 B CN110798331 B CN 110798331B
- Authority
- CN
- China
- Prior art keywords
- version number
- equipment
- transaction
- upgrade
- result
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
- H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/085—Retrieval of network configuration; Tracking network configuration history
- H04L41/0859—Retrieval of network configuration; Tracking network configuration history by keeping history of different configuration generations or by rolling back to previous configuration versions
- H04L41/0863—Retrieval of network configuration; Tracking network configuration history by keeping history of different configuration generations or by rolling back to previous configuration versions by rolling back to previous configuration versions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Stored Programmes (AREA)
Abstract
公开了一种设备升级方法和装置,所述方法包括:IOT网关获取升级请求,所述升级请求中包括升级包的第一期望版本号;根据所述第一期望版本号对第一设备集合中的至少一个设备的期望版本号进行更新,并将更新后包括第一期望版本号的至少一个更新结果记录在区块链本地账本上;IOT网关通过所述第一期望版本号确定待升级设备;并向所述待升级设备发送升级任务,以使所述待升级设备按照第一期望版本号更新自身的版本号。本方法,基于区块链的共识机制和分布式账本功能,通过更新的期望版本号确定待升级设备,使得这些设备的设备信息不受限于某一个设备,避免某一网元设备发生故障时,影响全网的设备升级,本方法提高设备升级系统的稳健性。
Description
技术领域
本申请涉及区块链领域,尤其涉及一种设备升级方法和装置。
背景技术
物联网是新一代信息技术的重要组成部分,也是“信息化”时代的重要发展阶段。物联网(Internet of things,IoT)即物物相连的互联网。它包括两层含义:其一,物联网的核心和基础仍然是互联网,是在互联网基础上的延伸和扩展的网络;其二,其用户端延伸和扩展到了任何物品与物品之间,进行信息交换和通信。一般地,可以将“物品”统称为IOT设备。
IOT设备在使用中经常面临升级(包括设备固件、设备上的软件包等)的需求:比如,由于IOT设备使用广、场景多,所以需要不断升级IOT设备上的软件包来支持自身的发展和创新的实现。另外,为了保护IOT设备避免攻击和遭到损坏,需要将其升级为最新固件。
目前,IOT设备升级通常作为IOT平台的一项设备管理服务提供。由于IOT设备具有数量多、物理位置分散、升级频繁等特点,所以对设备升级服务的健壮性提出了巨大挑战。一种为IOT设备升级方式是,利用IOT平台以及其配套的IOT网关来提供升级服务。其中,该IOT平台由IOT业务运营商提供,IOT业务运营商可以是电信运营商或者其他企业。
具体地,如图1所述,表示一种由IOT平台和IOT网关为设备提供升级服务的流程图。进一步地,该升级方法包括以下步骤:
1.IOT业务运营商/设备厂商/软件厂商通过业务提供商门户(Service ProviderPortal,SP Portal)向IOT平台上传升级包;
2.IOT业务运营商/设备厂商/软件厂商在SP Portal上选择待升级IOT设备,并进行设备升级任务和策略的配置;
3.SP Portal下发升级任务到IOT平台;
4.IOT平台接收升级任务,并根据自身存储的设备信息确定待升级IOT设备,以及与该待升级IOT设备连接的IOT网关,并下发升级任务到待升级IOT设备连接的IOT网关;
5.IOT网关下发升级任务到待升级IOT设备;
6.IOT设备向IOT网关请求升级包;
7.IOT网关向IOT平台请求升级包;
8.IOT平台发送升级包给IOT网关;
9.IOT网关发送升级包给IOT设备;
10.IOT设备升级并重启;
11.IOT设备向IOT网关上报升级结果;
12.IOT网关向IOT平台上报升级结果;
13.IOT业务运营商/设备厂商/软件厂商查询IOT设备的升级结果。
在上述IOT设备升级的过程中,IOT平台为整个IOT系统的中心,一旦发生故障将可能会影响IOT平台,进而可能导致IOT设备升级业务的中断。而IOT系统通常为大规模系统(包含数亿级IOT设备),从而更难以保证IOT设备升级系统的健壮性(Robustness)。其中,计算机科学中,健壮性是指一个计算机系统在执行过程中处理错误,以及算法在遭遇输入、运算等异常时继续正常运行的能力。
发明内容
本申请提供了一种设备升级方法和装置,以提高设备升级系统的稳健性。
本申请提供的技术方案基于区块链构建开放的设备升级系统,在企业需要设备升级时通过其关联的应用节点请求变更区块链上待升级IOT设备的固件/软件包的期望版本号。IOT网关监控本地账本中自己所管理的IOT设备的固件/软件包的期望版本号的变更,确定待升级设备,向待升级设备下发升级任务。
此外,通过区块链的通道机制,企业之间自由结组,形成与组外企业的隔离的设备升级系统。每个固件/软件包的期望版本号变更请求通过组内节点的验证,并记录在对组内公开的区块链共享账本中,防止信息被篡改并且保证升级系统的稳健性。
具体地,公开了以下技术方案:
第一方面,本申请提供了一种IOT设备升级方法,该方法应用于基于区块链构建的设备升级系统,所述方法包括:物联网IOT网关获取升级请求,所述升级请求中包括升级包的第一期望版本号;所述IOT网关根据所述第一期望版本号对第一设备集合中的至少一个设备的期望版本号进行更新,并将更新后包括所述第一期望版本号的至少一个更新结果记录在区块链的本地账本上;所述IOT网关通过所述本地账本中记录的至少一个更新结果的第一期望版本号确定待升级设备;以及,向所述待升级设备发送升级任务,以使所述待升级设备按照所述第一期望版本号更新自身的版本号。
本方面提供的方法,基于区块链的共识机制和分布式账本功能,通过升级请求对设备的固件/软件包的期望版本号进行更新,以使本地账本中记录的设备的期望版本号保持刷新状态,然后再通过更新的期望版本号确定待升级设备,由于这些设备信息是保存在区块链本地共享账本中,所以获取的第一期望版本号不受限于某一个设备,例如IOT平台,所以能够避免某一网元设备发生故障时,影响全网的IOT设备升级,本方法提高了设备升级系统的稳健性。
结合第一方面,在第一方面的一种可能的实现中,所述IOT网关对第一设备集合中的至少一个设备的期望版本号进行更新,包括:所述IOT网关获取其所管理的所有设备的设备ID;根据所述设备ID在所述第一设备集合中筛选出需要更新的至少一个设备;以及,在所述需要更新的至少一个设备的第二期望版本号小于所述第一期望版本号的情况下,将所述需要更新的至少一个设备的第二期望版本号替换为所述第一期望版本号。
本实现方式中,IOT网关根据其所管理的设备的设备ID和第一设备集合中的设备ID来确定需要更新期望版本号的设备,从而保证IOT网关所管理的待升级设备都能完成升级,提高了升级效率。
结合第一方面,在第一方面的另一种可能的实现中,所述IOT网关确定待升级设备的过程,包括:所述IOT网关获取所述第一设备集合中的至少一个设备的实际版本号;比较每个更新结果中的第一期望版本号是否大于设备对应的实际版本号,如果大于,则确定所述设备为所述待升级设备。
结合第一方面,在第一方面的又一种可能的实现中,所述升级请求中还包括第一设备群组标识,即第一设备群组ID,在所述IOT网关对第一设备集合中的至少一个设备的期望版本号进行更新之前,所述方法还包括:
所述IOT网关判断所述第一设备群组标识与记录在所述本地账本中的每个设备的第二群组标识是否相同;如果相同,则将所述第一设备群组标识或第二设备群组标识所指示的设备作为所述第一设备集合中的设备。
结合第一方面,在第一方面的又一种可能的实现中,所述IOT网关向所述待升级设备发送升级任务之后,所述方法还包括:
所述IOT网关获取升级包的名称,所述升级包的名称可通过应用节点提交的设备升级交易提案预先记录在本地账本中,然后IOT网关从该本地账本中获取所述升级包的名称,所述升级包的名称与第一期望版本号,设备ID具有对应关系。
所述IOT网关根据所述升级包的名称确定记载在所述本地账本的,且与所述升级包的名称对应的包下载地址和包哈希值;根据所述包下载地址获取升级包,以及根据所述包哈希值对所述升级包进行验证;以及,将验证通过的升级包发送给所述待升级设备。
本实现方式中,IOT网关通过升级包名称获取对应的升级包,并通过哈希值对升级包进行验证,从而保证了下发给待升级设备的包的正确性和安全性。
结合第一方面,在第一方面的又一种可能的实现中,所述方法还包括:所述IOT网关获取所述待升级设备反馈的升级结果,所述升级结果中包括所述待升级设备升级后的实际版本号,所述升级后的实际版本号与所述第一期望版本号相同;将所述升级后的实际版本号通过交易提案发送给设备管理节点;在接收到所述设备管理节点根据所述交易提案反馈的验证通过的消息之后,将所述待升级设备升级到所述实际版本号的交易记录在所述区块链的本地账本上。
第二方面,本申请还提供了一种设备升级方法,所述方法包括:设备管理节点获取来自至少一个应用节点的至少一个交易,其中,每个所述交易包括升级包的第一期望版本号;向IOT网关发送携带有所述升级包的第一期望版本号的升级请求,所述升级请求用于指示IOT网关对第一设备集合中的至少一个设备的期望版本号进行更新。
本方面中,设备管理节点通过接收来自应用节点的,且携带有第一期望版本号的交易,使得IOT网关能够动态地更新区块链中本地账本的设备信息,并且设备管理节点将携带有第一期望版本号的升级请求下发给IOT网关,使得IOT网关根据该第一期望版本号对待升级设备进行升级。由于所有信息都被记录在区块链的本地账本中,所有不会因为某一设备的故障影响整个设备升级系统,从而提高设备升级系统的稳健性。
结合第二方面,在第二方面的一种可能的实现中,所述设备管理节点向IOT网关发送升级请求的过程,包括:设备管理节点对所述至少一个交易进行排序,并按照所述排序结果生成新的区块;设备管理节点广播区块链更新请求,所述区块链更新请求用于指示IOT网关在本地账本中增加设备升级交易;以及,向所述IOT网关发送所述升级请求,所述升级请求中包括所述升级包的第一期望版本号。
结合第二方面,在第二方面的另一种可能的实现中,所述设备管理节点向所述IOT网关发送所述升级请求之后,所述方法还包括:设备管理节点接收IOT网关发送的设备信息更新交易提案,所述设备信息更新交易提案是通过待升级设备升级成功后获得的;所述设备管理节点根据所述设备信息更新交易提案进行背书,并生成第一背书结果;以及,向所述IOT网关发送所述第一背书结果。
结合第二方面,在第二方面的又一种可能的实现中,所述方法还包括:设备管理节点获取来自所述IOT网关的设备信息更新交易提案结果,所述设备信息更新交易提案结果为验证通过背书阶段的第一背书结果;设备管理节点将所述设备信息更新交易提案结果相关的交易记录在区块链的本地账本上;其中,所述设备信息更新交易提案结果相关的交易包括将所述待升级设备的升级包名称对应的实际版本号变更为所述第一期望版本号。
结合第二方面,在第二方面的又一种可能的实现中,所述设备管理节点获取来自至少一个应用节点的至少一个设备升级的交易之前,所述方法还包括:设备管理节点获取来自所述应用节点的设备升级交易提案,所述设备升级交易提案中包括链码ID和函数名;根据所述链码ID和函数名执行智能合约函数,得到执行结果,并对所述执行结果进行背书生成第二背书结果;将所述第二背书结果发送给所述应用节点,以使所述应用节点根据所述第二背书结果生成设备升级的交易。
需要说明的是,本方面所述的设备管理节点可以是一个设备管理节点,还可以是多个设备管理节点,例如,用于对交易进行排序和提交的设备管理节点,可称为提交节点;,以及用于执行背书的设备管理节点,可称为背书节点。其中,所述提交节点和背书节点是区块链节点在不同交易处理阶段的不同称谓。所述区块链系统中的所有节点都可以称为提交节点,可选的,所述背书节点可以是提交节点的子集。
所述提交节点用于对区块链中的交易进行验证,并将验证通过的交易封装成区块后,添加到区块链本地账本中。
第三方面,本申请还提供了一种设备升级方法,该方法适用于应用节点来执行,所述应用节点可以是某一企业,负责在企业需要设备升级时,请求更新区块链中IOT设备的固件/软件包的期望版本号、下载地址和哈希值等。
其中,所述固件/软件包是升级包的一种,即所述升级包包括对固件升级的升级包,和/或,包括对软件升级的升级包,还可以包括其它升级包,本申请对此不具体限制。
所述设备升级方法包括:应用节点确定设备升级的至少一个交易,其中,每个所述交易包括升级包的第一期望版本号;所述应用节点向设备管理节点发送所述至少一个交易,以使所述设备管理节点根据所述交易中的第一期望版本号对待升级设备的版本号进行更新。
结合第三方面,在第三方面的一种可能的实现中,所述应用节点确定设备升级的至少一个交易,包括:应用节点创建设备升级交易提案,所述设备升级交易提案中包括链码ID和函数名;向选择的至少一个设备管理节点发送所述设备升级交易提案;接收所述选择的至少一个设备管理节点根据所述设备升级交易提案中的链码ID和函数名反馈的至少一个第二背书结果;并根据所述至少一个第二背书结果生成设备升级的至少一个交易。
结合第三方面,在第三方面的另一种可能的实现中,所述应用节点根据所述至少一个第二背书结果生成设备升级的至少一个交易,包括:所述应用节点根据背书策略对所述至少一个第二背书结果进行验证,并根据统计的经过验证阶段的至少一个第二背书结果,生成所述设备升级的至少一个交易。
第四方面,本申请还提供了一种设备升级装置,例如所述装置可以是一种IOT网关,其中,所述装置中包括用于执行上述第一方面以及第一方面的各种实现方式中方法步骤的单元。
具体地,所述装置包括获取模块、处理模块和发送模块,此外,还可以还包括存储模块等其他单元或模块等。
进一步地,所述处理模块中可以包括:智能合约模块、交易提交模块、本地账本记录模块、下载验证模块和设备管理模块等。
第五方面,本申请还提供了一种设备升级装置,例如所述装置可以是一种设备管理节点或者设备管理装置,其中,所述装置中包括用于执行上述第二方面以及第二方面的各种实现方式中方法步骤的单元。
具体地,所述装置包括获取模块、处理模块和发送模块,此外,还可以还包括存储模块等其他单元或模块等。
进一步地,所述处理模块中可以包括:交易背书模块、交易提交模块、交易排序模块、智能合约模块和本地账本记录模块等。
第六方面,本申请还提供了一种设备升级装置,例如所述装置可以是一种应用节点,其中,所述装置中包括用于执行上述第三方面以及第三方面的各种实现方式中方法步骤的单元。
具体地,所述装置包括接收模块、处理模块和发送模块,此外,还可以还包括存储模块等其他单元或模块等。
第七方面,本申请还提供了一种网络设备,所述网络设备包括处理器,收发器和存储器,该网络设备可以一种设备升级装置,例如可以是应用节点、设备管理节点、IOT网关,另外还可以是IOT设备。
可选的,在所述网络设备为IOT网关的情况下,所述收发器,用于获取升级请求,所述升级请求中包括升级包的第一期望版本号;所述处理器,用于根据所述第一期望版本号对第一设备集合中的至少一个设备的期望版本号进行更新,并将更新后包括所述第一期望版本号的至少一个更新结果记录在区块链的本地账本上;通过所述本地账本中记录的至少一个更新结果的第一期望版本号确定待升级设备;所述收发器,还用于向所述待升级设备发送升级任务,以使所述待升级设备按照所述第一期望版本号更新自身的版本号。
此外,所述处理器和收发器还用于实现前述第一方面中的其它各种实现的功能。
可选的,在所述网络设备为设备管理节点的情况下,所述收发器,用于获取来自至少一个应用节点的至少一个交易,其中,每个所述交易包括升级包的第一期望版本号;以及,向IOT网关发送携带有所述升级包的第一期望版本号的升级请求,所述升级请求用于指示IOT网关对第一设备集合中的至少一个设备的期望版本号进行更新。
此外,所述处理器和收发器还用于实现前述第二方面中的其它各种实现的功能。
可选的,在所述网络设备为应用节点的情况下,所述处理器,用于确定设备升级的至少一个交易,其中,每个所述交易包括升级包的第一期望版本号;所述收发器,用于向设备管理节点发送所述至少一个交易,以使所述设备管理节点根据所述交易中的第一期望版本号对待升级设备的版本号进行更新。
此外,所述处理器和收发器还用于实现前述第三方面中的其它各种实现的功能。
可选的,在所述网络设备为IOT设备的情况下,所述收发器,用于接收来自IOT网关的升级任务,以及对应的升级包,所述处理器,用于升级和重启设备,将设备的实际版本号更新为所述第一期望版本号,生成升级结果;所述收发器,还用于将所述升级结果发送给所述IOT网关。
第八方面,本申请还提供了一种计算机存储介质,该计算机存储介质可存储有程序,该程序执行时可实现上述各个方面中,包括本申请提供的IOT设备升级方法各实施例中的部分或全部步骤。
第九方面,本申请还提供了一种计算机程序产品,所述计算机程序产品包括一个或多个计算机指令,例如设备升级指令。在计算机加载和执行所述计算机程序时,可实现包括本申请提供的IOT设备升级方法各实施例中的部分或全部步骤。
第十方面,本申请还提供了一种设备升级系统,所述系统中包括:至少一个应用节点、至少一个设备管理节点、至少一个IOT网关和待升级IOT设备,此外,还包括升级包下载服务器,该服务器可以配置在设备管理节点或者IOT网关上。
其中,可选的,所述IOT网关可以是上述第四方面以及第四方面各种实现方式中的设备升级装置,所述设备管理节点可以是上述第五方面以及第五方面各种实现方式中的设备升级装置,所述应用节点可以是上述第六方面以及第六方面各种实现方式中的设备升级装置,所述IOT设备可以是终端。
本申请提供的设备升级方法和装置,本方法实现了分布式的IOT设备升级控制,保证IOT设备升级系统的健壮性:任何IOT网关出现故障,不会影响其他IOT网关的升级任务,而IOT网关故障恢复后可以从区块链网络恢复账本,继续中断的升级任务。
此外,本方法去掉了IOT平台的功能,将IOT设备的设备信息保存在区块链的共享账本中,各方从区块链共享账本中获取设备信息,例如设备期望版本号和实际版本号等,通过IOT网关、设备管理节点包含关联通道的本地账本,使得IOT网关故障恢复后可以从区块链网络恢复本地账本,进而恢复升级任务,容错性好。
附图说明
图1为本申请提供的一种设备升级方法的流程图;
图2为本申请实施例提供的一种应用场景的结构示意图;
图3为本申请实施例提供的另一种应用场景的结构示意图;
图4为本申请实施例提供的一种设备管理节点的结构示意图;
图5为本申请实施例提供的一种IOT网关的结构示意图;
图6为本申请实施例提供的一种设备升级方法的流程图;
图7为本申请实施例提供的另一种设备升级方法的流程图;
图8a为本申请实施例提供的一种设备升级方法的第一阶段的流程图;
图8b为本申请实施例提供的一种设备升级方法的第二阶段的流程图;
图8c为本申请实施例提供的一种设备升级方法的第三阶段的流程图;
图9为本申请实施例提供的一种设备管理智能合约加载的流程图;
图10为本申请实施例提供的另一种IOT网关的结构示意图;
图11为本申请实施例提供的另一种设备管理节点的结构示意图;
图12为本申请实施例提供的一种应用节点的结构示意图;
图13为本申请实施例提供的一种网络设备的结构示意图。
具体实施方式
在对本申请实施例的技术方案说明之前,首先对本申请实施例中涉及的技术术语和应用场景进行介绍和说明。
本申请各实施例提供的技术方案应用于基于区块链构建的开放的设备升级系统。在介绍本申请的设备升级系统之前,首先,对区块链和区块链的特征做简单的介绍。
所述区块链(Block Chain)是一种分布式数据库,起源自比特币,是比特币的底层技术。区块链是一串使用密码学方法相关联产生的数据块,每一个数据块中包含了一次比特币网络交易的信息,用于验证其信息的有效性(防伪)和生成下一个区块(block)。
狭义来讲,区块链是一种按照时间顺序将数据区块以顺序相连的方式组合成的一种链式数据结构,并以密码学方式保证的不可篡改和不可伪造的分布式账本。广义来讲,区块链是一个分布式的账本,通过多个独立的分布式节点保存相同的记录。
区块链技术是一种通过去中心化、去信任的方式集体维护一个可靠数据库的技术方案。每当有新的数据需要写入区块链时,这些数据会汇总到一个区块中,添加在已有区块链的末端,通过共识算法保证每个节点新添加的区块是完全相同的。
其中,每个区块内记录了若干条交易记录,同时包含了前一个区块的哈希值(hash),所有区块就是通过这样保存前一个块中的信息,按顺序相连,组成了区块链,难以被篡改。基于区块链技术,可以达成一致的双方直接交易(Transaction,Tx),从而不需要可信赖的第三方中心化中介机构的参与。
智能合约(smart contract)是由事件驱动、具有状态的、运行在一个分布式区块链账本之上的、且能够管理账本上数据的程序。智能合约可以看作是一段普通的计算机执行程序,满足可准确自动执行即可。智能合约的代码内容规定了交易的规则和逻辑,使用者签署调用智能合约就意味着合约内容会被执行并写入区块链账本。
区块链的核心技术之一就是共识算法,例如比特币中所使用的工作量证明(Proofof Work,PoW)算法。区块链中的共识算法,要解决的是面向拜占庭容错的共识场景,即区块链网络中的节点相互之间并不信任,有可能存在恶意说谎节点。区块链网络中的每个节点都有可能是“说谎”的节点,但是众多的节点聚到一个网络中,它们共识的结果就是一个可信的结果。共识算法的主要作用,就是让区块链中的所有节点记录相同的有效交易区块内容。
另外,区块链还是一种解决多方之间信任问题的技术机制。多方信任的前提是技术机制本身就是可信的,因此区块链需要可审计。区块链系统、智能合约和共识算法在多方之间是必须要开源公开。
本申请的技术方案以区块链的特征为基础,构建了一种开放的设备升级系统。该系统所对应的应用场景如下:
IOT业务运营商、设备厂商、软件厂商组成联盟,基于区块链和智能合约技术制定设备升级的公共协议,通过应用节点、设备管理节点和IOT网关配套实现设备升级。IOT业务运营商/设备厂商/软件厂商按照联盟制定的公共协议构建应用节点、设备管理节点和IOT网关并接入系统,从而构建一个开放的设备升级系统。
实际应用时,可能由若干个大型企业提供设备管理节点和IOT网关,小型企业只构建应用节点,并与至少一个设备管理节点/IOT网关绑定;或者两个小型企业共同构建设备管理节点/IOT网关。
举例说明,如图2所示,IOT业务运营商、设备厂商1、设备厂商2、设备厂商3、软件厂商1、软件厂商2组成一个联盟,共同构建设备升级系统。所有企业各自构建应用节点。其中,设备厂商1构建设备管理节点2,设备厂商2和设备厂商3共同构建设备管理节点3。IOT业务运营商构建设备管理节点1和全部的IOT网关。软件厂商1和软件厂商2与设备管理节点1绑定。IOT网关用于服务于所有企业。
需要说明的是,图2仅仅示出了一种可能的应用场景,还可以根据商业环境的不同,系统的构建存在多种可能性,比如IOT网关可以由某个设备厂商提供,本申请对各种相关应用场景不做具体限制。
在一个联盟中,企业之间也可以自由结成组,通过通道(channel)机制实现与组外企业的隔离,通道中的链码(chaincode)和交易只对于加入该通道的节点可见,一个节点可以加入多个通道,并为不同通道单独维护一个账本。因此,在上述系统也可以包含多家IOT业务运营商。比如包含IOT SP1和IOT SP2。
在一种商业环境中,IOT SP1可以跟关联设备厂商、软件厂商组成channel1,IOTSP2可以跟关联设备厂商、软件厂商组成channel2;在另一种商业环境中,也可以是设备厂商1和IOT SP1、IOT SP2组成channel1,IOT SP1和设备厂商2、设备厂商3、关联软件厂商组成channel2,IOT Sp2和和设备厂商2、设备厂商3、关联软件厂商组成channel3。根据企业在商业中主导地位,可以组成不同的channel,本申请对此不予限制。
如图3所示,本实施例提供的设备升级系统中包括:至少一个应用节点,每个应用节点构建一个设备管理节点,至少一个IOT网关,每个IOT网关关联至少一个IOT设备。
进一步地,所述应用节点,可以是属于某个企业,用于在企业需要设备升级时,请求更新区块链中IOT设备的固件/软件期望版本号、固件/软件包的下载地址和Hash值,以及向设备管理节点发送交易提案。
设备管理节点,用于在应用节点或IOT网关请求更新区块链网络过程中,对设备更新相关的交易进行验证、排序,并将排好序的交易封装到区块中并请求更新区块链。
如图4所示,具体过程为,设备管理节点在接收到应用节点发送的交易提案后,交易背书模块401,解析该交易提案,获得设备管理智能合约的chaincode ID、设备升级函数的函数名和参数等信息,然后将这些信息发送给智能合约模块404。
智能合约模块404,执行智能合约函数,输出执行结果,然后对该执行结果进行背书,并返回给应用节点或IOT网关提案结果。应用节点收集提案结果,验证每个交易是否通过背书阶段,并将验证后的结果发送给设备管理节点。
交易排序模块403,对该所有交易进行排序,然后将排好序的交易封装到区块中,并请求更新区块链,设备管理节点收到区块链更新请求后,交易提交模块402,对区块中的交易进行验证并在验证通过后加入本地账本记录模块405中。
IOT网关,用于在接收到区块链更新请求(或升级请求)时,更新本地账本,并根据本地账本中新增的设备升级交易确定待升级IOT设备,获取固件/软件包,对固件/软件包进行验证,向待升级IOT设备下发设备升级任务和固件/软件包;以及,在接收到IOT设备上报的升级结果后,且该升级结果为成功时,请求更新区块链中IOT设备的实际版本号。
如图5所示,所述IOT网关可以包括:智能合约模块501、交易提交模块502、本地账本记录模块503、下载验证模块504和设备管理模块505,此外,还可以包括其它模块,本实施例对此不予限制。
具体地,各个模块的功能如下:
交易提交模块502,用于在接收到区块链更新请求(或升级请求)后,对区块中的交易进行验证并在验证通过后将交易加入本地账本记录模块503中,如果交易为设备升级交易,则触发设备管理模块505从本地账本中,获取其所管理的IOT设备的固件/软件期望版本号和实际版本号,并对这两个版本号进行比对,如果期望版本号大于实际版本号,则确定IOT设备为待升级设备,然后向其下发升级任务。
另外,设备管理模块505,还用于从本地账本记录模块503中获取期望版本号对应的固件/软件包下载地址和Hash值,然后触发下载验证模块504根据固件/软件包下载地址获取固件/软件包,计算获取到的固件/软件包的Hash值并与设备管理模块505从本地账本中Hash值对比;如果两者一致,则确定固件/软件包验证通过,将其下发给IOT设备。收到IOT设备上报的升级结果且升级结果为成功时,设备管理模块505更新区块链中IOT设备的实际版本号。
IOT设备,用于接收IOT网关下发的升级任务和固件/软件包,执行升级任务以及上报升级结果。
进一步地,如图6所示,本实施例提供的设备升级方法,包括:
步骤601:IOT网关获取升级请求,所述升级请求中包括升级包的第一期望版本号。
可选的,所述升级请求中还可以包括:设备管理智能合约的chaincode ID、函数名、设备群组ID、升级包名称等中的一项或多项。
步骤602:IOT网关根据第一期望版本号对第一设备集合中的至少一个设备的期望版本号进行更新,并将更新后包括所述第一期望版本号的至少一个更新结果记录在区块链的本地账本上。
进一步地,步骤602中具体包括:IOT网关确定第一设备集合中的至少一个设备。
IOT网关获取设备群组标识,其中,每个所述群组标识对应一个设备,所述第一设备集合中的所有设备的群组标识都相同。
可选的,所述第一设备群组标识可以通过升级请求携带。
IOT网关通过区块链的本地账本获取记录在所述本地账本中的每个设备的第二群组标识,判断每个设备的第二群组标识与所述第一群组标识是否相同,如果相同,则该第一设备群组标识或第二设备群组标识所指示的设备作为所述第一设备集合中的设备;如果不相同,则该设备不属于所述第一设备集合中的至少一个设备。
进一步地,在步骤602中,对所述第一设备集合中的至少一个设备进行期望版本号的更新,具体还包括:
IOT网关获取其所管理的所有设备的设备ID,然后,根据所述设备ID在所述第一设备集合中筛选出需要更新的至少一个设备,再对所述需要更新的至少一个设备的期望版本号进行更新。例如,所述IOT网关在第一设备集合和其所管理的设备中确定第二设备集合,所述第二设备集合为第一设备集合和其所管理的设备的交集,即具有相同的设备ID,然后再对所述第二设备集合中的至少一个设备的期望版本号进行更新。
IOT网关在确定第二设备集合之后,将升级请求中携带的第一期望版本号替换为本地账本中记录的设备的原期望版本号,比如第二期望版本号。例如,对于设备A,其在本地账本中记录的期望版本号(第二期望版本号)为V10.1,升级请求中携带的第一期望版本号为V10.2,所以IOT网关将该设备A的第二期望版本号V10.1更新为第一期望版本号V10.1,并将更新后的第一期望版本号的更新结果记录在本地账本中。
步骤603:IOT网关通过所述本地账本中记录的至少一个更新结果的第一期望版本号确定待升级设备。
具体确定待升级设备的过程包括:IOT网关获取第一设备集合中的至少一个设备的实际版本号,所述实际版本号可以通过本地账本中获得。IOT网关比较每个更新结果中的第一期望版本号是否大于设备对应的实际版本号,如果大于,则确定所述设备为所述待升级设备。
例如,对于设备A而言,其在本地账本中记录的实际版本号是V10.0,而更新后的期望版本号是V10.2,实际版本号小于期望版本号,则确定设备A为带升级设备。
可选的,所述记录在本地账本中的期望版本号和实际版本号可以通过设备信息保存和记录,所述设备信息为登记在区块链上的一个设备所包含的信息。例如,设备A的设备信息包括:设备A标识、设备A群组ID、实际版本号、期望版本号、设备A上的固件/软件包的ID等信息。
此外,所述设备信息中还可以包括其它信息,具体包含的内容会在下面的实施例中详细介绍。
步骤604:IOT网关向所述待升级设备发送升级任务,以使所述待升级设备按照所述第一期望版本号更新自身的版本号。
IOT网关根据本地账本中确定的待升级设备的设备信息,例如设备标识确定其目的地址,并向该待升级设备下发升级任务,以指示该设备进行固件/软件包升级操作。
所述升级任务可以是一种消息,该消息中可以包括消息内容,例如包括升级包或者升级包对应的下载地址,还可以不携带任何内容,仅起到指示设备升级的作用。
本实施例提供的方法,基于区块链的共识机制和分布式账本功能,通过升级请求对设备的固件/软件包的期望版本号进行更新,以使本地账本中记录的设备的期望版本号保持刷新状态,然后再通过更新的期望版本号确定待升级设备,由于这些设备信息是保存在区块链本地共享账本中,所以获取的第一期望版本号不受限于某一个设备,例如IOT平台,所以能够避免某一网元设备发生故障时,影响全网的IOT设备升级。
本实施例中,上述步骤604之后,所述方法还包括:
IOT网关获取升级包的名称,根据所述升级包的名称确定记载在所述本地账本的,且与所述升级包的名称对应的包下载地址和包哈希值;根据所述包下载地址获取升级包,以及根据所述包哈希值对所述升级包进行验证,以及,将验证通过的升级包发送给所述待升级设备。
其中,所述升级包的名称是从记录在区块链的本地账本中获得,进一步地,该升级包的名称是应用节点在创建设备升级交易提案时,第一期望版本号对应的升级包的名称。
进一步地,所述根据包哈希值对升级包进行验证,包括:计算所述升级包的哈希值,比较所述升级包的哈希值与记录在本地账本中的升级包对应的包哈希值是否相同,如果相同,则该升级包通过验证;否则,不通过验证。
本方法中通过升级包的名称获取升级包对应的哈希值,并通过该哈希值对升级包进行验证,进而保证下发给待升级设备的升级包的安全性和可靠性。
可选的,所述方法还包括:IOT网关更新和记录IOT设备的升级情况,并将该升级的交易事件记录在区块链上。
具体地过程包括:IOT网关获取待升级设备反馈的升级结果,所述升级结果中包括所述待升级设备升级后的实际版本号,所述升级后的实际版本号与第一期望版本号相同;IOT网关将所述升级后的实际版本号通过交易提案发送给设备管理节点;在接收到所述设备管理节点根据所述交易提案反馈的验证通过的消息之后,将所述待升级设备升级到所述实际版本号的交易记录在所述区块链的本地账本上。
需要说明的是,本实施例中,所述区块链的本地账本包括所有记录在区块链上的设备的设备信息,则在步骤602中,所述的第一设备集合中的至少一个设备,包括区块链上本地账本中记录的所有设备中的第一设备集合。
或者,所述本地账本包括IOT网关所管理的所有设备的设备信息,则确定的需要进行期望版本号更新的设备为第一设备集合与IOT网关所关联的所有设备的交集,即第二设备集合中的设备。
对应于上述IOT网关的方法实施例,本申请还提供了一种IOT设备升级方法,该方法可应用于至少一个设备管理节点。
如图7所示,所述方法还包括:
步骤701:设备管理节点获取来自至少一个应用节点的至少一个交易,其中,每个所述交易中包括升级包的第一期望版本号。
此外,所述交易中还包括:调用的函数名和参数信息,所述调用的函数名用于指示所述交易用于设备升级,所述参数信息包括升级包的名称。可选的,所述升级包的第一期望版本号可以配置在所述参数信息中。
具体地,在获取来自至少一个应用节点的至少一个交易之前,所述方法还包括:
设备管理节点获取来自至少一个应用节点的设备升级交易提案,所述设备升级交易提案中包括Chaincode ID和函数名,此外,还可以包括设备群组ID,升级包名称和期望版本号等信息。设备管理节点根据所述设备升级提交提案中的Chaincode ID和函数名执行智能合约函数,得到执行结果,并对所述执行结果进行背书生成第二背书结果;所述设备管理节点将所述第二背书结果发送给所述应用节点,以使所述应用节点根据所述第二背书结果生成至少一个设备升级的交易。
步骤702:设备管理节点对所述至少一个交易进行排序,并按照所述排序结果将所有交易封装成区块,即形成新的区块。
步骤703:设备管理节点广播区块链更新请求,所述区块链更新请求用于指示IOT网关在本地账本中增加设备升级交易。
步骤704:设备管理节点向所述IOT网关发送升级请求,所述升级请求中包括所述升级包的第一期望版本号。
此外,所述方法还包括:
设备管理节点接收IOT网关发送的设备信息更新交易提案,所述设备信息更新交易提案是通过待升级设备升级成功后获得的。
其中,所述设备信息更新交易提案中包括:升级设备的设备标识(即设备ID)、升级后的版本号,即第一期望版本号,也是当前实际的版本号,还包括升级包的名称等信息。
具体地,IOT网关接收到所述升级请求之后,确定至少一个待升级设备,并向所述至少一个待升级下发升级包,每个待升级设备进行固件/软件包的升级,然后,向IOT网关反馈设备信息更新交易提案,以更新升级设备的实际版本号。
具体地,所述IOT网关的执行步骤参见前述实施例图6以及方法步骤601至步骤604的描述,此处不详细赘述。
设备管理节点根据所述设备信息更新交易提案进行背书,并生成第一背书结果。
设备管理节点向所述IOT网关发送所述第一背书结果,以使IOT网关对所有第一背书结果进行验证,验证其是否通过背书阶段。
此外,所述方法还包括:设备管理节点获取来自所述IOT网关的设备信息更新交易提案结果,所述设备信息更新交易提案结果为验证通过背书阶段的第一背书结果,并对这些交易提案进行排序并封装成新的区块。设备管理节点广播区块链更新请求,以使接收的IOT网关将所述设备信息更新交易提案结果相关的交易记录在所述本地账本上。
其中,所述设备信息更新交易提案结果相关的交易包括将所述待升级设备的升级包名称对应的实际版本号变更为所述第一期望版本号。
需要说明的是,本实施例中,设备管理节点可以是一个设备管理节点,具备交易排序功能和背书功能;也可以是不同的设备管理节点,即一种设备管理节点用于对交易进行排序和封装区块,另一种设备管理节点用于对背书以及对背书结果进行验证。此外,还可以根据不同的功能区分成更多的设备管理节点,本申请各个实施例对完成IOT设备升级方法所需要的设备管理节点的个数不进行限制。
对应于前述IOT网关和设备管理节点的实施例,本申请提供的设备升级方法,对于应用节点侧,具体包括以下步骤:
应用节点确定设备升级的至少一个交易,其中,每个所述交易包括升级包的第一期望版本号。
应用节点向设备管理节点发送所述至少一个交易,以使所述设备管理节点根据所述交易中的第一期望版本号对待升级设备的版本号进行更新。
进一步地,所述应用节点确定设备升级的至少一个交易,包括:应用节点创建设备升级提交提案,其中,所述设备升级提交提案中包括Chaincode ID和函数名,此外,还可以包括:设备标识,设备群组标识,升级包名称,升级包的期望版本号等信息,且这些信息可以统称为设备信息。
应用节点选择至少一个设备管理节点,并向选择的至少一个设备管理节点发送所述设备升级交易提案;每个选择的设备管理节点接收到该设备升级交易提案之后执行智能合约中的函数,并对执行结果进行背书,生成对应的背书结果,例如第二背书结果。
应用节点接收所述选择的至少一个设备管理节点根据所述设备升级交易提案中的Chaincode ID和函数名反馈的至少一个第二背书结果,并根据所述至少一个第二背书结果生成设备升级的至少一个交易,其中,每个所述交易中包括调用的函数名和参数信息,所述调用的函数名用于指示所述交易用于设备升级,所述参数信息包括升级包的名称和升级包的第一期望版本号。
进一步地,所述应用节点根据所述至少一个第二背书结果生成设备升级的至少一个交易,包括:应用节点根据背书策略对所述至少一个第二背书结果进行验证,并根据统计的经过验证阶段的至少一个第二背书结果,生成所述设备升级的至少一个交易。
其中,所述背书策略包括:接收到x%所选择的至少一个设备管理节点的提案结果(交易),并且其中的智能合约执行结果一致,则确定该交易通过背书阶段验证,其中,x的取值范围为[51,100]。
下面结合具体的实施例对本申请提供的IOT设备升级方法进行详细地介绍和说明。
如图8a所示,在登记好升级包(即固件/软件包)信息后,可以开始启动设备升级流程。其中,关于固件/软件包、设备的登记以及智能合约的加载过程会在后面的实施例中详细介绍。
第一阶段,新增区块阶段(包括步骤801至步骤807)。
步骤801:企业关联的应用节点可以作为客户端,创建设备升级交易提案。
其中,所述设备升级交易提案包:设备管理智能合约的chaincode ID、函数名、设备群组ID(group ID)和参数信息等。所述参数信息中包括第一期望版本号和升级包名称等。
可选的,所述函数名为upgrade Device,用于指示该提案是设备升级的提案交易。所述参数信息包括升级包的名称、升级包版本号(或称为第一期望版本号)等。
另外,应用节点还用于选择和确定至少一个设备管理节点。
步骤802:应用节点将设备升级交易提案发送给应用节点所选择的至少一个设备管理节点。
步骤803:设备管理节点作为背书节点在接收到来自应用节点的设备升级交易提案之后,执行如下操作:
设备管理节点根据交易提案中的chaincode ID、函数名确定要执行的智能合约函数。例如,该智能合约函数为设备管理智能合约中的设备升级函数,根据所述交易提案中的参数信息执行智能合约函数,得到包含读集和写集在内的执行结果,然后对执行结果进行背书,生成设备升级提案交易的提案结果。
其中,所述读集,即执行设备管理智能合约时从账本读取的数据;所述写集,即执行设备管理智能合约时向账本写入的数据。
进一步地,所述设备管理节点在执行智能合约函数时,需要以所述交易提案中的设备群组ID参数和升级包名称为键值从账本中读取的设备信息数据,再将其中的期望版本号修改为交易提案中包版本号参数的设备信息数据,以交易提案中的设备群组ID和升级包名称为键值写入账本。
在设备管理节点执行背书阶段时,由于设备管理节点的执行为模拟执行,所以数据不会被写入到本地账本,而是存放在写集中。通过读集定义读取的设备群组ID(作为key值)和设备管理结节点在本地账本中记录的key值,来保证设备管理节点读取相同的数据,通过定义写入的key值,保证所有节点写入相同的数据。
步骤804:设备管理节点将所述设备升级提案交易的提案结果,即包含读、写集在内的,设备管理节点经过签名后的执行结果发送给应用节点。
步骤805:应用节点接收各个设备管理节点反馈的提案结果,并验证各个提案结果是否通过背书阶段。
具体地,可以将每个所述提案结果作为一个提交设备升级的交易,并通过背书策略验证各个交易是否通过背书阶段。所述背书策略包括:接收到x%所选择的设备管理节点(背书节点)的提案结果(交易),并且,其中的智能合约执行结果一致,则确定该交易通过背书阶段,其中,x的取值范围为[51,100]。
例如,当应用节点获取的10个背书节点反馈的提案结果中,有7个背书节点执行结果都相同,大于50%,则验证该交易通过背书阶段,否则如果小于或等于50%,则不通过背书阶段。
步骤806:应用节点将验证通过的提交设备升级的至少一个交易发送给设备管理节点。
其中,所述交易中包括以下至少一项:交易标识、通道标识、智能合约标识、智能合约版本、调用的函数名(或者方法名)和参数信息、读集、写集、背书节点签名、应用节点签名。所述背书节点签名包括多个且对各个执行结果一致的背书节点的签名。
步骤807:设备管理节点作为排序节点,对获取的多个交易进行排序并按照排序将所有交易封装成区块。
表1
参见上表,Tx1、Tx2和TxN都表示一个交易,每个交易中包含的内容如表1所示。所述排序可以采用多种策略,一般地,采用先到者在前的策略进行排序。此外,还可以按照交易优先级进行排序,将优先级高的交易排列到前面,将优先级低的交易排到后面处理。另外,还可以采用其他排序策略对多个交易进行排序,本申请实施例对此不进行限制。
另外,每个区块中至少封装有一个交易。且区块的区块头部包含区块号、前一区块hash和本区块hash。所述区块号为前一个区块的区块号加1,通过前一区块hash与前一区块链上。
第二阶段,确定待升级设备和升级阶段(包括步骤808至步骤818)。
如图8b所示,包括:
步骤808:设备管理节点广播区块链更新请求,所述区块链更新请求用于指示接收的节点,例如IOT网关在本地账本中增加设备升级交易。
所述设备管理节点向IOT网关发送升级请求,其中,升级请求中包括:升级包的名称和升级包的第一期望版本号。此外,所述升级请求中还可以包括:设备管理智能合约的Channel ID、函数名、设备ID和设备群组ID等信息。
可选的,所述升级请求也可以是更新请求。
具体地,设备管理节点在封装完形成新的区块之后,会通知IOT网关要更新区块链,然后设备管理节点会在全网广播升级请求或者区块链更新请求。
可选的,所述升级请求或者区块链更新请求还可以为一个交易事件发送给IOT网关。
步骤809:区块链网络中的所有节点,包括设备管理节点和IOT网关,接收所述升级请求,然后根据该升级请求中携带的设备管理智能合约的Channel ID确定自己相关的交易,并对该交易进行验证,将验证通过的交易写入本地账本。
此时,在同一个通道关联的节点以及节点上该通道的账本中,交易(交易调用的函数参数)指定群组的IOT设备的设备信息中,IOT网关会将交易指定升级包的第二期望版本号均变更为交易指定的第一期望版本号(即升级包版本号),即对本地账本的期望版本号进行更新。使得更新后的设备的期望版本号与升级请求中携带的第一期望版本号相同。
可选的,在步骤809,IOT网关在更新至少一个设备的期望本编号的过程中,包括以下两种实现方式:
一种实现方式是,IOT网关对应用节点设定的第一设备集合中的至少一个设备的期望版本号进行更新。
另一种实现方式是,IOT网关对应用节点设定的第一设备集合中的至少一个设备,且属于该IOT网关管理范围内的设备进行期望版本号的更新。即被更新的设备为第一设备集合与IOT网关所管理的设备的交集对应的设备。
具体地,过程包括:IOT网关先确定第一设备集合中的所有设备,然后再判断该第一设备集合中的每个设备是否属于IOT网关的管理范围内,如果是,则该设备为需要更新期望版本号的设备。
另外,所述第一设备集合可以通过设备群组标识,例如设备群组ID来确定。例如,每个设备对应一个设备群组ID,并预先记录在本地账本中,如果所述升级请求中所携带的设备1的设备群组ID与本地账本中记录的设备群组ID相同,则该设备1为第一设备集合中的一个设备。此外,还可以通过其它方法确定第一设备集合中的至少一个设备,本实施例对此不进行限制。
步骤810:IOT网关确定本地账本中增加的设备升级交易。
其中,所述IOT网关可以根据设备升级交易中的chaincode ID和invoke method来确定新增的交易。
步骤811:IOT网关从本地账本中获取设备的设备信息,所述设备信息包括至少一个设备的实际版本号。此外,IOT网关还可以从区块链的本地账本中获取更新的至少一个设备的第一期望版本号;比较每个设备的第一期望版本号是否大于其对应的实际版本号,如果大于,则确定该设备为待升级IOT设备,并记录该IOT设备相应的升级包名称(packagename)。
其中,每个IOT设备对应一个期望版本号和一个实际版本号,所述期望版本号为需要更新的设备的版本号,是由应用节点通过设备升级交易提案携带和发送给设备管理节点的;所述实际版本号是记录在本地账本中的设备当前的版本号。
例如,应用节点在本地账本中获知设备A当前的实际版本号是9.0,而应用节点为将该设备1的版本号升级为10.0,所以,创建一个包括第一期望版本号为10.0的设备升级交易提案,并执行前述步骤801至步骤810,以触发设备A对版本进行升级操作。
步骤812:IOT网关向确定的待升级IOT设备下发升级任务。
步骤813:IOT网关从本地账本查询步骤811中记录的package name对应的包下载地址、包hash和包版本号。
步骤814:IOT网关根据所述包下载地址从固件/软件包下载服务器上获取升级包。
步骤815:IOT网关计算所述升级包的hash,并将该升级包的hash与从本地账本中获得的hash进行比较,如果结果相同,则所述升级包验证通过。
步骤816:IOT网关向待升级IOT设备下发所述升级包。
步骤817:IOT设备接收来自IOT网关的升级包,然后升级并重启,得到升级结果。
步骤818:IOT设备上报所述升级结果给IOT网关。
第三阶段,上报升级结果并更新区块链阶段(包括步骤819至步骤827)。
如图8c所示,上述方法还包括:
步骤819:IOT网关接收来自IOT设备的升级结果,确定所述IOT设备上报的升级结果为成功时,则创建设备信息更新交易提案。
其中,所述设备信息更新交易提案包含设备管理智能合约的Channel ID、函数名为update Device、函数参数为设备群组ID、设备ID、升级包名称、升级包版本等。
该交易提案用于修改区块链上至少一个设备的实际版本号。所述设备的设备ID和设备群组ID与函数参数中的设备群组ID、设备ID相同,所述实际版本号为函数参数中的升级包名称所对应的实际版本号,修改后的实际版本号与函数参数中的升级包版本相同。
步骤820:IOT网关将设备信息更新交易提案发送给所选择的用于背书的设备管理节点。所述设备信息更新交易提案中包括:更新后的期望版本号,即第一期望版本号,还包括设备ID、设备群组ID、chaincode ID、函数名、参数信息等内容。
其中,所述用于背书的设备管理节点可以与前述步骤807中的设备管理节点相同,也可以不同。
步骤821:设备管理节点根据所述设备信息更新交易提案中的参数执行智能合约函数,得到执行结果,并对该执行结果进行背书,得到每个设备信息更新交易提案对应的提案结果。
步骤822:设备管理节点向IOT网关发送设备信息更新交易提案的提案结果。
步骤823:IOT网关接收至少一个设备管理节点发送的设备信息更新交易提案的提案结果,并根据背书策略对所有提案结果进行验证,确定所述提案结果是否通过背书阶段。
步骤824:IOT网关对验证通过背书阶段的至少一个提案结果(交易)发送给设备管理节点。
步骤825:设备管理节点接收并对至少一个提案结果(交易)进行排序,并按照所述排序结果将所有的交易封装成新的区块。
步骤826:设备管理节点广播区块链更新请求,所述区块链更新请求用于触发区块链网络中的所有节点,例如设备管理节点和IOT网关对IOT设备升级后的交易上链。
步骤827:区块链网络中的所有节点,包括设备管理节点和IOT网关接收所述更新请求之后,根据所述更新请求中的channel ID确定自己相关的交易,并对交易进行验证,以及将验证通过的交易写入到区块链的本地账本上。
此时,同一个通道关联的节点以及节点上该通道的账本中,交易指定的IOT设备的设备信息中,交易指定的升级包名称对应的实际版本号均变更为交易指定的升级包版本,即将IOT设备的实际版本号升级为第一期望版本号的交易记录在区块链的本地账本上。
本实施例提供的设备升级方法,在企业需要设备升级时,通过其关联的应用节点请求变更区块链上待升级IOT设备的固件/软件包的期望版本号,IOT网关根据本地账本更新的期望版本号的变更情况来确定待升级设备,并向待升级设备下发升级任务。本方法实现了分布式的IOT设备升级控制,保证IOT设备升级系统的健壮性:任何IOT网关出现故障,不会影响其他IOT网关的升级任务,而IOT网关故障恢复后可以从区块链网络恢复账本,继续中断的升级任务。
此外,本方法去掉了IOT平台功能,将设备的设备信息保存在区块链的共享账本中,各方从区块链共享账本中获取设备信息,例如设备期望版本号和实际版本号等,通过IOT网关、设备管理节点包含关联通道的本地账本,使得IOT网关故障恢复后可以从区块链网络恢复本地账本,进而恢复升级任务,容错性好。
另外,每个固件/软件包的期望版本号变更请求通过通道内节点的验证,并记录在对组内公开的区块链共享账本中,以便在出现争议时可以进行追溯,方便多方参与。
需要说明的是,本实施例提供的方法,在第一阶段和第三阶段,设备管理节点执行背书和验证、以及交易排序和更新区块链的过程与现有的背书、更新过程相同,可以参考现有的方法流程,本实施例对此不详细赘述。
在上述实施例提供的方法中,在应用节点创建设备升级交易提案之前,还包括准备工作:具体地,所述准备工作可以包括:设备管理智能合约加载、固件/软件包信息登记和设备登记三个部分过程。
下面对这三部分过程分别进行介绍和说明。
一、设备管理智能合约加载
初始时,应用节点所属联盟/通道中的所有企业需要协商好由哪个企业的应用节点作为管理员,并预先定义设备管理智能合约,由管理员应用节点请求关联的设备管理节点和IOT网关加载该设备管理智能合约。
其中,所述设备管理智能合约中,包括以下信息:
A.设备信息。
所述设备信息,即定义登记在区块链上的设备所需要包含的信息。其中,所述设备信息至少包括:设备标识、设备群组ID、设备上的固件/软件包的ID或名称、实际版本号、期望版本号;另外,还可以包括设备类型、设备所在域等信息。比如下面伪码中的Device Info结构。
B.用于在区块链上登记设备信息的智能合约函数。
比如下面伪码中的“registry Device()”函数。IOT网关在IOT设备注册时调用该函数,并将注册设备的设备信息登记到区块链上。
C.包括用于在区块链上登记固件/软件包信息的智能合约函数。
应用节点在企业生成固件/软件包时,调用登记固件/软件包信息的智能合约函数,将固件/软件包信息登记到区块链上。如下面伪码中的“registry Package()”、“upgrade Package()”函数。这两个函数的区别在于,“registry Package()”函数在第一次创建固件/软件包时调用,而“upgrade Package()”函数则在生成之前创建的固件/软件包的更新版本时调用。所述固件/软件包信息中包括:固件/软件包的ID或名称、版本号、下载地址和hash值等。
D.用于更新设备期望版本号的智能合约函数。
比如下面伪码中的“upgrade Devices()”函数。应用节点在企业需要进行设备升级时,调用该函数,在函数参数中指定设备群组标识、固件/软件包的ID或名称、版本,将区块链中属于该群组的设备的固件/软件包的ID或名称所对应的期望版本号改为函数参数中的版本号。
E.用于更新设备实际版本号的智能合约函数。
IOT网关在收到IOT设备上报的升级结果且该升级结果为成功时,调用该函数。如下面伪码中的“update Devices()”函数。调用该函数时,在函数参数中指定设备群组标识、设备标识、设备上安装成功的固件/软件包的ID或名称、版本号,将区块链中该设备的实际版本号修改为参数中指定的设备上安装成功的固件/软件包的版本号。
下面列举一种设备管理智能合约的伪码和部分中文释义。
下面提供一种设备管理智能合约加载方法,参见图9,该方法包括:
步骤901:管理员应用节点(智能合约提供方)作为客户端先创建一个加载智能合约的交易提案,该交易提案中包括智能合约的代码及要调用的初始化函数Init。
可选的,本例中所述初始化函数为空,所以不执行任何具体操作。
步骤902:管理员应用节点将交易提案发送给所选择的至少一个设备管理节点,此时所述设备管理节点可作为背书节点,并执行背书功能。
本例中,以选择两个设备管理节点(1和2)为例,且所述选择设备管理节点作为背书节点的过程为现有技术,所以此处不再赘述。
步骤903:设备管理节点运行交易提案中的初始化函数,记录对数据的修改。由于本例中初始化函数为空,所以不执行任何具体操作。
设备管理节点对执行结果进行背书,得到所述加载智能合约的交易提案的提案结果。所述背书,指背书节点对智能合约执行结果进行签名,以代表执行结果由背书节点生成。
步骤904:设备管理节点向管理员应用节点返回所述提案结果。其中,所述提案结果中包括背书后的智能合约执行结果。
步骤905:管理员应用节点基于背书策略确定交易通过背书阶段。本例中背书策略为收到全部所选择的背书节点的提案结果并且智能合约执行结果一致,则确定交易通过背书阶段。
步骤906:管理员应用节点对提交设备管理智能合约加载的交易进行排序,所述交易中包括设备管理智能合约代码。
步骤907:设备管理节点充当排序节点,对交易进行排序并按照排序结果将所有交易封装为区块。
步骤908:设备管理节点广播区块链更新请求。
步骤909:设备管理节点、IOT网关对区块中的交易进行验证,在验证通过后加入本地账本。从而将设备管理智能合约代码记录在设备管理节点、IOT网关的本地账本上。
二、固件/软件包信息登记
企业开发好固件/软件包后,关联的应用节点调用设备管理智能合约中的固件/软件包信息登记函数请求,将固件/软件包信息登记到区块链中。如前所述,在企业第一次生成固件/软件包时调用“registry Package()”函数;在企业生成之前创建的固件/软件包的更新版本时调用“upgrade Package()”函数。
具体过程包括:应用节点创建固件/软件包信息登记交易提案,其中,该信息登记交易提案中包括:设备管理智能合约的ID、函数名为registry Package或upgradePackage、固件/软件包的ID或名称、版本号、下载地址和hash值等参数。
应用节点将所述信息登记交易提案发送给设备管理节点,设备管理节点执行相应的智能合约函数,并对执行结果进行背书,以及将生成的提案结果反馈给应用节点。
应用节点收集提案结果,根据背书策略确定固件/软件包信息登记交易通过背书阶段,则提交固件/软件包信息登记交易进行排序,设备管理节点对交易进行排序并封装为区块,然后广播区块链更新请求,设备管理节点、IOT网关对区块中的交易进行验证;以及,在验证通过后将固件/软件包相关信息记录在本地账本中,从而使得设备管理节点、IOT网关都记录了固件/软件包信息,以备后续设备升级时使用。
三、设备登记
IOT网关在设备注册成功后,调用设备管理智能合约中的设备登记函数,并将注册设备的设备信息登记到区块链上。
具体过程包括:IOT网关(具体为图5所示设备管理模块505)创建设备信息登记交易提案,其中,所述设备信息登记交易提案中包括:设备管理智能合约的ID、函数名为registry Device、DeviceInfo中的相关参数等信息;然后将设备信息登记交易提案发送给设备管理节点。设备管理节点接收提案后,执行相应的智能合约函数,并对执行结果进行背书,生成提案结果,以及向IOT网关发送该提案结果。
IOT网关收集至少一个设备管理节点反馈的提案结果,根据背书策略确定设备信息登记交易通过背书阶段,以及对提交设备信息登记交易进行排序。设备管理节点对交易进行排序并封装成新的区块,然后在全网广播区块链更新请求。
网络中的所有节点,包括设备管理节点和IOT网关,接收到更新请求之后对区块中的交易进行验证,并在验证通过后将设备信息记录在本地账本中,从而使得设备管理节点、IOT网关都保存设备的设备信息,以备设备升级时使用。
需要说明的是,本申请实施例中“二、固件/软件包信息登记”和“三、设备登记”之间在时间上没有先后关系,即这两部分的登记过程可以先后执行,或者同时执行,本实施例不对此进行限制。
下面介绍与上述各方法实施例对应的装置实施例。
参见图10,为本申请一实施例提供的一种IOT网关的结构示意图,所述IOT网关100包括:获取模块1001、处理模块1002和发送模块1003,此外,还可以包括其它功能模块或单元,用于执行图6所对应的设备升级方法。
具体地,获取模块1001,用于获取升级请求,所述升级请求中包括:升级包名称和升级包的第一期望版本号等信息。
处理模块1002,用于根据第一期望版本号对第一设备集合中的至少一个设备的期望版本号进行更新,并将更新后包括所述第一期望版本号的至少一个更新结果记录在区块链的本地账本上,以及,通过所述本地账本中记录的至少一个更新结果的第一期望版本号确定待升级设备。
发送模块1003,用于向所述待升级设备发送升级任务,以使所述待升级设备按照所述第一期望版本号更新自身的版本号。
可选的,在本实施例的一种可能的实现方式中,获取模块1001,还用于获取所述IOT网关所管理的所有设备的设备ID。
处理模块1002,具体用于根据所述设备ID在所述第一设备集合中筛选出需要更新的至少一个设备,以及,在所述需要更新的至少一个设备的第二期望版本号小于所述第一期望版本号的情况下,将所述需要更新的至少一个设备的第二期望版本号替换为所述第一期望版本号。
可选的,在本实施例的另一种可能的实现方式中,处理模块1002,具体用于获取所述第一设备集合中的至少一个设备的实际版本号,比较每个更新结果中的第一期望版本号是否大于设备对应的实际版本号,如果大于,则确定所述设备为所述待升级设备。
可选的,在本实施例的又一种可能的实现方式中,所述升级请求中还包括第一设备群组标识,例如设备群组ID。
处理模块1002,还用于对第一设备集合中的至少一个设备的期望版本号进行更新之前,判断所述第一设备群组标识与记录在所述本地账本中的每个设备的第二群组标识是否相同;如果相同,则将所述第一设备群组标识或第二设备群组标识所指示的设备作为所述第一设备集合中的设备。
可选的,在本实施例的又一种可能的实现方式中,获取模块1001,还用于在所述发送模块向所述待升级设备发送升级任务之后,获取升级包的名称。
处理模块1002,还用于根据所述升级包的名称确定记载在所述本地账本的,且与所述升级包的名称对应的包下载地址和包哈希值,根据所述包下载地址获取升级包,以及根据所述包哈希值对所述升级包进行验证。
发送模块1003,还用于将验证通过的升级包发送给所述待升级设备。
可选的,在本实施例的又一种可能的实现方式中,获取模块1001,还用于获取所述待升级设备反馈的升级结果,所述升级结果中包括所述待升级设备升级后的实际版本号,所述升级后的实际版本号与所述第一期望版本号相同。
发送模块1003,还用于将所述升级后的实际版本号通过交易提案发送给设备管理节点。
处理模块1002,还用于在接收到所述设备管理节点根据所述交易提案反馈的验证通过的消息之后,将所述待升级设备升级到所述实际版本号的交易记录在所述区块链的本地账本上。
此外,本实施例中的IOT网关的处理模块1002,还可以具体包括如图5所示的智能合约模块501、交易提交模块502、本地账本记录模块503、下载验证模块504和设备管理模块505。其中各个模块之间的数据传输可以通过发送模块1003和获取模块1001来实现,进而执行在收到区块链更新请求时更新本地账本,并根据本地账本中新增的设备升级交易确定待升级IOT设备,获取固件/软件包,对固件/软件包进行验证,向待升级IOT设备下发设备升级包,以及在收到IOT设备升级后上报的升级结果,且该升级结果为成功时,请求更新区块链中IOT设备的实际版本号等步骤。
可选的,IOT网关还可以包括存储模块,用于存储本地账本和其它传输数据。
参见图11,为本申请一实施例提供的一种设备管理节点的结构示意图,该设备管理节点110包括:获取模块1101、处理模块1102和发送模块1103,此外,还可以包括其它功能模块或单元,用于执行图7所对应的设备升级方法。
具体地,获取模块1101,用于获取来自至少一个应用节点的至少一个交易,其中,每个所述交易包括升级包的第一期望版本号。
发送模块1103,用于向IOT网关发送携带有所述升级包的第一期望版本号的升级请求,所述升级请求用于指示IOT网关对第一设备集合中的至少一个设备的期望版本号进行更新。
可选的,在本实施例的一种可能的实现方式中,还包括处理模块1102。
处理模块1102,用于对所述至少一个交易进行排序,并按照所述排序结果生成新的区块,以及,广播区块链更新请求,所述区块链更新请求用于指示IOT网关在本地账本中增加设备升级交易。
发送模块1103,具体用于点向所述IOT网关发送所述升级请求,所述升级请求中包括所述升级包的第一期望版本号。
可选的,在本实施例的另一种可能的实现方式中,获取模块1101,还用于向所述IOT网关发送所述升级请求之后,接收IOT网关发送的设备信息更新交易提案,所述设备信息更新交易提案是通过待升级设备升级成功后获得的;处理模块1102,还用于根据所述设备信息更新交易提案进行背书,并生成第一背书结果;发送模块1103,还用于向所述IOT网关发送所述第一背书结果。
可选的,在本实施例的又一种可能的实现方式中,获取模块1101,还用于获取来自所述IOT网关的设备信息更新交易提案结果,所述设备信息更新交易提案结果为验证通过背书阶段的第一背书结果。
处理模块1102,还用于将所述设备信息更新交易提案结果相关的交易记录在区块链的本地账本上。其中,所述设备信息更新交易提案结果相关的交易包括将所述待升级设备的升级包名称对应的实际版本号变更为所述第一期望版本号。
可选的,在本实施例的又一种可能的实现方式中,获取模块1101,还用于在获取来自至少一个应用节点的至少一个设备升级的交易之前,获取来自所述应用节点的设备升级交易提案,所述设备升级交易提案中包括链码ID和函数名。
处理模块1102,还用于根据所述设备升级交易提案中的链码ID和函数名执行智能合约函数得到执行结果,并对所述执行结果进行背书生成第二背书结果。
发送模块1103,还用于将所述第二背书结果发送给所述应用节点,以使所述应用节点根据所述第二背书结果生成设备升级的交易。
此外,本实施例中的设备管理节点中的处理模块1102,还可以具体包括如图4所示的交易背书模块401、交易提交模块402、交易排序模块403、智能合约模块404和本地账本记录模块405。其中各个模块之间的数据传输可以通过发送模块1103和获取模块1101来实现,进而执行对交易验证、排序,将排序好的交易封装成区块并请求更新区块链等步骤。
可选的,设备管理节点还可以包括存储模块,用于存储本地账本和其它传输数据。
本申请实施例还提供了一种应用节点,如图12所示,该应用节点120包括:接收模块1201、处理模块1202和发送模块1203,此外,还可以包括其它功能模块或单元,例如存储模块等,用于在企业需要设备升级时,请求更新区块链中IOT设备的固件/软件期望版本号、固件/软件包的下载地址和Hash值。
具体地,处理模块1202,用于确定设备升级的至少一个交易,其中,每个所述交易包括升级包的第一期望版本号。
发送模块1203,用于向设备管理节点发送所述至少一个交易,以使所述设备管理节点根据所述交易中的第一期望版本号对待升级设备的版本号进行更新。
可选的,在本实施例的一种可能的实现方式中,处理模块1202,具体用于创建设备升级交易提案,所述设备升级交易提案中包括链码ID和函数名。
发送模块1203,还用于向选择的至少一个设备管理节点发送所述设备升级交易提案。
接收模块1201,用于接收所述选择的至少一个设备管理节点根据所述设备升级交易提案中的链码ID和函数名反馈的至少一个第二背书结果。
处理模块1202,还用于根据所述至少一个第二背书结果生成设备升级的至少一个交易。
可选的,在本实施例的另一种可能的实现方式中,处理模块1202,具体用于根据背书策略对所述至少一个第二背书结果进行验证,并根据统计的经过验证阶段的至少一个第二背书结果,生成所述设备升级的至少一个交易。
在具体的硬件实现中,如图13所示,本申请实施例还提供了一种网络设备或者网络节点,该网络设备130可以是前述方法实施例中的任一节点或装置,例如该网络设备130前述实施例所述的IOT网关110、设备管理节点120和应用节点130,还可以是IOT设备。
具体地,网络设备130包括:收发器131、处理器132和存储器133,该网络设备还可以包括更多或更少的部件,或者组合某些部件,或者不同的部件布置,本申请对此不进行限定。
所述收发器131用于消息或交易的接收和发送,并与网络中的其他节点进行数据传输。其中,所述收发器可以包括收发模块,所述收发模块可以包括无线局域网(wirelesslocal area network,WLAN)模块、蓝牙模块、基带(base band)模块等通信模块,以及所述通信模块对应的射频(radio frequency,RF)电路,用于进行无线局域网络通信、蓝牙通信、红外线通信及/或蜂窝式通信系统通信,例如宽带码分多重接入(wideband code divisionmultiple access,WCDMA)及/或高速下行封包存取(high speed downlink packetaccess,HSDPA)。所述收发模块用于控制网络设备中的各组件的通信,并且可以支持直接内存存取(direct memory access)。
处理器132为网络设备的控制中心,利用各种接口和线路连接整个网络设备的各个部分,通过运行或执行存储在存储器133内的软件程序和/或模块,以及调用存储在存储器133内的数据,以执行网络设备的各种功能和/或处理数据。
进一步地,处理器132可以由集成电路(Integrated Circuit,IC)组成,例如可以由单颗封装的IC所组成,也可以由连接多颗相同功能或不同功能的封装IC而组成。举例来说,处理器可以仅包括中央处理器(Central Processing Unit,CPU),也可以是GPU、数字信号处理器(Digital Signal Processor,DSP)、及收发器中的控制芯片(例如基带芯片)的组合。在本申请的各种实施方式中,CPU可以是单运算核心,也可以包括多运算核心。
存储器133可以包括易失性存储器(volatile memory),例如随机存取内存(Random Access Memory,RAM);还可以包括非易失性存储器(non-volatile memory),例如快闪存储器(flash memory),硬盘(Hard Sisk Drive,HDD)或固态硬盘(Solid-StateDrive,SSD);存储器还可以包括上述种类的存储器的组合。所述存储器中可以存储有程序或代码,处理器132通过执行所述程序或代码可以实现所述网络设备的功能。
在本实施例中,收发器131所要实现的功能可以由前述各个装置实施例中的获取模块/接收模块和发送模块来实现,或者由处理器132控制的收发器131实现;各个处理模块所要实现的功能则可以由处理器132实现。
此外,本申请还提供一种计算机存储介质,其中,该计算机存储介质可存储有程序,该程序执行时可包括本申请提供的设备升级方法的各实施例中的部分或全部步骤。所述的存储介质可为磁碟、光盘、只读存储记忆体ROM或随机存储记忆体RAM等。
在上述实施例中,可以全部或部分通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。
所述计算机程序产品包括一个或多个计算机指令,例如设备升级指令。在计算机加载和执行所述计算机程序时,全部或部分地产生按照本申请上述各个实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络或者其他可编程装置。
所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网络节点、计算机、服务器或数据中心通过有线或无线方式向另一个站点、计算机或服务器进行传输。
所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等存储设备。所述可用介质可以是磁性介质,例如软盘、硬盘、磁带、光介质(例如DVD)、或半导体介质,例如固态硬盘SSD等。
另外,需要说明的是,本申请各实施例中所述IOT网关可以是一种交换机或者路由器,所述交换机或路由器可以部署在基站或者接入点上。
此外,所述基站可以是GSM或CDMA中的基站(Base Transceiver Station,BTS),也可以是WCDMA中的基站(NodeB),还可以是LTE中的演进型基站(evolutional NodeB,eNB/e-NodeB),本申请不予限定。
本申请各实施例中所述的IOT设备可以是客户端、终端设备,所述终端设备,可以是指向用户提供语音和/或数据连通性的设备,具有无线连接功能的手持式设备、或连接到无线调制解调器的其他处理设备。
无线终端可以经无线接入网RAN与一个或多个节点进行通信,所述无线终端可以是移动终端,如移动电话(或称为“蜂窝”电话)和具有移动终端的计算机,例如,可以是便携式、袖珍式、手持式、计算机内置的或者车载的移动装置,它们与无线接入网交换语言和/或数据。例如,个人通信业务(PCS,Personal Communication Service)电话、无绳电话、会话发起协议(SIP)话机、无线本地环路(WLL,Wireless Local Loop)站、个人数字助理(PDA,Personal Digital Assistant)等设备。无线终端也可以称为系统、订户单元(SubscriberUnit)、订户站(Subscriber Station),移动站(Mobile Station)、移动台(Mobile)、远程站(Remote Station)、接入点(Access Point)、远程终端(Remote Terminal)、接入终端(Access Terminal)、用户终端(User Terminal)、用户代理(User Agent)、用户设备(UserDevice)、或用户装备(User Equipment)。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等(如果存在)是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
本领域的技术人员可以清楚地了解到本申请实施例中的技术可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本申请实施例中的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。
本说明书中各个实施例之间相同相似的部分互相参见即可。尤其,对于网络设备/节点或装置设备而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例中的说明即可。
以上所述的本申请实施方式并不构成对本申请保护范围的限定。
Claims (28)
1.一种设备升级方法,其特征在于,所述方法包括:
物联网IOT网关获取升级请求,所述升级请求中包括升级包的第一期望版本号;
所述IOT网关根据所述第一期望版本号对第一设备集合中的至少一个设备的期望版本号进行更新,并将更新后包括所述第一期望版本号的至少一个更新结果记录在区块链的本地账本上;
所述IOT网关通过所述本地账本中记录的至少一个更新结果的第一期望版本号确定待升级设备;
所述IOT网关向所述待升级设备发送升级任务,以使所述待升级设备按照所述第一期望版本号更新自身的版本号。
2.根据权利要求1所述的方法,其特征在于,所述IOT网关对第一设备集合中的至少一个设备的期望版本号进行更新,包括:
所述IOT网关获取其所管理的所有设备的设备ID;
所述IOT网关根据所述设备ID在所述第一设备集合中筛选出需要更新的至少一个设备;
所述IOT网关在所述需要更新的至少一个设备的第二期望版本号小于所述第一期望版本号的情况下,将所述需要更新的至少一个设备的第二期望版本号替换为所述第一期望版本号。
3.根据权利要求1所述的方法,其特征在于,所述IOT网关确定待升级设备的过程,包括:
所述IOT网关获取所述第一设备集合中的至少一个设备的实际版本号;
所述IOT网关比较每个更新结果中的第一期望版本号是否大于设备对应的实际版本号,如果大于,则确定所述设备为所述待升级设备。
4.根据权利要求1所述的方法,其特征在于,所述升级请求中还包括第一设备群组标识,
在所述IOT网关对第一设备集合中的至少一个设备的期望版本号进行更新之前,所述方法还包括:
所述IOT网关判断所述第一设备群组标识与记录在所述本地账本中的每个设备的第二群组标识是否相同;如果相同,则将所述第一设备群组标识或第二设备群组标识所指示的设备作为所述第一设备集合中的设备。
5.根据权利要求1-4任一项所述的方法,其特征在于,所述IOT网关向所述待升级设备发送升级任务之后,所述方法还包括:
所述IOT网关获取升级包的名称;
所述IOT网关根据所述升级包的名称确定记载在所述本地账本的,且与所述升级包的名称对应的包下载地址和包哈希值;
所述IOT网关根据所述包下载地址获取升级包,以及根据所述包哈希值对所述升级包进行验证;
所述IOT网关将验证通过的升级包发送给所述待升级设备。
6.根据权利要求5所述的方法,其特征在于,所述方法还包括:
所述IOT网关获取所述待升级设备反馈的升级结果,所述升级结果中包括所述待升级设备升级后的实际版本号,所述升级后的实际版本号与所述第一期望版本号相同;
所述IOT网关将所述升级后的实际版本号通过交易提案发送给设备管理节点;
所述IOT网关在接收到所述设备管理节点根据所述交易提案反馈的验证通过的消息之后,将所述待升级设备升级到所述实际版本号的交易记录在所述区块链的本地账本上。
7.一种设备升级方法,其特征在于,所述方法包括:
设备管理节点获取来自至少一个应用节点的至少一个交易,其中,每个所述交易包括升级包的第一期望版本号;
所述设备管理节点向IOT网关发送携带有所述升级包的第一期望版本号的升级请求,所述升级请求用于指示IOT网关对第一设备集合中的至少一个设备的期望版本号进行更新,并将至少一个更新结果记录在区块链的本地账本上,所述至少一个更新结果记录包括所述第一期望版本号。
8.根据权利要求7所述的方法,其特征在于,所述设备管理节点向IOT网关发送升级请求的过程,包括:
所述设备管理节点对所述至少一个交易进行排序,并按照所述排序结果生成新的区块;
所述设备管理节点广播区块链更新请求,所述区块链更新请求用于指示IOT网关在本地账本中增加设备升级交易;
所述设备管理节点向所述IOT网关发送所述升级请求,所述升级请求中包括所述升级包的第一期望版本号。
9.根据权利要求8所述的方法,其特征在于,所述设备管理节点向所述IOT网关发送所述升级请求之后,所述方法还包括:
所述设备管理节点接收IOT网关发送的设备信息更新交易提案,所述设备信息更新交易提案是通过待升级设备升级成功后获得的;
所述设备管理节点根据所述设备信息更新交易提案进行背书,并生成第一背书结果;
所述设备管理节点向所述IOT网关发送所述第一背书结果。
10.根据权利要求9所述的方法,其特征在于,所述方法还包括:
所述设备管理节点获取来自所述IOT网关的设备信息更新交易提案结果,所述设备信息更新交易提案结果为验证通过背书阶段的第一背书结果;
所述设备管理节点将所述设备信息更新交易提案结果相关的交易记录在区块链的本地账本上;
其中,所述设备信息更新交易提案结果相关的交易包括将所述待升级设备的升级包名称对应的实际版本号变更为所述第一期望版本号。
11.根据权利要求7-10任一项所述的方法,其特征在于,所述设备管理节点获取来自至少一个应用节点的至少一个设备升级的交易之前,所述方法还包括:
所述设备管理节点获取来自所述应用节点的设备升级交易提案,所述设备升级交易提案中包括链码ID和函数名;
所述设备管理节点根据所述链码ID和函数名执行智能合约函数,得到执行结果,并对所述执行结果进行背书生成第二背书结果;
所述设备管理节点将所述第二背书结果发送给所述应用节点,以使所述应用节点根据所述第二背书结果生成设备升级的交易。
12.一种设备升级方法,其特征在于,所述方法包括:
应用节点确定设备升级的至少一个交易,其中,每个所述交易包括升级包的第一期望版本号;
所述应用节点向设备管理节点发送所述至少一个交易,以使所述设备管理节点根据所述交易中的第一期望版本号对待升级设备的版本号进行更新,并将至少一个更新结果记录在区块链的本地账本上,所述至少一个更新结果记录包括所述第一期望版本号。
13.根据权利要求12所述的方法,其特征在于,所述应用节点确定设备升级的至少一个交易,包括:
所述应用节点创建设备升级交易提案,所述设备升级交易提案中包括链码ID和函数名;
所述应用节点向选择的至少一个设备管理节点发送所述设备升级交易提案;
所述应用节点接收所述选择的至少一个设备管理节点根据所述设备升级交易提案中的链码ID和函数名反馈的至少一个第二背书结果;
所述应用节点根据所述至少一个第二背书结果生成设备升级的至少一个交易。
14.根据权利要求13所述的方法,其特征在于,所述应用节点根据所述至少一个第二背书结果生成设备升级的至少一个交易,包括:
所述应用节点根据背书策略对所述至少一个第二背书结果进行验证,并根据统计的经过验证阶段的至少一个第二背书结果,生成所述设备升级的至少一个交易。
15.一种IOT网关,其特征在于,包括:
获取模块,用于获取升级请求,所述升级请求中包括升级包的第一期望版本号;
处理模块,用于根据所述第一期望版本号对第一设备集合中的至少一个设备的期望版本号进行更新,并将更新后包括所述第一期望版本号的至少一个更新结果记录在区块链的本地账本上,以及,通过所述本地账本中记录的至少一个更新结果的第一期望版本号确定待升级设备;
发送模块,用于向所述待升级设备发送升级任务,以使所述待升级设备按照所述第一期望版本号更新自身的版本号。
16.根据权利要求15所述的网关,其特征在于,
所述获取模块,还用于获取所述IOT网关所管理的所有设备的设备ID;
所述处理模块,具体用于根据所述设备ID在所述第一设备集合中筛选出需要更新的至少一个设备,以及,在所述需要更新的至少一个设备的第二期望版本号小于所述第一期望版本号的情况下,将所述需要更新的至少一个设备的第二期望版本号替换为所述第一期望版本号。
17.根据权利要求15所述的网关,其特征在于,
所述处理模块,具体用于获取所述第一设备集合中的至少一个设备的实际版本号,比较每个更新结果中的第一期望版本号是否大于设备对应的实际版本号,如果大于,则确定所述设备为所述待升级设备。
18.根据权利要求15所述的网关,其特征在于,所述升级请求中还包括第一设备群组标识,
所述处理模块,还用于对第一设备集合中的至少一个设备的期望版本号进行更新之前,判断所述第一设备群组标识与记录在所述本地账本中的每个设备的第二群组标识是否相同;如果相同,则将所述第一设备群组标识或第二设备群组标识所指示的设备作为所述第一设备集合中的设备。
19.根据权利要求15-18任一项所述的网关,其特征在于,
所述获取模块,还用于在所述发送模块向所述待升级设备发送升级任务之后,获取升级包的名称;
所述处理模块,还用于根据所述升级包的名称确定记载在所述本地账本的,且与所述升级包的名称对应的包下载地址和包哈希值,根据所述包下载地址获取升级包,以及根据所述包哈希值对所述升级包进行验证;
所述发送模块,还用于将验证通过的升级包发送给所述待升级设备。
20.根据权利要求19所述的网关,其特征在于,
所述获取模块,还用于获取所述待升级设备反馈的升级结果,所述升级结果中包括所述待升级设备升级后的实际版本号,所述升级后的实际版本号与所述第一期望版本号相同;
所述发送模块,还用于将所述升级后的实际版本号通过交易提案发送给设备管理节点;
所述处理模块,还用于在接收到所述设备管理节点根据所述交易提案反馈的验证通过的消息之后,将所述待升级设备升级到所述实际版本号的交易记录在所述区块链的本地账本上。
21.一种设备管理节点,其特征在于,包括:
获取模块,用于获取来自至少一个应用节点的至少一个交易,其中,每个所述交易包括升级包的第一期望版本号;
发送模块,用于向IOT网关发送携带有所述升级包的第一期望版本号的升级请求,所述升级请求用于指示IOT网关对第一设备集合中的至少一个设备的期望版本号进行更新,并将至少一个更新结果记录在区块链的本地账本上,所述至少一个更新结果记录包括所述第一期望版本号。
22.根据权利要求21所述的节点,其特征在于,还包括处理模块,
所述处理模块,用于对所述至少一个交易进行排序,并按照所述排序结果生成新的区块,以及,广播区块链更新请求,所述区块链更新请求用于指示IOT网关在本地账本中增加设备升级交易;
所述发送模块,具体用于点向所述IOT网关发送所述升级请求,所述升级请求中包括所述升级包的第一期望版本号。
23.根据权利要求22所述的设备管理节点,其特征在于,
所述获取模块,还用于向所述IOT网关发送所述升级请求之后,接收IOT网关发送的设备信息更新交易提案,所述设备信息更新交易提案是通过待升级设备升级成功后获得的;
所述处理模块,还用于根据所述设备信息更新交易提案进行背书,并生成第一背书结果;
所述发送模块,还用于向所述IOT网关发送所述第一背书结果。
24.根据权利要求23所述的设备管理节点,其特征在于,
所述获取模块,还用于获取来自所述IOT网关的设备信息更新交易提案结果,所述设备信息更新交易提案结果为验证通过背书阶段的第一背书结果;
所述处理模块,还用于将所述设备信息更新交易提案结果相关的交易记录在区块链的本地账本上;
其中,所述设备信息更新交易提案结果相关的交易包括将所述待升级设备的升级包名称对应的实际版本号变更为所述第一期望版本号。
25.根据权利要求22-24任一项所述的设备管理节点,其特征在于,
所述获取模块,还用于在获取来自至少一个应用节点的至少一个设备升级的交易之前,获取来自所述应用节点的设备升级交易提案,所述设备升级交易提案中包括链码ID和函数名;
所述处理模块,还用于根据所述设备升级交易提案中的链码ID和函数名执行智能合约函数得到执行结果,并对所述执行结果进行背书生成第二背书结果;
所述发送模块,还用于将所述第二背书结果发送给所述应用节点,以使所述应用节点根据所述第二背书结果生成设备升级的交易。
26.一种应用节点,其特征在于,包括:
处理模块,用于确定设备升级的至少一个交易,其中,每个所述交易包括升级包的第一期望版本号;
发送模块,用于向设备管理节点发送所述至少一个交易,以使所述设备管理节点根据所述交易中的第一期望版本号对待升级设备的版本号进行更新,并将至少一个更新结果记录在区块链的本地账本上,所述至少一个更新结果记录包括所述第一期望版本号。
27.根据权利要求26所述的应用节点,其特征在于,还包括接收模块,
所述处理模块,具体用于创建设备升级交易提案,所述设备升级交易提案中包括链码ID和函数名;
所述发送模块,还用于向选择的至少一个设备管理节点发送所述设备升级交易提案;
所述接收模块,用于接收所述选择的至少一个设备管理节点根据所述设备升级交易提案中的链码ID和函数名反馈的至少一个第二背书结果;
所述处理模块,还用于根据所述至少一个第二背书结果生成设备升级的至少一个交易。
28.根据权利要求27所述的应用节点,其特征在于,
所述处理模块,具体用于根据背书策略对所述至少一个第二背书结果进行验证,并根据统计的经过验证阶段的至少一个第二背书结果,生成所述设备升级的至少一个交易。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810869281.2A CN110798331B (zh) | 2018-08-02 | 2018-08-02 | 一种设备升级方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810869281.2A CN110798331B (zh) | 2018-08-02 | 2018-08-02 | 一种设备升级方法和装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110798331A CN110798331A (zh) | 2020-02-14 |
CN110798331B true CN110798331B (zh) | 2021-11-09 |
Family
ID=69425231
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810869281.2A Active CN110798331B (zh) | 2018-08-02 | 2018-08-02 | 一种设备升级方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110798331B (zh) |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111447092B (zh) * | 2020-03-26 | 2022-11-01 | 杭州复杂美科技有限公司 | 版本监测方法、设备和存储介质 |
CN113495750B (zh) * | 2020-04-01 | 2023-02-10 | 中移物联网有限公司 | 一种设备的升级检测方法、装置及服务器 |
CN111381866A (zh) * | 2020-05-29 | 2020-07-07 | 支付宝(杭州)信息技术有限公司 | 区块链系统的版本升级方法、系统、及装置 |
CN111835835A (zh) * | 2020-06-24 | 2020-10-27 | 清科优能(深圳)技术有限公司 | 一种智慧物联网终端的批量远程管理方法及系统 |
CN112001592A (zh) * | 2020-07-21 | 2020-11-27 | 梁哲钧 | 基于区块链技术的广电设备安装工程施工过程管理共享方法 |
CN114124907B (zh) * | 2020-08-14 | 2023-07-21 | 中国移动通信集团浙江有限公司 | Sip信令前置机及业务升级方法、装置、设备以及存储介质 |
EP3958507A1 (en) * | 2020-08-17 | 2022-02-23 | Nokia Solutions and Networks Oy | Blockchain-based network device management methods and devices |
CN111984295B (zh) * | 2020-08-22 | 2021-04-13 | 暗链科技(深圳)有限公司 | 一种区块链软件全网更新方法、存储介质及电子设备 |
CN112162768B (zh) * | 2020-10-14 | 2022-09-30 | 支付宝(杭州)信息技术有限公司 | 一种区块链升级方法和系统 |
CN113641391B (zh) | 2021-10-19 | 2022-02-18 | 杭州趣链科技有限公司 | 升级区块链系统的方法、装置及终端设备 |
CN114168175B (zh) * | 2021-12-14 | 2024-04-16 | 四川启睿克科技有限公司 | 基于区块链的跨厂商设备追溯方法及系统 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106101242A (zh) * | 2016-06-24 | 2016-11-09 | 深圳前海微众银行股份有限公司 | 区块链云服务平台的构建方法和装置 |
CN106130779A (zh) * | 2016-07-18 | 2016-11-16 | 布比(北京)网络技术有限公司 | 一种物联设备及用该设备的物联网构建方法 |
CN107438003A (zh) * | 2016-05-27 | 2017-12-05 | 索尼公司 | 电子设备、用于电子设备的方法和信息处理系统 |
US9953281B2 (en) * | 2012-09-28 | 2018-04-24 | Rex Wiig | System and method of a requirement, compliance and resource management |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170031676A1 (en) * | 2015-07-27 | 2017-02-02 | Deja Vu Security, Llc | Blockchain computer data distribution |
-
2018
- 2018-08-02 CN CN201810869281.2A patent/CN110798331B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9953281B2 (en) * | 2012-09-28 | 2018-04-24 | Rex Wiig | System and method of a requirement, compliance and resource management |
CN107438003A (zh) * | 2016-05-27 | 2017-12-05 | 索尼公司 | 电子设备、用于电子设备的方法和信息处理系统 |
CN106101242A (zh) * | 2016-06-24 | 2016-11-09 | 深圳前海微众银行股份有限公司 | 区块链云服务平台的构建方法和装置 |
CN106130779A (zh) * | 2016-07-18 | 2016-11-16 | 布比(北京)网络技术有限公司 | 一种物联设备及用该设备的物联网构建方法 |
Also Published As
Publication number | Publication date |
---|---|
CN110798331A (zh) | 2020-02-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110798331B (zh) | 一种设备升级方法和装置 | |
CN111052711B (zh) | 发现由网络存储库功能提供的服务的方法 | |
JP6834033B2 (ja) | ネットワークスライス管理方法、ユニット、及びシステム | |
JP6130529B2 (ja) | 加入方式のサービスにアクセスするための登録および資格証明ロールアウト | |
US11258822B2 (en) | Network function service discovery method and device | |
US8255908B2 (en) | Managing tasks in a distributed system | |
US20180234906A1 (en) | Method and apparatus for self organizing networks | |
US11516310B2 (en) | Method and apparatus for invoking application programming interface | |
US20190181901A1 (en) | Local profile assistant and application programming interface | |
US20120203858A1 (en) | Transaction control arrangement for device management system | |
US20120008766A1 (en) | Securing a component prior to manufacture of a device | |
CN113785532B (zh) | 用于管理和验证证书的方法和装置 | |
US11789974B2 (en) | Synchronization of distributed ledger processes | |
JP4330631B2 (ja) | 移動局のためのセキュリティ関連パラメータの更新技法 | |
CN113127020A (zh) | 一种软件升级方法和装置 | |
KR20210079352A (ko) | 데이터 수집 방법, 장치, 디바이스 및 컴퓨터가 판독 가능한 저장 매체 | |
US9154973B1 (en) | Testing mobile phone maintenance channel | |
US8745270B2 (en) | Communication device and method of handling large object in device management | |
CN109429225A (zh) | 消息接收、发送方法及装置、终端、网络功能实体 | |
US11778451B2 (en) | 5G Network Exposure Function (NEF) capturing processor identity | |
JP2017500642A (ja) | ポリシー制御機能の管理メカニズムのためのシステム及び方法 | |
KR101351867B1 (ko) | 소프트웨어 및 어플리케이션 제어 관리 객체에서의 단계 실행 결과를 처리하는 방법 | |
US12107868B1 (en) | Ledger-based protocol to verify sources and transmit communications | |
WO2024199056A1 (zh) | 一种信息处理方法及通信装置 | |
WO2024140038A1 (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 |