李 潇，许飞青，于 喆，韩 征，李 凯，郭亚杉，冒 建

（1.北京市地质矿产勘查院信息中心，北京 100195；2.北京市地质研究所，北京 100120）

北京市位于华北平原西北隅，是世界上突发地质灾害较为频繁的首都城市之一，灾害形式以泥石流、崩塌、滑坡、采空塌陷为主，主要分布在北山和西山的沟谷、陡坡、矿山分布集中地区及新构造活动较强烈的地区（北京市地质矿产勘查开发局等，2008）。北京市人口密度大，经济社会发展程度高，自1949年以来，各类突发地质灾害造成的死亡人数已超过600人，直接经济损失达数亿元。2012年7月21日，自有气象记录以来的最大降雨，给首都带来一场特大自然灾害并诱发了崩塌、泥石流、滑坡等次生地质灾害，造成了严重的人员伤亡和财产损失。

2000年以来，全国各省市陆续着手建立地质灾害监测预警系统。三峡库区较早地建立了地质灾害监测预警信息管理系统（刘传正等，2004），浙江、江苏、天津等省市也都分别针对各自地区的地质条件特点建立了基于WebGIS的监测预警系统（余风华等，2006；单玉香等，2007；董元等，2008；王爽等，2012）。北京市在2003年启动了地质灾害气象预报预警工作，并在基于GIS的地质灾害预警、评价以及相关信息系统建设等方面做了一系列的积极探索（文斌等，2007；白利平等，2009）。这一阶段建立的系统基本以预警评价分析为主，自动化程度不高。

随着基于GIS技术的专业分析日渐成熟和新一代移动通信、云计算、大数据以及北斗卫星、5G等技术迅猛发展，基于前端感知、网络传输、应用分析三级结构的物联网技术也逐步应用于地质灾害监测体系（朱永辉等，2010；何文娜，2013；李超岭等，2015；Baum et al.，2010），各省市也在纷纷探索运用新技术建立地质灾害监测预警信息系统（黄健，2012；徐永强等，2013；杜金星等，2014；杨雪艳等，2015；贾进科等，2016），在数据快速获取和自动预警方面取得了一定成果。但总体基本以单灾种、小区域范围建立的孤立系统居多，且在多种监测数据采集汇聚上受标准不一致的制约未能很好地解决，针对崩滑塌多灾种、监测设备多样化、监测点数量多、多种模型集成统一的大型信息系统更不多见。由于地质条件和气候的差异性，已有的一些较为成熟的预警模型并不适用于北京。2018年北京市启动建设基于新一代信息技术的、涵盖突发地质灾害监测预警工作全流程的信息系统，并在全面、快速地获取隐患点监测信息，自动、智能地完成信息处理流程，精细、准确地生成预警分析产品，便捷、直观的成果查询展示，低成本、集约化的建设运行投入等方面取得了积极成效。

本文详细介绍了北京市突发地质灾害监测预警系统的功能与总体设计，论述了系统采用的关键技术，并举例介绍了系统实现的应用案例。相关技术成果和方法可为突发地质灾害监测预警工作提供有效参考和借鉴。

1 系统总体架构与功能设计

北京市突发地质灾害监测预警信息系统是实现从监测数据采集、集成、管理、分析、预警预报的全流程业务系统，是以物联感知技术、传输通讯技术、信息化软硬件环境为基础，以地理信息平台、大型数据库平台为支撑，在行业标准体系和信息安全规范体系的框架下，对地质灾害监测成果、调查成果、评价成果等结构化、非结构化、空间的多源数据进行汇聚、融合和集成，构建系统应用，实现设备管理、数据管理、预警分析、应急指挥、三维展示、数据共享等功能，为政府决策、专业人员和社会公众提供北京突发地质灾害信息成果服务。其总体技术架构从下向上分别为物联感知层、基础层、数据层、支撑层、服务层和用户层（图1）。

