基于区块链的动态控制系统及方法与流程

1.本发明属于区块链技术领域，更具体地，涉及基于区块链的动态控制系统及方法。


背景技术：

2.动态调配控制是一种控制构成要素能实时适应任务特征，并通过动态匹配调节，最大限度满足资源发挥效能的控制体系。随着信息与智能化时代的发展，各层级、各地域间整合协同的动态调配控制方法成为热点研究方向。
3.传统的调配控制系统中，由于采用了传统c/s架构设计，多形成了层级式、预设式体制，存在以下弊端：(1)组织结构固化、审批流程复杂。(2)跨域权限交互过程中缺乏有效信任机制。(3)应急响应能力不足。面对突发情况，资源难以实现按需动态组合。
4.针对传统调配控制模式存在的不足，利用区块链技术去中心化、灵活可信特点支撑调配控制活动，并应用于跨域协同与权限控制的方法开始逐步受到学者们的关注。然而现有的将区块链技术应用于调配控制领域的技术方案，主要从网络架构、节点管理、数据访问以及权限控制四个方面进行改进，但对于数据及权限的管理尚集中于节点相对固定和仅可在域内交互的阶段，针对节点灵活管理和权限的跨域动态流转，未有较好的解决方案。


技术实现要素：

5.针对现有技术的至少一个缺陷或改进需求，本发明提供了一种基于区块链的动态控制系统及方法，可以根据任务需求改变调控协作关系，实现灵活的权限交互和资源调配。
6.为实现上述目的，按照本发明的第一方面，提供了一种基于区块链的动态控制系统，所述动态控制系统包括多个控制单元，每个所述控制单元均包括调控节点、信息节点和装备节点，多个所述控制单元的所述信息节点构成了基于区块链的共识单元；
7.所述调控节点用于创建任务、领取任务和控制任务调控权限的转移；
8.所述装备节点用于执行任务和控制资源访问权限的转移；
9.所述共识单元用于对任务的创建和执行进行共识确认，还用于按照预先设置的权限授予规则对任务调控权限的转移、资源访问权限的转移进行共识确认；
10.所述信息节点用于实现所述调控节点、所述装备节点间的信息交互。
11.优选的，所述共识单元用于获取每个所述控制单元的公信力集合，根据所述公信力集合对新控制单元的加入请求、或新调控节点的加入请求、或新装备节点的加入请求进行共识确认。
12.优选的，所述调控节点用于创建任务表单，所述任务表单至少包括任务内容字段、任务状态字段、任务申请人字段和权限字段，填充所述任务内容字段，将所述任务状态字段设置为第一状态，将修改后的所述任务表单发送给所述共识单元进行共识后发布；
13.所述调控节点还用于读取第一状态的所述任务表单，填充所述任务申请人字段，将所述任务状态字段设置为第二状态，将修改后的所述任务表单发送给所述共识单元进行共识后发布；
14.所述调控节点还用于读取第二状态的所述任务表单，填充所述权限字段，将所述任务状态字段设置为第三状态，将修改后的所述任务表单发送给所述共识单元进行共识。
15.优选的，所述调控节点还用于修改所述任务内容字段和/或所述权限字段，将修改后的所述任务表单发送给所述共识单元进行共识后发布。
16.优选的，所述共识单元还用于获取每个所述控制单元的签名效用值集合，按照预先设置的权限授予规则利用所述签名效用值集合对所述权限字段中的权限进行共识确认。
17.优选的，所述任务表单至少还包括任务完成情况字段和任务效果评估字段；
18.所述调控节点还用于读取第三状态的所述任务表单，填充所述任务完成情况字段，将所述任务状态字段设置为第四状态，将修改后的所述任务表单发送给所述共识单元进行共识；
19.所述调控节点还用于读取第四状态的所述任务表单，填充所述任务效果评估字段，将所述任务状态字段设置为第五状态，将修改后的所述任务表单发送给所述共识单元进行共识后发布。
20.优选的，所述装备节点中包括装备需求节点和装备所属方节点；
21.所述装备需求节点用于读取第一状态的所述任务表单，填充所述装备借调字段，将所述装备状态字段设置为第二状态，将修改后的所述装备表单发送给所述共识单元进行共识后发布；
22.所述装备所属方节点还用于读取第二状态的所述装备表单，将所述装备状态字段设置为第三状态，将修改后的所述装备表单发送给所述共识单元进行共识。
23.所述装备需求节点或所述所属方节点还用于读取第三状态的所述装备表单，将所述装备状态字段设置为第四状态，将修改后的所述装备表单发送给所述共识单元进行共识。
24.优选的，所述共识单元还用于获取每个所述控制单元的签名效用值集合，按照预先设置的资源访问权限授予规则利用所述签名效用值集合对第四状态的所述装备表单进行共识确认。
25.优选的，基于区块链的动态控制系统，还包括：记录模块，用于在区块链上记录和更新所述任务表单和/或所述装备表单的创建或修改事件。
26.按照本发明的第二方面，提供了一种基于区块链的动态控制方法，其特征在于，所述方法应用于动态控制系统，所述动态控制系统包括多个控制单元，每个所述控制单元均包括调控节点、信息节点和装备节点，多个所述控制单元的信息节点构成了基于区块链的共识单元，所述方法包括步骤：
27.所述调控节点创建任务、领取任务和控制任务调控权限的转移；
28.所述装备节点执行任务和控制资源访问权限的转移；
29.共识单元对任务的创建和执行进行共识确认，还用于按照预先设置的权限授予规则对任务调控权限的转移、资源访问权限的转移进行共识确认；
30.信息节点实现所述调控节点、所述装备节点间的信息交互。
31.总体而言，本发明与现有技术相比，可以根据任务需求改变调控协作关系，实现灵活的权限交互和资源调配，具有表现在以下方面：
32.(1)提出了一种扁平化、分布式的动态控制系统，信息指令传输快，并且设计了权
限管控机制，实现了从固定式权限管控方法向共识的方法转变，并且可以实现跨控制单元的权限交互。
33.(2)针对任务执行模式进行设计，实现了从预设式任务执行模式向灵活可定义、互监督、分布式执行的智能合约模式转变。
34.(3)设计了相应的数据管理方法，实现了中心化的数据管理向互鉴证分布式的转变。
附图说明
35.图1是本发明实施例的动态控制系统的控制单元内节点交互模式；
36.图2是本发明实施例的动态控制系统的区块链网络模型；
37.图3是本发明实施例的任务调控权限转移流程；
38.图4是本发明实施例的装备申领流程；
39.图5是本发明实施例的装备归还流程；
40.图6是本发明实施例的调控事务区块链结构。
具体实施方式
41.为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。
42.本发明实施例的一种基于区块链的动态控制系统，所述动态控制系统包括多个控制单元，每个所述控制单元均包括调控节点、信息节点和装备节点，多个所述控制单元的信息节点构成了基于区块链的共识单元；所述调控节点用于创建任务和控制任务调控权限的转移；所述装备节点用于执行任务和控制资源访问权限的转移；所述共识单元用于对任务的创建和执行进行共识确认，还用于按照预先设置的权限授予规则对任务调控权限的转移、资源访问权限的转移进行共识确认；所述信息节点用于实现所述调控节点、所述装备节点间的信息交互。
43.1控制单元组成
44.调控节点(node_cmd)可用于实现以下功能：发布任务，下达指令，管理任务调控权限，对其他节点实施控制的单元，是控制单元的决策核心。
45.信息节点(node_info)可用于实现以下功能：针对任务，负责指令及信息的传递与交互的单元，是控制单元的交互核心。
46.装备节点(node_equip)可用于实现以下功能：执行任务的装备资源(机车等)，是控制单元任务实施的载体。
47.这三类节点即可构成一个基本的控制单元。在每个控制单元内部，三类节点采用如图1所示的模式进行交互。
48.其典型交互模式为：用户通过调控节点实施调配控制活动，将调控指令提交信息节点并接收反馈；信息节点负责指令等信息的传递与转达，以及区块链系统的共识功能，装备节点负责管控装备资源，通过链接到信息节点上完成相应的业务活动。
49.图2展现了不同领域控制单元间的连接与交互关系。其中，org1是领域a的控制单元，org1_1是org1的下级控制单元，org2是领域b的控制单元，org2_1是org2的下级控制单元，各控制单元信息节点是建立控制单元间连接关系的锚点，并为跨域的指令下达与权限流转提供通信机制；ordering service是由各个控制单元专属的具有验证功能的信息节点构成的共识单元(认证联盟)，为系统提供认证服务，其中order1至order4分别是来自四个组织的具有验证功能的信息节点，共同负责为区块链网络模型中各组织的节点、用户等提供数字证书生成、身份认证服务以及参与区块链数据的维护与管理。
50.优选的，为了确保任务的机密性和实现不同任务间的数据隔离，本技术使用任务通道机制，为每个任务过程创建一个通道，通道内仅包含对应任务所涉及的组织。具体地，由发起任务的节点进行创建，选择其认为适合执行任务的节点发送配置文件，使其加入通道。
51.通过上述控制单元架构设计，将传统的层级式的控制单元结构变得更加扁平化，提高了控制单元的去中心化水平与抗毁能力，为实现动态权限授权建立了基础。
52.2权限管理
53.权限管理是跨控制单元协同的必要内容。优选的，权限管理优选包括节点管理和权限流转两个方面。
54.2.1节点管理
55.所述共识单元用于获取每个所述控制单元的公信力集合，根据所述公信力集合对新控制单元的加入请求、或新调控节点的加入请求、或新信息节点的加入请求、或新装备节点的加入请求进行共识确认。
56.2.1.1组织加入
57.除了构建认证联盟时的初始控制单元，其余的控制单元加入区块链网络需要得到一定数量的已加入控制单元的认可，以此保证控制单元跨域协作的可信度。如果有组织加入，它至少有一个信息节点，组织加入即为信息节点加入。设o＝{o1，o2，...，o
n
}是已加入网络的控制单元集合，o
i
为o中已存在的控制单元，是vpt
org
控制单元准入的共识阈值，α＝{α1,α2,...,α
n
}为已加入网络控制单元的公信力集合，可以依据调控体系的特点灵活设置或调整各组织的公信力大小。permitted()为判别组织o
i
是否认可组织o
j
的函数：
[0058][0059]
则组织o
j
想要加入区块链网络，须满足：
[0060][0061]
2.1.2节点加入规则
[0062]
在一个实施例中，调控节点或装备节点的加入需要其所隶属组织的认可，同时也需要网络中一定数量的组织的同意，以确保节点的高可信度。若node为申请加入的节点，vpt
node
为节点准入的共识阈值，o
belong
是要加入网络的节点所隶属的组织，则调控或装备节点加入网络，需满足：
[0063][0064]
2.1.3退出网络规则
[0065]
在一个实施例中，调控节点或装备节点退出网络仅需要其所隶属组织的认可。若node为申请退出网络的节点，o
belong
是要退出网络的节点所隶属的组织，则调控或装备节点退出网络，需满足：
[0066]
permitted(o
belong
,node)≠0(4)
[0067]
2.2权限流转
[0068]
动态调配控制的过程主要涉及到任务调控权限的转移和资源访问权限的转移。调控节点用于控制任务调控权限的转移，所述装备节点用于控制资源访问权限的转移；共识单元用于按照预先设置的权限授予规则对任务调控权限的转移、资源访问权限的转移进行共识确认。
[0069]
2.2.1基于阈值的权限授予规则
[0070]
权限授予包含任务调控权限和资源访问权限的授予。组织o
i
在组织o
j
加入区块链网络后可以依据任务需要向o
j
授予部分权限，除o
i
需要对权限授予行为进行签名，也需要一定数量组织的签名。β＝{β1,β2,...,β
n
}为网络中各组织签名的效用值集合，vpt
right
是权限流转的共识阈值。sign()是判别组织o
i
是否签名的函数：
[0071][0072]
在一个实施例中，组织o
i
进行权限授予需满足：
[0073][0074]
2.2.2基于阈值的权限取消规则
[0075]
权限取消包含任务调控权限和资源访问权限的收回。优选的，分为主动归还与被动收回两种模式。如需取消组织o
i
对组织o
j
授予的权限，主动归还模式下由组织o
j
发起取消申请并签名，被动收回模式则由组织o
i
发起并签名，两种模式均需要一定数量组织的签名批准：
[0076][0077]
3任务执行
[0078]
优选的，动态任务执行包含任务调控权限转移、资源访问权限转移以及应急响应权限转移三个主要场景，权限的授予与流转过程在前述管控规则下通过智能合约执行实现。
[0079]
为保证任务间保密性和通信效率，优选为每项任务构建专用任务通道，任务通道是特定任务成员相互通信的专用“子网”，任务相关事务都在任务通道中执行。任务相关方
加入通道，并在身份验证和授权后才能在该通道上完成业务，装备的借调同样在任务通道中进行，通道账本记录了装备调配的过程以及一项任务的完整过程。完成任务时将任务通道的账本数据经过hash运算形成任务链hash存储在系统的总帐本中。
[0080]
3.1任务调控权限转移
[0081]
优选的，在区块链任务通道中基于任务表单设计了任务调控权限转移方案。任务表单是包含了当前任务预设信息的规范化数据，以智能合约的形式在任务通道中流通，根据任务阶段和条件不同具备不同的状态标签。
[0082]
优选的，所述调控节点用于创建任务表单，所述任务表单至少包括任务内容字段、任务状态字段、任务申请人字段和权限字段，填充所述任务内容字段，将所述任务状态字段设置为第一状态，将修改后的所述任务表单发送给所述共识单元进行共识后发布；
[0083]
所述装备节点用于读取第一状态的所述任务表单，填充所述任务申请人字段，将所述任务状态字段设置为第二状态，将修改后的所述任务表单发送给所述共识单元进行共识后发布；
[0084]
所述调控节点还用于读取第二状态的所述任务表单，填充所述权限字段，将所述任务状态字段设置为第三状态，将修改后的所述任务表单发送给所述共识单元进行共识。
[0085]
所述调控节点用于创建任务表单，所述任务表单至少包括任务内容字段、任务状态字段、任务申请人字段和权限字段，填充所述任务内容字段，将所述任务状态字段设置为第一状态，将修改后的所述任务表单发送给所述共识单元进行共识后发布；
[0086]
所述装备节点用于读取第一状态的所述任务表单，填充所述任务申请人字段，将所述任务状态字段设置为第二状态，将修改后的所述任务表单发送给所述共识单元进行共识后发布；
[0087]
所述调控节点还用于读取第二状态的所述任务表单，填充所述权限字段，将所述任务状态字段设置为第三状态，将修改后的所述任务表单发送给所述共识单元进行共识。
[0088]
优选的，所述调控节点还用于修改所述任务内容字段和/或所述权限字段，将修改后的所述任务表单发送给所述共识单元进行共识后发布。
[0089]
优选的，所述共识单元还用于获取每个所述控制单元的签名效用值集合，按照预先设置的权限授予规则利用所述签名效用值集合对所述权限字段中的权限进行共识确认。
[0090]
优选的，所述任务表单至少还包括任务完成情况字段和任务效果评估字段；
[0091]
所述装备节点还用于读取第三状态的所述任务表单，填充所述任务完成情况字段，将所述任务状态字段设置为第四状态，将修改后的所述任务表单发送给所述共识单元进行共识；
[0092]
所述调控节点还用于读取第四状态的所述任务表单，填充所述任务效果评估字段，将所述任务状态字段设置为第五状态，将修改后的所述任务表单发送给所述共识单元进行共识后发布。
[0093]
在一个实施例中，任务表单的数据结构如表1所示。
[0094]
表1任务表单数据结构
[0095][0096]
任务调控权限转移包含了任务发布与申领、任务动态调整和任务完成与反馈三个主要环节。如图3所示，三个环节的主要交互流程相近，但内涵的具体的业务逻辑不同。
[0097]
3.1.1任务发布与申领
[0098]
任务发布与申领主要划分为两种模式：任务申领模式及任务指派模式。其中任务申领模式引入众包的思想，生成任务的组织负责任务发布，而相关组织根据自身情况进行申领。任务发布方、受领方与认证联盟加入任务通道，任务申领的流程如下。
[0099]
(1)任务发布阶段：
[0100]
①
任务发布方读取链上合约模板，构建初始任务表单；
[0101]
②
发布方更新表单content项，并将表单state字段设置为“发布”，对表单签名；
[0102]
③
表单在任务通道中广播；
[0103]
④
认证联盟进行验证与签名，并生成任务发布事务；
[0104]
⑤
事务提交任务通道中进行共识同步；
[0105]
⑥
事务共识成功后提交通道事务区块。
[0106]
(2)任务申领阶段：
[0107]
①
通道之中的其他组织的调控节点读取state字段值为“发布”的任务表单；
[0108]
②
受领方对任务表单发出受领申请，填写applicants字段信息，并修改state字段为“待批”，并对表单签名；
[0109]
③
表单在任务通道中广播；
[0110]
④
认证联盟进行验证与签名，并生成任务申请事务；
[0111]
⑤
事务提交任务通道中进行共识同步；
[0112]
⑥
事务共识成功后提交通道事务区块。
[0113]
(3)任务确认阶段：
[0114]
①
发布方读取state字段值为“待批”的表单；；
[0115]
②
发布方对受领方进行审核决定是否交由其执行，若同意则完善任务表单，将任务需要的权限填入表单的authority字段,对表单签名；
[0116]
③
表单在任务通道中广播；
[0117]
④
认证联盟依据权限授予规则进行验证签名，若达到阈值要求即将表单state字段设为“执行”,并生成任务确认事务；
[0118]
⑤
事务提交任务通道中进行共识同步；
[0119]
⑥
事务共识成功后提交通道事务区块。
[0120]
受领方通过签名及时间戳对任务数据和调控权限进行校验，验证无误后受领方即可具有对应的调控权限并开始执行任务。
[0121]
除了申领模式，有些任务则需要指派特定的组织进行完成，这即是任务执行的另一种情形，任务指派模式。发布方将表单信息按照确认阶段的标准填写，任务执行方接受确认后即可进入任务执行阶段，相关事务在链上同步记录。相较于任务申领模式，指派模式具有较高的效率，适用于目的明确、指向性强的任务场景。
[0122]
3.1.2任务动态调整
[0123]
在任务执行的过程中考虑到战场环境变化等因素，需要对任务调控权限、任务内容等要素进行灵活调整以实现动态调控要求。任务调整流程的步骤如下：
[0124]
①
任务发布方读取state字段值为“执行”的任务表单；
[0125]
②
发布方更新任务细节或权限填入content项或authority项并签名；
[0126]
③
表单在任务通道中广播；
[0127]
④
认证联盟对其进行验证与签名，若满足权限授予规则与权限取消规则，任务表单即可更新成功，并生成相应事务；
[0128]
⑤
事务提交任务通道中进行共识同步；
[0129]
⑥
事务共识成功后提交通道事务区块。
[0130]
任务执行方依据更新后的任务内容与任务调控权限执行任务。
[0131]
3.1.3任务完成与反馈
[0132]
任务执行的结果需要反馈给发布任务的组织进行审核，以此评估任务执行的效果，并决定是否结束任务，分为反馈与审核两个阶段，步骤如下：
[0133]
(1)反馈阶段：
[0134]
①
任务受领方在任务完成时从链中读取state字段值为“执行”的任务表单；
[0135]
②
受领方将任务完成情况写入任务表单result字段，同时修改state字段为“待审核”,并对修改后的表单签名；
[0136]
③
表单在任务通道中广播；
[0137]
④
认证联盟进行验证与签名，生成任务反馈事务；
[0138]
⑤
事务提交任务通道中进行共识同步；
[0139]
⑥
事务共识成功后提交通道事务区块。
[0140]
(2)审核阶段：
[0141]
①
任务发布方读取链上state值为“待审核”的任务表单；
[0142]
②
发布方对执行情况进行审核和评估决定任务是否已完成，若认可任务执行情况则填写evaluation字段信息并将state字段更新为“完成”，并对表单进行签名；
[0143]
③
表单在任务通道中广播；
[0144]
④
认证联盟依据权限取消规则进行验证与签名，生成任务审核事务；
[0145]
⑤
事务提交任务通道中进行共识同步；
[0146]
⑥
事务共识成功后提交通道事务区块。
[0147]
此时，任务表单已无法继续修改，任务执行方的调控权限也已被收回。
[0148]
3.2资源访问权限转移
[0149]
除了任务执行时调控权限的流转，还需要对资源权限进行管理，装备的权限流转同样在任务通道中进行。与任务表单类似，本技术基于装备表单实现装备点对点按需调配和权限流转。装备表单是包含了当前装备预设信息的规范化数据，具备不同的状态标签。
[0150]
优选的，所述装备节点中包括装备需求节点和装备所属方节点；
[0151]
所述装备需求节点用于读取第一状态的所述任务表单，填充所述装备借调字段，将所述装备状态字段设置为第二状态，将修改后的所述装备表单发送给所述共识单元进行共识后发布；
[0152]
所述装备所属方节点还用于读取第二状态的所述装备表单，将所述装备状态字段设置为第三状态，将修改后的所述装备表单发送给所述共识单元进行共识。
[0153]
所述装备需求节点或所述所属方节点还用于读取第三状态的所述装备表单，将所述装备状态字段设置为第四状态，将修改后的所述装备表单发送给所述共识单元进行共识。
[0154]
优选的，所述共识单元还用于获取每个所述控制单元的签名效用值集合，按照预先设置的资源访问权限授予规则利用所述签名效用值集合对第四状态的所述装备表单进行共识确认。
[0155]
在一个实施例中，装备表单的数据结构如表2所示。
[0156]
表2装备信息数据结构
[0157][0158]
3.2.1装备借调
[0159]
通道中的组织可以借用其他组织的处于闲置状态的装备，流程如图4所示，分为申领阶段与批复阶段。
[0160]
(1)申领阶段：
[0161]
①
需求方读取state字段为“闲置”的装备表单，其中装备表单相当于装备的使用情况登记表，可在装备实体存在时即具备；
[0162]
②
需求方对装备表单的content字段更新装备请求，修改state字段为“待批复”并签名；
[0163]
③
表单被发布到通道中广播；
[0164]
④
认证联盟对事务进行验证并签名，生成装备资源申领事务；
[0165]
⑤
事务在通道中进行共识；
[0166]
⑥
若共识成功即将事务提交通道事务区块。
[0167]
(2)批复阶段：
[0168]
①
本级组织的装备节点与上级组织的装备节点均可读取state字段为“待批复”的装备表单，查看表单的content项并进行审核批复；
[0169]
②
若本级组织的装备节点同意且上级组织装备节点未提出拒绝，或是上级组织的装备节点同意(无论本级组织同意与否)，则将装备表单的state字段更新为“借调”并签名；
[0170]
③
表单在通道中进行广播；
[0171]
④
认证联盟依据权限授予规则对申请进行验证与签名，若符合阈值标准便形成批复事务；
[0172]
⑤
事务交由通道成员进行共识；
[0173]
⑥
若共识成功即将事务提交通道事务区块。
[0174]
装备的逻辑与物理访问权限的具体管控方法可以借助基于哈希计数器的权能令牌实现。
[0175]
3.2.2装备归还
[0176]
当需求方结束装备使用或者是装备所属方的本级装备节点因任务需求等原因需收回装备则需要执行装备归还操作。优选的，分为主动归还与被动收回两种模式，如图5所示，其中虚线为被动收回模式，实线为主动归还模式。步骤如下：
[0177]
①
需求方或装备所属方的本级装备节点读取state项为“借调”的装备表单；
[0178]
②
填写表单的description字段，并更新表单的state项为“归还”；
[0179]
③
表单在通道中进行广播；
[0180]
④
认证联盟依据权限取消规则对事务验证，若符合阈值要求则进行签名，并生成归还事务；
[0181]
⑤
事务交由通道成员进行共识；
[0182]
⑥
若共识成功即将事务提交通道事务区块。
[0183]
此时装备中计数器进行迭代。当装备闲置时，本级组织的装备节点可以将装备状态从归还更新为闲置，供下一步装备借调。
[0184]
3.3应急响应权限转移
[0185]
为减轻调控员及参谋的记忆压力，强化应急响应能力提高响应效率，本文通过将触发应急响应的条件与相应的应急响应方案编写成应急响应智能合约库形成自动化、智能化的高效响应机制，满足应急响应条件即可实现相应的调控权限及资源权限的获取。预先设置应急响应的合约模板，它根据条令条例编写了不同应急响应场景下的应急预案，预案是一个智能合约模板，它的输入是紧急情况的证据以及发现情况节点的签名，合约主体一部分是对证据进行判断决定其是否符合条件，另一部分是若符合则通过调用任务权限与装备权限相关合约来完成所需权限的授予。发现情况的节点将紧急情况的证据以及私钥签名作为事务输入，由智能合约判定算法是否符合条件，若符合则将其广播到区块链网络进行共识，若共识成功则触发相应的规则集，按照规则集进行任务表单创建及权能令牌的建立，而应急响应需求则可作为任务基本内容或装备借调理由供相应组织进行快速审核与共识。
[0186]
4调控事务记录模型
[0187]
优选的，动态控制系统还包括记录模块，用于在区块链上记录和更新所述任务表单和/或所述装备表单的创建或修改事件。
[0188]
本技术基于哈希链设计了记录模块，存储任务通道中任务执行相关的数据记录，形成调控事务区块链。
[0189]
调控事务区块链按照时间顺序对网络中发生的事件进行记录，包括任务执行事件
和装备权限操作事件。任务执行事件主要记录包括时间戳信息、任务通道标签、发布任务节点、受领任务节点、任务表单哈希值等信息，装备权限操作事件则记录包括时间戳信息、执行操作的节点、装备表单哈希值、装备操作类型等信息。每条记录均含有由时间戳标记的前序事件的哈希值，由此形成了链接关系，任务执行事件和装备权限操作事件均记录在任务通道账本，如图6所示。通过使用任务表单哈希与装备表单哈希进行哈希寻址，建立调控事务区块链与任务表单及装备表单的关联关系。
[0190]
一种基于区块链的动态控制方法，所述方法应用于动态控制系统，所述动态控制系统包括多个控制单元，每个所述控制单元均包括调控节点、信息节点和装备节点，多个所述控制单元的信息节点构成了基于区块链的共识单元，所述方法包括步骤：
[0191]
所述调控节点创建任务、领取任务和控制任务调控权限的转移；
[0192]
所述装备节点执行任务和控制资源访问权限的转移；
[0193]
共识单元对任务的创建和执行进行共识确认，还用于按照预先设置的权限授予规则对任务调控权限的转移、资源访问权限的转移进行共识确认；
[0194]
信息节点实现所述调控节点、所述装备节点间的信息交互。
[0195]
方法的实现原理、技术效果与上述系统类似，此处不再赘述。
[0196]
本领域的技术人员容易理解，以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。