水库综合信息管理平台关键技术研究与应用
2022-01-12林艳燕金有杰
林艳燕 ,陈 季 ,金有杰
(1. 水利部南京水利水文自动化研究所,江苏 南京 210012; 2. 南京水利科学研究院,江苏 南京 210029;3. 水利部水文水资源监控工程技术研究中心,江苏 南京 210012)
0 引言
截至 2020 年底,全国水利部门共注册登记水库 96 180 座,总库容为 4 816 亿 m3,水库现存业务系统分别在不同的时期建设,没有统一的规划,各自独立运行,形成信息孤岛。以大坝安全渗流监测为例,渗压计测量计算形成水位高程成果值,在实际应用时需要与库水位值或其他环境量进行相关性分析,水库雨水情与大坝安全监控系统由不同的厂家建设,分别部署在不同的服务器上,导致相关的高级应用开发困难,无法提供综合性分析,最终造成水库整体信息化能力低、可视化技术不足的情况,影响了水库安全运行管理工作的高效运行。
为此,建设水库综合信息化管理平台(以下简称管理平台),要求在保证已建系统功能和数据仍能独立使用的前提下,在监控中心层对各雨水情、工情、大坝安全、气象、土壤墒情等多系统数据进行整合,通过构建中心站数据库,将各子系统数据抽取至中心站,实现对水库各子系统监测数据的综合管理,通过提供监测信息汇集应用与共享服务接口,达到资源的合理配置和高效利用,提高水库综合信息监测、管理和应用能力,促进所在流域经济社会持续稳定的发展。
1 管理平台需求与目标
现有大中型水库一般都按需建立了信息化系统,如工情信息管理、雨水情遥测、土壤墒情监测、大坝安全监测、闸门监控及办公管理等系统。原有老系统大多采用 C/S 单机版架构,可扩展性差,客户端须安装在指定机器上,无法进行远程数据查询和视频浏览。新旧各系统间相对孤立,缺少相应的数据融合、分析和预警监视功能。此外,在系统安全性上,并未实现用户分级管理与数据接口的安全性控制,对系统安全性与稳定性造成了影响。为此,水库综合信息化管理系统以平台化为目标,互联网技术为手段,解决水库信息化管理中数据分散、可视化能力低、功能权限分配等问题。
1.1 实现异构数据整合与应用
水库运维过程中,各独立运行的信息系统产生的数据主要包括水库气象、周边土壤墒情、工情,以及大坝安全监测及水文等数据。
对各专业异构数据的汇集有自动上报和主动抓取 2 种方式。从数据的时效性考虑,自动上报优于主动抓取,但实际操作时,自动上报的方式要求各子系统调用由平台端发布的接口将数据实时传至中心端,但大多数水库专业子系统缺乏专门的运维人员,自动上报实现起来有一定难度,因此本研究采用主动抓取的方式。通过构建 1 个基础信息库和多个业务数据库,将各子系统中与基础信息相关的库表迁移至基础信息库,业务数据库表迁移至对应的业务数据库,形成统一的基础信息库与业务数据库。
在积累足够的监测数据后,可利用多元线性回归统计模型或其他常见理论计算方法(如置信区间法、小概率法、极限状态法、结构分析法)确定测点的技术警戒值,实现数据的异常预警。
1.2 提供统一接口服务
管理平台需要依托各业务数据库和基础库开发统一的数据接口,基于数据库设计将服务接口划分为基础数据、专业业务数据、综合服务等 3 类接口,其中基础数据接口主要提供基础信息库的数据维护功能,专业业务数据接口提供单一专业的数据服务,综合服务接口可通过跨 Schema 的联合查询或单一业务的数据组装提供综合性的数据服务。最终形成标准的 RESTful 接口文档,实现一套平台,多种应用,为构建移动端多种应用打下基础,同时为共享交换数据库预留接口,用以实现与其他专业系统或高级应用的数据共享交换。
1.3 提高可视化能力
中小型水库信息化系统大坝安全监测部分主要包括变形、渗流、环境量等的监测,为提高系统可视化能力,管理平台将有效利用各阶段输出的 CAD 工程图,重点增加检测部位的可视化查询功能。
大多数水库的 CAD 工程图纸,贯穿规划、布置、设计、施工、维护全过程,是提高管理平台可视化能力的重要素材。例如:安全监测水工建筑物剖面图和平面图,可用于测点可视化查询;大坝断面图常作为底图,用于浸润线、水位线的可视化查询界面;水库布置图,可展现水库中水工建筑物在整体水库布局的位置,标识重点建筑物或关注位置(如重要断面、溢洪道、泄洪闸)的重点监测信息。
1.4 保证数据安全性
管理平台对外发布统一的 HTTP 数据接口,需要采用一定的鉴权机制[1]实现接口调用过程的安全管理。根据具体业务需求,只对满足权限的用户提供服务,以保证站点数据与基础信息的保密性和安全性。
1.5 实现用户分级管理
管理平台的使用者包括领导、操作员、社会公众等,因此需要对不同级别的用户进行功能权限划分。通过对用户访问的功能菜单进行管理和规划,完成基于用户所属角色的权限分配,可对不同的用户身份进行鉴别,防止用户的越权访问。
2 软件关键技术研究与应用
2.1 基于 ETL 的数据整合
对历史站点的监测数据,采用 Kettle 进行历史数据库的数据迁移与监控[2-3],通过分析源系统数据结构,基于业务制定 ETL 方案,完成源数据库向目标数据库的适配,实现异构数据的平滑流动。Kettle 是一款开源 ETL 工具,数据整合阶段主要使用到其中 2 项产品 Spoon 和 Kitchen:Spoon 允许通过图形界面设计 ETL 转换过程;Kitchen 是一个后台运行的程序,允许批量使用由 Chef 设计的任务。
利用 Spoon,可以开发转换和作业内容,用于构建整个 Kettle 工作流程的基础。转换主要是针对数据的各种处理,1 个转换里可以包含多个步骤。作业相较于转换,是更高级的操作。1 个作业里包括多个作业项,1 个作业项代表1 项工作,而转换是 1 种作业项,即作业里面可以包括多个转换。
为确保已建大坝安全监测系统仍能独立运行,需要利用转换一次性将原有数据库的基础数据迁移至目标库,后续采用作业对实时监测数据进行定时抽取。以红崖山水库大坝安全监测数据定时抽取的作业为例的转换作业如图1 所示,改作业步骤如下:首先基于数据同步表获取所有测点的最新数据时间,再调用子作业“数据同步”将最新的数据同步至中心库,最后执行 SQL 语句更新数据同步表的最新数据时间。利用 Kitchen 组件可实现作业 5 min调度 1 次,保障数据的时效性。其他气象、土壤墒情、雨水情等数据的汇集也可采用类似方法处理。
图1 转换作业实例
2.2 基于 Druid 的动态数据源配置
数据访问层采用动态数据源技术,管理平台可设置多个数据源,根据配置项决定加载 1 个或多个数据源。Druid[4]是一个开源的分布式的支持实时分析和摄入的数据存储系统,每个 Druid 进程都可以独立配置和扩展,各数据源相互独立,为系统提供最大的灵活性。
利用 Druid 将数据库按业务分类:大坝数据源配置为大坝安全监测数据库,为大坝安全监测提供服务接口;雨水情数据源配置为雨水情数据库提供雨水情相关服务接口;气象数据源配置为气象服务提供数据接口;墒情数据源提供土壤墒情数据服务;公共数据源包括水库基础信息数据库和测站信息,用于提供公共的服务接口。管理平台针对公共业务开发通用的数据服务接口,同时在控制层灵活地对业务接口进行基于具体业务的组装使用。管理平台基于 Springboot 开发,集成 Swagger 组件发布数据接口 UI 界面,可利用可视化界面模拟接口请求,在应用系统开发时降低前后端联调的沟通成本,为基于管理平台的多端应用开发提供良好的支撑。
2.3 基于 WebGIS 的可视化查询
利用 CAD 工程图实现可视化查询功能,需要完成 DWG 文件的转换 、发布、加载 3 个步骤。首先利用 ArcMap 将 DWG 的点线面分别转换成 SHP 格式,然后利用 GeoServer 添加 SHP 数据并发布为点线面图层,最后利用 OpenLayesr.js 加载并操作图层完成可视化查询功能。
2.3.1 CAD 制图的转换与处理
CAD 制图成果是 DWG 文件,DWG 是基于 CAD保存设计数据所用的一种专有文件格式,但实际 GIS 应用中,离不开 SHP 文件。SHP 是一种空间数据开放格式,已成为地理信息软件界的一个开放标准。因此,需要利用 ArcMap 对 CAD 进行按需转换,转换时只需关注和业务相关的图层文件并做针对业务的处理。
出于方便人为的管理, CAD 中每个图层文字、点、线、面都可以画,在 ArcGIS 中每个图层强制按照点线面划分,在此基础上再按照人为因素划分。因此在做图层导出时,需要针对点、线、面分别进行,再根据业务的需要对属性表做相应的处理,ArcMap 的属性表中记录着图层各个要素的信息,通常结合实际业务数据库做字段的增加或删除。
2.3.2 SHP 文件的发布
在进行图层发布时,采用风格化图层描述器 SLD[5]对地图可视化的表现形式进行扩展。没有 SLD 标准前,只能使用一些已经在服务器上规定好的样式对地图进行可视化;使用实现了 SLD 标准后,允许从客户端进行图层样式的渲染、分级显示等操作,极大地扩展了地图可视化的灵活性。
2.3.3 图层的加载与应用
OpenLayers 是专为 GIS 客户端开发提供的 JavaScript 类库包,用于实现标准格式发布的地图数据访问,管理平台利用 OpenLayers 加载点线面图层。目前 CAD 图纸大多应用在平面布置图和断面浸润线的功能页面中:平面布置图一般用于查看测点在水工建筑物中的具体位置,可进行拖拽、放大、缩小等操作;浸润线的加载较平面布置图的加载更为复杂,除了基础点线面图层的加载外,还需要记录测点在图层标尺上的相对位置,根据实测水位高程推算渗压水位在标尺上的位置。图2 为利用断面 CAD 图实现的浸润线功能,图中包含 2 个渗压监测点,当黑色浸润线高于红色警戒线时,说明当前渗压计计算的水位高程偏高,需要引起注意。
图2 利用 CAD 图绘制的大坝断面浸润线
2.4 访问控制
2.4.1 角色权限访问控制
管理平台以 RBAC(Role-Based Access Control)模型为基础,基于 Apache Shrio 的权限控制框架,实现用户权限的控制与功能的可扩展。RBAC 又称为基于角色的访问控制[6],在 RBAC 模型中,一个平台用户拥有若干角色,每个角色拥有若干权限,构造成用户-角色-权限的授权模型,用户与角色之间,角色与权限之间,一般都是多对多的关系。最终实现的功能模块主要包括组织机构管理、用户角色管理、用户权限设置等内容。
Apache Shrio 包含以下 3 个核心组件:1)Subject(主体)。主体是任何可以与应用交互的用户。2)SecurityManager。SecurityManager 是 Shiro的心脏,所有具体的交互都通过 SecurityManager 进行控制,管理着所有 Subject,且负责进行认证和授权,以及会话、缓存的管理。3)Realm。Realm 是与安全相关的 DAO(Data Access Object),它封装了数据源的连接细节,并在需要时将相关数据提供给 Shiro。在实际应用中,1 个 Realm 可负责校验 1 类令牌(Token),目前管理平台中集成了 2 个 Realm,1 个用于鉴别基础的用户名密码 Token,另 1 个用于鉴别 JWT(JSON Web Token)Token。
2.4.2 接口访问控制
在角色访问控制基础上,为防止外部恶意调用数据接口,管理平台结合 JWT 鉴权实现数据接口的访问控制,JWT 是一种基于 JSON 的用于在网络上声明某种主张的 Token。用户在登录验证成功后,后台返回给请求源 1 个Token,接下来任何的数据请求都必须将 Token 放在 HTTP 请求的头部,任意的成功数据请求后台都会更新 Token,更新后的 Token 保留原先 Token 的所有数据信息,只刷新过期时间,从而维护 Token 的时效性。JWT 鉴权开销小,Token 只需要在客户端保留,服务端不用保存Token,分布式环境下后端无需再做 Session 共享,为后期系统由单体应用向分布式演化提供方便,同时,JWT 鉴权适用于前后端分离的开发模式,为管理平台后端服务安全性提供技术支撑。JWT 由以下 3 个部分组成:1)头信息,指定该 JWT 使用的签名算法;2)消息体,包含 JWT 的意图,如 userId,roleId,expireTime 等;3)签名,是对前两部分的签名,防止数据被篡改。
签名首先需要指定 1 个秘钥,这个秘钥只有服务器知道,不能泄露给用户,然后使用 Header 里面指定的签名算法(默认是 HMAC SHA256)产生签名。算出签名后,Header,Payload,Signature 3 个部分拼成 1 个字符串,每个部分之间用(.)分隔,再返回给用户。
3 管理平台开发与工程应用
管理平台软件采用 SpringBoot 框架[7]开发,SpringBoot 不仅继承了 Spring 框架原有的优秀特性,还通过简化配置进一步简化了 Spring 应用的整个搭建和开发过程。另外 SpringBoot 通过集成大量的框架,使得依赖包的版本冲突及引用的不稳定性等问题得到了有效控制。管理平台现可适配多主流数据库厂家,基于通用业务接口能够实现应用的快速搭建与部署,已成功部署的项目包括单水库项目 4 个,区域多水库项目 2 个。图3 为管理平台在红崖山水库的应用截图,红崖山水库涵盖的业务包括大坝安全监测分析、人工位移对比、雨水情监测、水质监测、蒸发监测、道闸控制等。
图3 红崖山综合监控界面
通过多元监测数据的融合与应用,管理平台可满足水库管理各级用户的需要,现已在广东、甘肃、安徽、四川、江苏等省得到应用,经济和社会效益显著。可有效解决水库管理单位信息化缺乏统一规划、运行环境差别大、系统生命周期短,以及集成度低而造成不兼容、难以整合发挥协同作用等问题,实现水库由粗放管理向精细化管理转变,由传统人工管理为主向水利现代化管理为主转变。
4 结语
通过对水库信息化现状进行分析,结合 ETL 工具,Druid 多数据源,WebGIS 等技术开发水库综合信息化管理平台,管理平台具备良好的可扩展性和移植性,可减轻水库管理人员工作强度,同时保证监测数据的及时性。今后管理平台将进一步实现实时信息的统一采集,加强各专业子系统间实时数据的交互。以机器学习和业务模型相结合的方式,在基于数字孪生的平台环境下,深度融合和挖掘有效信息,当出现不利于工程安全运行的场景条件时,能自动对大数据进行分析评估,提供智能预警与辅助决策,为汛期水库安全运行提供保障。