图1 北京突发地质灾害监测预警信息系统架构图Fig. 1 Structure diagram of Beijing sudden geological disaster monitoring and early warning information system

（1）物联感知层依托物联网技术，对地质灾害隐患点进行监测数据采集，将获取的数据通过移动互联网、专线网络、北斗卫星通道等方式传输至基础层。

（2）基础层全面依托于云平台，按需使用计算、存储、网络、安全服务等资源，并将从物联感知层接收的数据推送至数据层进行汇聚、融合和处理。

（3）数据层实现对数据资源的处理入库和数据库的管理维护。

（4）支撑层将应用所需的GIS组件、三维模型组件、预警模型库、各类接口、标准及数据服务等进行模块式封装，为服务层的预警分析、查询展示、决策支持等应用提供支撑，为其他系统对接共享时提供调用服务，满足基于自定义的组件调用、快捷开发及专业技术人员的差异化需求。

（5）服务层面向不同用户按需提供差异化系统应用。

（6）用户层面向政务用户提供政务网络访问页面，公共用户通过公共服务接口和共享发布接口访问系统。

北京市突发地质灾害监测预警系统设计了8个子系统、1个APP、1个公众号共10部分，采用B/S与C/S相结合的软件体系架构，面向专业技术人员、政府主管部门人员和社会公众三大类用户提供差异化系统功能服务（表1）。

表 1 北京市突发地质灾害监测预警系统主要功能Tab. 1 The main functions of the sudden geological disaster monitoring and early warning system in Beijing

2 系统技术体系设计

2.1 基于物联网技术的数据监测

北京市突发地质灾害监测以泥石流、滑坡、崩塌和采空塌陷为主要监测对象，以变形、物理场、诱发因素等为监测内容，以自动监测为主要方式，通过埋设监测设备传感器将各类监测数据采集、传输，通过统一接口接入信息平台并分析处理，整体过程形成了由感知、传输、应用的物联网架构体系。其中，形变、诱发因素、物理场等监测信息经传感器设备采集后，通过GPRS或北斗传输汇聚，视频监测数据通过网络专线传输，最终统一在云端汇聚融合和应用（图2）。

图2 北京突发地质灾害物联网监测示意图Fig. 2 Schematic diagram of Internet of things monitoring of sudden geological disasters in Beijing

2.2 基于北斗与GPRS相结合的通信方式

突发地质灾害主要发生在山区，传统监测设备传输数据的通信方式主要依靠移动通信网络，在山体崩塌、滑坡或泥石流等大型灾害发生时，往往会因电力和通信网络中断导致在灾害发生的关键时刻监测数据却无法传输的问题。北京市突发地质灾害监测预警系统的监测传感设备采用了北斗与GPRS相结合、双通道互补切换的技术，通过在前端监测点及后端数据中心分别配备北斗用户机，利用北斗卫星系统短报文功能，在GPRS信号中断时及时切换卫星通信模式，实现监测数据通信传输的双通道保障。

2.3 基于云技术的IT资源支撑

北京市突发地质灾害监测预警工作具有显著的季节特征，其关键时间主要集中在6—9月的汛期。在非汛期，监测频率、传输频率及系统需处理的数据量和分析计算量很小；而入汛后，为有效发挥监测和预警预报作用，系统需要7×24 h不间断的进行数据采集和分析，监测频率、传输频率大幅提高，数据处理、分析、预警计算等需求大大增加。仅以汛期视频摄像头监控为例，视频服务的平均在线带宽资源需求100 M·s-1，流媒体转发服务平均24路同时在线，平均同时服务于5个用户部门；在非汛期，访问量大幅减少。在应对计算资源、存储资源、网络资源的弹性需求上，固定计算存储资源建设方式显现出其局限性，峰值需求难以满足、闲时又产生资源浪费，因而云技术对于满足信息资源按需分配的需求具有明显优势。

