一种残膜回收机防缠绕挑膜装置的制 一种秧草收获机用电力驱动行走机构

一种基于联盟链的地质灾害应急指挥系统的制作方法

2022-02-22 08:40:53 来源:中国专利 TAG:


1.该发明涉及地质灾害领域,尤其涉及一种基于联盟链的地质灾害应急指挥系统。


背景技术:

2.地质灾害具有突发性、隐蔽性、破坏性强等特点,灾害发生后严重影响了人民生命和财 产安全。
3.地质灾害发生后,需要多个政府部门与各企事业单位开展充分协调合作,及时制定高效、 有序的防控和治理方案,减少人们生命和财产损失。然而,灾害发生后的应急指挥系统涉及 应急管理、自然资源、安监、公共安全、通讯、民政、财政等多个职能部门,政府机构与研 究机构、政府与企事业单位、政府与社会民众之间形成横向与纵向的功能交叉,是一个错综 复杂的系统。
4.地质灾害发生后,应急指挥系统依然存在着一些问题,比如,缺少权限更高的机构统一 协调各单位和部门的行动方案,缺乏多部门协作运行机制的相关规定和约束,部门之间因职 责不清而导致利益冲突,部门与部门之间沟通不顺畅,数据和信息公开不及时、不准确等。


技术实现要素:

5.针对上述技术的不足,本发明的目的在于提供一种基于联盟链的地质灾害应急指挥系 统,用以解决地质灾害发生后,应急指挥系统中的各部门对灾害数据的获取速度慢以及各部 门之间的沟通和协作不畅,导致各部门不能在地质灾害发生后及时作出响应的问题。
6.为了达到上述目的,本发明采取的技术方案如下:
7.一种基于联盟链的地质灾害应急指挥系统,包括数据层、网络层、共识层、合约层和 应用层;
8.所述数据层位于联盟链的各节点中,用以存储关于地质灾害的专业监测数据和辅助分 析数据;
9.所述网络层用于构建联盟链,且联盟中各节点之间采用p2p传输方式,各节点之间通 过远程服务访问接口进行通信;
10.所述共识层嵌套在联盟链的链码中,用以对请求方上传至联盟链内的消息摘要的签名、 授权、数据结构的正确性等进行验证;
11.所述合约层由联盟链内的各节点共同商定,采用javascript语言将相关的地质灾害应急 处理标准、规范、指南等编码为智能合约,形成可执行代码,经各节点同意后部署到联盟链 并在链上运行;
12.所述应用层对请求方发出的地质灾害应急指挥提案进行处理和响应,并将处理结果反 馈给联盟链上对应的应急指挥服务机构节点。
13.进一步限定,所述专业数据包括但不限于卫星遥感、无人机倾斜摄影、雨量计、应
力 计、裂缝计、钻孔倾斜仪、位移计、测斜仪、光纤、微地震监测、重力监测、声波仪和次声 探测仪测量所得数据,所述辅助分析数据包括但不限于风力、温度、降雨、地震和坡体挖掘 数据。
14.进一步限定,所述联盟链中的节点包括但不限于自然资源、应急管理、卫生健康、地 震、气象、交通、水利、民政、财政各政府职能部门和研究自然灾害的科研机构。
15.进一步限定,所述联盟链内的各节点通过实用拜占庭容错算法(pbft)对应急指挥方 案进行响应,请求方收集各节点的数据和处理结果打包反馈到联盟链应急指挥服务机构进行 验证、排序和记账,并将响应结果传输给应急指挥中心,由中心统一调度灾害点的应急救援、 专业监测、防护治理、灾后重建、卫生健康和宣传报道等。
16.进一步限定,所述数据层、网络层、共识层、合约层和应用层均采用模块化设计。
17.进一步限定,所述应急指挥服务机构节点具有执行智能合约编码、msp授权管理、账 本记账、账本广播、与应急指挥中心通信和网络维护功能。
18.进一步限定,所述请求方具有联盟链应急指挥服务机构发布的数字证书ca,通过密钥 进入联盟链,将应急指挥提案通过api接口和sdk程序包发布到联盟链的其他节点。
19.进一步限定,所述应急指挥提案的交易流程为:
20.(1)节点1收到客户端发出的提案后,对提案进行检查和背书。
21.(2)节点1对包括acl权限、地址、数字签名等检查在内的各种检验,通过后则创 建模拟执行环境。
22.(3)执行环境调用相关地质灾害应急处理标准、规范、指南等编码形成的智能合约,对 提案进行认证和处理。
23.(4)将处理结果发给背书节点,组成新的区块,节点1将新的区块添加数字签名和时间 戳后发送给节点2,并将处理结果反馈给客户端。
24.(5)节点2循环步骤第(1)-(4),将新的区块添加数字签名和时间戳后发送给下一节 点。
25.(6)客户端将所有节点的反馈的结果打包到一起,对上一组交易认证并签名,通过通道 发送给联盟链应急指挥服务机构。
26.(7)联盟链应急指挥服务机构是由背书策略指定的节点,同时具有排序服务节点、交易 节点、记账节点、维护网络稳定和安全的功能。
27.进一步限定,还包括所述共识层内的共识机制,所述共识机制采用实用拜占庭容错算 法对请求方发出的地质灾害应急指挥提案进行处理和响应。
28.进一步限定,所述共识层中的实用拜占庭容错算法流程如下:
29.(1)请求方(客户端)节点发起提案请求:请求方(客户端)寻找联盟链内最近的节 点作为主节点(节点2),通过api sdk向主节点发送请求调用服务操作;
30.(2)主节点广播(pre-pre):节点2收到请求端节点的请求后进行广播,广播至节点 1、3和4;
31.(3)节点广播(promise):节点1、3和4收到广播并对消息处理完后,再次向联盟 链中的其他节点广播消息,比如,节点3将收到的消息处理后再将消息传播至1、2、4。
32.(4)执行请求(commit):节点1-4在节点广播阶段,如果收到2f 1以上数量相同 的请求,则进入执行请求阶段,开始广播执行请求。
33.(5)反馈(reply):节点1、2、3、4在执行请求阶段,如果收到2f 1以上数量的相 同请求,则对请求方(客户端)节点反馈处理结果。
34.(6)所有节点都执行请求并将结果发回请求方(客户端),请求方需要等待f 1个不 同节点返回相同的结果,作为整个操作的最终结果。
35.在pbft算法中,如果满足n≥3f 1,其中n为总节点数,f为有故障的节点总数。
36.本技术方案的工作原理为:本发明将区块链的联盟链应用于地质灾害的应急指挥,各 政府职能部门、企事业单位、社会公众均可参与到应急指挥中,实现了部门去中心化功能, 降低了因单个部门应急策略不当、应急措施延缓而造成巨大损失的风险;相关的地质灾害应 急处理标准、规范、指南等形成的智能合约,保障了各政府职能部门的协作运行机制;基于 p2p网络和广播式传播的消息传播机制,使得应急处理方案和部门响应能及时送达各部门, 并得到信息反馈,提高了应急指挥的效率;实用拜占庭容错(pbft)算法使得各部门之间 遵守“共同表决、少数服从多数”的原则,解决了各部门沟通不畅的问题,提高了各部门的 共识信任、统一协作的效率;分布式存储、哈希加密、数字签名等技术的融合,提高了网络 数据传输的安全性和稳定性。
37.本发明的技术效果如下:该发明运用了区块链非中心化、数据防篡改、可追溯、隐私 保护、共识信任、开放、共享等优点,使地质灾害发生后的应急指挥更加专业化、规范化、 灵活化,提升了应急指挥系统各部门之间的沟通和协同工作的效率,使各部门之间能第一时 间对地质灾害作出响应,最大程度地减少地质灾害发生后造成的损失,对于高效保障人民的 生命和财产安全具有重要意义。
附图说明
38.图1为本具体实施方式中地质灾害应急指挥系统示意图;
39.图2为本具体实施方式中地质灾害应急指挥系统结构示意图。
40.图3为本具体实施方式中地质灾害应急指挥提案交易流程示意图。
41.图4为本具体实施方式中应急指挥提案交易共识机制工作示意图。
具体实施方式
42.下面通过具体实施方式进一步详细说明:
43.图1示例了一种基于联盟链的地质灾害应急指挥系统。主要包括区块链的数据层、网络 层、共识层、合约层和应用层,合约层和共识层嵌套在联盟链的链码中。其中,数据层为存 储在分布式数据库中的有关灾害点的各种监测数据。专业监测数据包括但不限于卫星遥感、 无人机倾斜摄影、雨量计、应力计、裂缝计、钻孔倾斜仪、位移计、测斜仪、光纤、微地震 监测、重力监测、声波仪、次声探测仪等,辅助分析数据包括但不限于风力、温度、降雨、 地震、坡体挖掘等。地质灾害发生后,由政府成立应急指挥中心,协调统一各部门的应急工 作。组织相关专家针对地质灾害发生的原因、二次灾害的可能性、应急处理的措施等开展研 判,由政府批准后确定应急指挥方案,采用p2p的传输方式将方案发送给联盟链内的各政府 职能部门(节点)。
44.为了保证应急指挥方案在网络传输中的保密性和安全性,通过sha 256算法将方案转化 为长度为32个字节(256位)的消息摘要,添加数字签名和时间戳后再传输至联盟链
中。
45.联盟链内的节点包括但不限于自然资源、应急管理、卫生健康、地震、气象、交通、水 利、民政、财政等各政府职能部门和相关科研机构,各节点均部署了以相关地质灾害应急处 理标准、规范、指南等形成的智能合约,智能合约以javascript语言编码形成,包含在节 点内的链码中。联盟链内各节点有相同的账本副本,记录了链内所有节点的交易记录。各节 点采用通道技术进行通讯,由联盟链的服务机构负责保障整个链的安全运行、分发数字证书 等。
46.联盟链内的各节点通过实用拜占庭容错算法(pbft)对应急指挥方案进行响应,客户端 收集各节点的数据和处理结果打包反馈到联盟链服务机构进行验证、排序和记账,并将响应 结果传输给应急指挥中心,由中心统一调度灾害点的应急救援、专业监测、防护治理、灾后 重建、卫生健康、宣传报道等,保障地质灾害应急指挥高效、协同、有序的开展。
47.图2示例了一种基于联盟链的地质灾害应急指挥系统结构。自上而下主要包括应用层、 合约层、共识层、网络层和数据层,其中,共识层和合约层嵌套在联盟链的链码中。各层采 用模块化功能设计,系统开发时根据应用场景的需求可灵活调用相应的模块。
48.数据层位于联盟链的各节点中。各类专业监测数据和辅助分析数据存储在分布式数据库 中。地质灾害发生后,从不同部门的数据库中调用灾害点相关的数据,经专家会商和研判、 政府批准后形成对灾害点的应急指挥方案。
49.为了保证应急指挥方案在网络传输中的保密性和安全性,通过sha 256算法将方案转化 为长度为32个字节(256位)的消息摘要,添加数字签名和时间戳后再传输至联盟链中。
50.网络层通过通道技术建立联盟链,各节点采用p2p传输方式,节点之间彼此通过远程服 务访问接口(grpc)消息进行通信。通过gossip协议来进行状态同步、数据分发和信息交换。 节点会定期调用gossip协议搜索账本的最新数据,并对发送消息进行签名认证。此外,联 盟链内的各节点可以为某一个政府职能部门,或某一台通过授权的电脑,利用msp (membership service providers)来控制节点的权限,msp管理机构为各部门均同意授权 管理的联盟链服务机构,该节点执行智能合约编码、msp授权管理、账本记账、账本广播、 与应急指挥中心通信、网络维护等功能。
51.共识层和合约层共同嵌套在联盟链的链码中。首先节点需要对请求方上传至联盟链内的 消息摘要的签名、授权、数据结构的正确性等进行验证,通过背书节点模拟执行交易及签名、 排序服务节点对接收到的提案进行共识排序,按照区块生成策略,将应急指挥提案生成新的 区块,发送给提交节点进行校验,检查提案依赖的输入输出是否符合当前联盟链的状态,完 成交易并记录到账本中。
52.合约层由联盟链内的各节点共同商定,采用javascript语言将相关的地质灾害应急处 理标准、规范、指南等编码为智能合约,形成的可执行代码通过链码实现。可执行代码可根 据应用场景的需求由联盟链服务机构进行修改,经各节点同意后部署到联盟链并在链上运 行,各节点必须遵守智能合约的规定。
53.应用层包括但不限于应急救援、专业监测、防护治理、灾后重建、卫生健康、宣传报道、 相关科研等机构(节点),对请求方(客户端)发出的地质灾害应急指挥提案进行处理和响 应,并将处理结果反馈给联盟链应急指挥服务机构(节点),该节点执行智能合约编码、
msp 授权管理、账本记账、账本广播、与应急指挥中心通信、网络维护等功能。
54.图3示例了一种基于联盟链的地质灾害应急指挥提案交易流程。主要包括持有密钥和数 字证书ca的客户端,对应急指挥提案进行处理的联盟链节点,实现排序、记账、广播账本 的节点。客户端具有联盟链服务机构(节点)发布的数字证书ca,通过密钥进入联盟链,将 应急指挥提案通过api接口和sdk程序包发布到联盟链的其他节点。各节点采用p2p传输方 式,节点之间彼此通过远程服务访问接口(grpc)消息进行通信。通过gossip协议来进行状 态同步、数据分发和信息交换。
55.联盟链通过通道技术建立彼此节点的通信。应急指挥提案的交易流程为:
56.1.节点1收到客户端发出的提案后,对提案进行检查和背书。
57.2.节点1对包括acl权限、地址、数字签名等检查在内的各种检验,通过后则创建模 拟执行环境。
58.3.执行环境调用相关地质灾害应急处理标准、规范、指南等编码形成的智能合约,对 提案进行认证和处理。
59.4.将处理结果发给背书节点,组成新的区块,节点1将新的区块添加数字签名和时间 戳后发送给节点2,并将处理结果反馈给客户端。
60.5.节点2循环步骤第1-4,将新的区块添加数字签名和时间戳后发送给下一节点。
61.6.客户端将所有节点的反馈的结果打包到一起,对上一组交易认证并签名,通过通道 发送给联盟链服务机构(节点)。
62.7.联盟链服务机构(节点)是由背书策略指定的节点,同时具有排序服务节点、交易 节点、记账节点、维护网络稳定和安全的功能。
63.该节点记录联盟链内其他节点的运行结果,通过实用拜占庭容错算法pbft对各节点的 处理结果进行处理,遵守“少数服从多数”的原则判断提案结果是否一致,验证通过后,对 背书过的节点的顺序进行排序,把新的交易添加到账本中,并将更新后的账本广播至联盟链 内的所有节点,更新各节点的分布式账本。
64.图4示例了一种基于联盟链的地质灾害监测应急指挥提案交易共识机制。该发明涉及的 共识机制,联盟链内的各节点对请求方(客户端)发起的同一事件进行判断,遵守共同表决、 少数服从多数的原则,采用实用拜占庭容错算法(pbft)对请求方发出的地质灾害应急指挥 提案进行处理和响应,提高灾害发生后各部门职能分工、共同协作的决策效率,提高各部门 的共识信任。
65.共识算法采用实用拜占庭容错算法(practical byzantine fault tolerant,pbft), 解决了原始拜占庭容错算法效率不高的问题。pbft是一种状态机制副本复制算法,即服务作 为状态机进行建模。状态在分布式系统不同节点进行副本复制。pbft共识算法各个节点由应 急指挥涉及的职能部门(业务方,比如自然资源、公共安全、安全监督、卫生健康等部门) 和监督方(联盟链服务机构)组成。安全性与稳定性由联盟链服务机构保证,共识效率高。
66.联盟链中的节点共同遵循智能合约,通过交换信息而达成共识,并按照相同的分工合作 策略行动,提高了各部门共识信任、统一协作的效率,保障各政府职能部门稳定、有序的应 急运行机制。
67.该共识算法针对每一个请求方(客户端)的提案,需要经过主节点广播、节点广播、
执 行请求、反馈4个阶段才能完成。pbft的算法流程如下:
68.1.请求方(客户端)节点发起提案请求:请求方(客户端)寻找联盟链内最近的节点 作为主节点(节点2),通过api sdk向主节点发送请求调用服务操作;
69.2.主节点广播(pre-pre):节点2收到请求端节点的请求后进行广播,广播至节点1、 3和4;
70.3.节点广播(promise):节点1、3和4收到广播并对消息处理完后,再次向联盟链 中的其他节点广播消息,比如,节点3将收到的消息处理后再将消息传播至1、2、4。
71.4.执行请求(commit):节点1-4在节点广播阶段,如果收到2f 1以上数量相同的请 求,则进入执行请求阶段,开始广播执行请求。
72.5.反馈(reply):节点1、2、3、4在执行请求阶段,如果收到2f 1以上数量的相同 请求,则对请求方(客户端)节点反馈处理结果。
73.6.所有节点都执行请求并将结果发回请求方(客户端),请求方需要等待f 1个不同 节点返回相同的结果,作为整个操作的最终结果。
74.在pbft算法中,如果满足n≥3f 1,其中n为总节点数,f为有故障的节点总数,那 么最终对地质灾害应急指挥方案的一致性是可以达成的,从而解决了灾害发生后各部门之间 缺乏共识和信任的问题。
75.需要提前说明的是,在本发明中,除非另有明确的规定和限定,术语“安装”、“相连”、
ꢀ“
连接”、“固定”等术语应做广义理解,例如,可以是固定连接,也可以是可拆卸连接, 或一体地连接;可以是直接相连,也可以通过中间媒介间接相连,可以是两个元件内部的连 通。对于本领域的普通技术人员而言,可以根据具体情况理解上述术语在本发明中的具体含 义。
76.以上所述的仅是本发明的实施例,方案中公知的具体结构及特性等常识在此未作过多描 述。应当指出,对于本领域的技术人员来说,在不脱离本发明结构的前提下,还可以作出若 干变形和改进,这些也应该视为本发明的保护范围,这些都不会影响本发明实施的效果和专 利的实用性。本技术要求的保护范围应当以其权利要求的内容为准,说明书中的具体实施方 式等记载可以用于解释权利要求的内容。
再多了解一些

本文用于企业家、创业者技术爱好者查询,结果仅供参考。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

相关文献