该系统运行所需的各类IT资源、基础运行环境都通过北京市政务云平台来实现。北京市政务云的总体服务架构包含基础设施服务、互联互通服务、应用支撑服务、业务应用服务、安全服务体系和运维服务体系，基于该平台，系统能够统筹集约从基础层到应用层所需的各类信息资源、虚拟层之下的信息安全服务和运维服务，极大地提升了资源使用效率，节省了人力和物力成本。

2.4 基于Web GIS技术的空间信息服务平台

系统的GIS服务基于ArcGIS 10.2进行二次开发，实现基本的空间分析和二三维展示功能，GIS的基础开发环境为ArcGIS Engine组件库。

在开发模式上采用了B/S与C/S相结合的软件体系，将地图发布、空间信息查询、展示等服务应用在B/S端实现，将复杂的空间信息操作、专业预警、分析计算等应用功能在C/S端实现后再同步到B/S端。这种模式既保证了交互式、分布式、动态的地理信息服务响应效果和效率，为与其他信息系统平台集成提供了良好的扩展性，同时又有效避免了当前Web技术对海量空间数据进行查询和复杂专业计算的局限性（刘光等，2015），满足系统使用的快捷性、安全性、高效性和灵活性的要求（汤国安，2019）。

系统充分利用二三维GIS技术融合，在地图实时表达、空间分析、三维模拟等多方面进行深度应用，提高专业表达能力。三维GIS技术在系统中的应用主要体现在2个方面:一是突发地质灾害三维场景的真实表达，这其中包括利用影像、DEM对各隐患点进行真实三维环境的展现，也包括在三维场景中对监测数据和设备的三维立体显示；二是预警分析结果的三维表达，泥石流预警模型本质是数学模型与空间分析相结合的计算实现，在C/S端特定二维/三维场景下通过预警模型计算得到的预警成果、泥石流淹没范围、预警剖面等结果在Web端的三维环境下展示更为专业和直观。

3 系统关键技术研究

目前，突发地质灾害监测主要采用信息化监测为主、群测群防员巡查为辅的方式，技防与人防相结合。已有的信息化监测体系缺乏指导标准，对于同类灾害的监测内容、监测方法并不统一，监测设备数据传输格式多样，获取的多源数据在存储管理和利用时不能有效互通。因此系统关键技术研究以问题和需求为导向，自上而下形成了贯穿业务全流程的完整体系（图3），在系统架构的各层均有与解决问题对应的关键技术，主要包含监测方法重分类、监测设备统一通讯规约、多源异构数据资源集成技术及预警模型库建立等。

图3 北京突发地质灾害监测预警系统关键技术逻辑图Fig. 3 The logic diagram of key technologies of Beijing sudden geological disaster monitoring and early warning information system

3.1 基于地质要素的监测方法分类

地质专业的监测通常按照不同专题类型来分类，例如地裂缝监测、地下水水质监测、地面沉降监测等，突发地质灾害监测也是从专题类型的角度来命名的。但不同的监测对象比如崩塌和滑坡，二者在监测的内容和方式上基本相同，在同一地理位置点上的监测内容和方法可以统筹利用。从建立统一数据分类标准的角度来说，在监测方法选用和监测设备布置时应充分考虑到监测对象、地质要素分类和监测方法分类之间的关系。

该系统在建立之初，就突破了以往同类型系统采用的监测分类方法，通过对传统监测网进行拆解、归并、优化处理和概化，梳理出按照地质要素重分类的方法，建立监测对象与地质要素分类之间的对应关系，旨在为系统后续的数据三重分类切割奠定基础。其中突发地质灾害监测涉及到的地质要素主要包括地表形变、地层形变、物理场（应力监测、次声监测、微震监测）、诱发因素（降雨量监测、人类活动监测）和其他要素（土壤含水率监测、水位水量监测、实时视频监控、泥位监测、流速监测）几大类（图4）。

图4 基于地质要素分类方法示意图Fig. 4 Based on geological elements classification method schematic diagram

3.2 物联监测设备统一通讯规约

地质灾害监测工作中涉及到的物联感知设备数量众多、种类多样（图5）、厂商不一、通讯协议无行业标准可遵循，各设备厂商往往都提供自行开发的数据接收软件，对于兼容几十种品牌类型监测设备的信息系统而言，这样的方式会产生监测设备难以统一管理、不同软件接收的设备数据格式不一致、出现问题运维权责难界定、数据接收异常原因难以排解等问题。

为解决上述问题，首先对前端物联网的监测方式、通讯方式、监测对象、数据结构进行了梳理分类，将数据来源分为统一规约类、非标准化规约类和人工获取类。其次，对于雨量计、次声仪、土壤含水率仪、泥位计、位移计等14种监测设备参照水文监测数据通信规约（SL 651－2014）等技术要求建立统一规约进行数据传输，规约涉及的内容包含链路传输规约、报文帧结构框架、报文正文结构、数据传输的考核等内容。例如：报文101E表示协议版本为1，报文正文长度为30个字节。对于微震仪、GPS监测站、视频流媒体等采用单独的通讯规约和解算程序进行传输。最后采用数据接收软件模块对所有监测设备进行集成管理，将数据存储到多源异构数据库中（图5）。通过制定统一通讯规约，系统实现了对所有监测设备的自动数据抄收和解析入库，远程设置参数并进行数据打包、发送给相关设备，人工数据实时召测和设备远程通讯管理，接收设备故障报警信息、判断故障位置并通知相关责任人员。

图5 物联监测设备统一通讯规约技术方法图Fig. 5 Method diagram of unified communication protocol technology for Internet of Things monitoring equipment

3.3 多源异构数据资源集成方法

多源异构数据资源集成方法涉及多源数据分类方法、数据标准化规则、多源异构空间数据库建设方法、多源数据ETL规则、信息资源管理方法等（付博等，2020）。

（1）多源数据分类方法。以往地质灾害监测系统数据通常采用单纯按监测对象分类的方法，对数据的应用范围会产生一定限制。本系统采用的方法是根据数据的来源和用途，按照数据类型（结构化、半结构化、空间数据）、所属地质要素（地表形变、地层形变、物理场等）和监测对象（崩塌、滑坡、泥石流、采空塌陷等）的3种分类方法，将全部数据切分成若干相对独立且紧密相关的数据集合，为后续存储管理做好准备。

（2）数据标准化规则。按照行业标准规范对数据集合进行标准化处理，同时建立数据ETL规则，实现数据自动化的抽取、转换、上载。对于雨量、位移、应力监测等结构化数据，进行数据质量校验；对于地质灾害易发性分区图、风险性分区图、隐患点分布图等空间数据，按照标准化方式进行图层拆解；对于调查报告、图像资料等非结构化数据进行元数据编录。

（3）多源异构空间数据库建设方法。根据上述的分类方法和标准化规则对数据进行切分、标准化处理后，运用系统自建的ETL法则，分别导入关系型（Oracle）、非关系型（Trip）数据库中，两种数据库之间依赖于元数据编录信息实现统一的调度。

（4）信息资源管理方法。对于结构化数据而言，采用基于“监测对象”的库表结构、基于空间的元数据信息和结构化数据索引实现自身数据集成，并借助于结构化数据库表中的空间信息实现与空间数据的集成；对于空间数据而言，通过其空间数据引擎、图层索引和基于空间的元数据信息实现自身数据的集成，同时借助于空间和索引信息实现与结构化数据的集成；对于非结构化数据而言，通过著录信息实现与结构化和空间数据的集成。

3.4 突发地质灾害预警模型库

突发地质灾害预警模型是实现及时、准确预警功能的核心之处，也是难点所在。北京市突发地质灾害类型多样，不同灾种的预警模型各不相同，在时间精度和空间精度上也存在差异。

本系统预警分析功能依托的并非单一模型，而是采用建立预警模型库的方式集成多种模型，在系统工作时可实现多种模型同时计算分析，提交预警结果供专业人员审核判断。在逻辑上将预警模型按空间尺度划分为区域、沟域和隐患点，探索空间精度“由区到沟到点”的分级别预警；时间精度上结合单沟域模型研究探索泥石流2 h短期灾前预报、5 min灾前警报。

运用可拓理论、灰色系数、模糊数学、人工神经网络、层次分析法、水动力学、流体力学等方法，依托GIS平台开发空间分析工具，形成包括隐患点专业监测预警模型、单沟泥石流预警模型、地质灾害气象风险预警模型、单灾种区域预警模型、易发程度划分评价模型、地质灾害危险性评价模型等在内的多种模型。

采用面向对象的模型表示方法，模型表示与算法相互独立，用户在修改模型时无需考虑求解方法，仅需直接赋予相关参数即可；采用开放式定义与管理，可以对模型进行建立、编辑、存储和维护操作，以实现模型建设研究和验证调试的功能。

4 系统实现与案例模拟

系统已实现了实时自动接收汇聚各类监测设备数据并解析入库，判断设备故障情况并自动报警。对地质灾害隐患点信息、监测数据、预警分析结果、设备运行情况等进行二维及三维的查询、统计和展示（图6），可实现区域预警分析、自动隐患点预警分析和自动单沟预警分析，并将相关结果以系统信息和短信的形式发送给相关业务人员和值班人员，按流程审核通过后可进行预警发布。

图6 系统主界面-部分监测点分布示意图Fig. 6 Main System Interface - Distribution of some monitoring points

以北京山区某小流域泥石流沟为例进行单沟山洪泥石流预警模拟，该沟域内有大量煤矸石堆，多沿沟、顺坡堆弃在谷坡，稳定性极差，地形整体呈东南高、西北低的地形分布，坡降约为0.2，一旦坡脚被冲蚀或受到强大的水体冲刷，则会引发泥石流灾害。

系统C/S端预警计算软件在获取雨量计、土壤含水率仪监测设备的连续模拟数据后启动预警模型计算，通过实时雨量数据输入，实时计算该沟域指定位置的预警结果并提交业务审核。

模拟计算结果，图7a显示在模拟计算时刻开始后的未来25 min内，指定位置的水深和流量变化值和对应的预警程度，在模拟时间2点05分该位置将达到黄色预警级别,在2点20分将达到红色预警级别。图7b表示在2点05分时刻该沟域的水深分布和相应位置预警情况，其中深蓝色表示水深程度较深，浅绿色表示水深程度较浅。计算结果表明，该泥石流沟积水最大水深分布向泥石流沟汇流的趋势非常明显，由于沟口狭窄，短时强降雨会引起沟口上游出现剧烈壅水，发生泥石流灾害的风险性较高，在相应位置上显示黄色预警旗帜符号。图7c显示的是随着时间推移，在该沟域相应位置上的流速变化曲线。

图7 C/S端计算生成的某单沟泥石流预警结果图Fig. 7 A single gully debris flow warning result graph generated by C/S terminal calculation

以上预警结果可同步到系统B/S端上显示，经过审核后可发布。单沟预警信息将与其他地区和不同模型计算生成的预警信息、监测、统计数据实时显示在信息大屏系统上，重要预警及时推送消息，提醒用户查询和决策使用。

5 结论

突发地质灾害监测预警工作关乎人民生命财产安全，对时效性和准确性要求高，并且由于涉及多门学科的融合，是一项复杂的系统工程，信息系统的建设效果直接影响着预警工作的成效。北京市突发地质灾害监测预警系统在系统结构、功能搭建、预警模型、数据库建设、标准建立等方面逐步形成完整体系，基本覆盖了突发地质灾害调查、监测、分析、预警、应急管理工作的全流程，随着系统运行管理工作的不断完善与深入，可为首都的突发地质灾害监测预警工作提供可靠技术支撑。