地震预警系统的架构设计

周跃勇 李水龙 周施文 于伟恒

摘  要：地震预警系统作为复杂的大型应用系统，需要支持多源异构观测数据的多种处理操作，客观上要求系统具备因需而变的扩展性。在顶层规划中引入基于软件架构层面的设计，通过对处理流程的宏观归纳抽象，在较高级别上勾勒出系统的运行主线，给出系统运行状况的全景图，从而构建一套易定制、易扩展，具有较强适应能力的分布式地震预警应用系统。

关键词：地震预警;软件架构;扩展演化

中图分类号：TP311;P315        文献标识码：A文章编号：2096-4706（2021）14-0042-04

Abstract： As a complex large-scale application system， the earthquake early warning system needs to support multiple processing operations of multi-source heterogeneous observation data， which objectively requires the system to be scalable according to needs. In the top-level planning， the design based on the software architecture level is introduced. Through the macro induction and abstraction of the processing flow， the main line of the system operation is outlined at a higher level， and the panoramic picture of the system operation is given， so as to build a set of distributed earthquake early warning application system which is easy to customize， easy to expand and has strong adaptability.

Keywords： earthquake early warning; software architecture; extended evolution

0  引  言

地震预警系统作为复杂的大型应用系统，通过对海量实时波形数据进行仿真变换、捡拾震相、量测幅值、烈度预测等多种处理操作，为重大工程提供紧急处置时间，有效减少大震中的人员伤亡，是防震减灾事业实现跨越发展的客观要求。

由于地震灾害发生机理的复杂性，要求地震预警系统能够融合多源异构的观测数据，以及支持对观测数据的多种处理操作;同时随着地震科学研究的不断进步，新的观测数据格式以及新的处理算法会不断地涌现。这些需求客观上要求地震预警系统具备较好的扩展性，从而能以较小的代价支持系统的演化完善，随需应变。

1  软件架构简介

IEEE/ISO/IEC 24765-2017系统和软件工程词汇中将架构定义为：架构是以组件、组件之间的关系、组件与环境之间的关系为内容的某一系统的基本组织结构，以及指导上述内容设计与演化的原理。Rational统一过程（Rational Unified Process， RUP）中的软件架构则定义为：软件架构包含了关于以下问题的重要决策，软件系统的组织，选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为;如何组合这些元素，使它们逐渐合成更大的子系统，用于指导这个系统组织的架构风格;这些元素以及它们的接口、协作和组合。

软件架构并不仅仅注重软件本身的结构和行为，还注重其他特性：功能、性能、弹性、重用、可理解性、经济和技术的限制及权衡，以及美学等。

总体来说，软件架构是对软件系统的宏观抽象概括。软件架构的设计主要受到功能需求、质量属性、约束条件等三方面的影响。

软件架构关注的是系统的处理流程，通过对处理流程的宏观归纳抽象，在较高级别上勾勒出系统的运行主线，给出系统运行状况的全景图。

2  方案设计

地震预警系统的软件架构可为系统建设提供基础，是系统的核心支撑。在架构的设计中，除了描述出地震预警处理过程之外，重点则要考虑采取何种技术手段使地震预警系统具有类似“热插拔”的组合能力，支持良好的定制化进而达到随需应变的要求。

地震预警系统包含了数据实时处理、地震定位、震级确定、地震动影响场估计等应用。这些应用从功能目標产出等方面虽然存在较大差异，但是都属于数字地震台网综合处理的一部分，在业务处理上还是存在着不少共性的。通过对这些处理过程的归纳抽象，可以发现这些应用基本都包含了数据接收、数据派发、通道处理、综合处理、外围应用等部分。因此通过对这些环节的分析研究，可以得到地震预警系统的软件架构。系统架构设计示意图如图1所示。

2.1  数据接收

部分主要负责从实时流服务器和归档波形服务器接收获取台站的实时波形或是归档波形。这部分需要支持同时从多个流服务器中接收波形数据，在设计中可以采用适配器（Adapter）模式来屏蔽不同波形服务器之间的差异性，如网络流、归档文件、数据库等，通过给每种波形服务器编写对应的数据获取适配器，可以为后续的地震应用处理提供统一格式的波形数据，从而简化地震业务处理的复杂程度。具体来说，数据接收部分设计需要考虑以下要求：

（1）支持多种来源、多种格式的数据。

（2）易于扩充，支持新的数据来源和数据格式。

（3）为后续的数据处理提供统一格式的波形数据。

实时地震数据接收的设计支持HTTP协议，能够实时接收Jopens6.0及以上版本流服务分发的MiniSeed格式的地震数据，波形数据的接收采用多连接管理设计，如图2所示。

部分设计代码为：

miniSeedReceive = new MiniSeedReceive（）; miniSeedReceive.initialize（[configurationManager]）;

miniSeedReceive.register（[miniSeedDispatcher]）;

……

miniSeedReceive.startReceive（）;

……

miniSeedReceive.stopReceive（）;

2.2  数据派发

部分从数据接收部分得到统一格式的波形数據，传递给后续的通道处理部分，作为数据与处理之间的通道。数据派发部分从波形数据中解析出台网、台站、通道等信息，根据这些参数信息把数据发送给相应的波形数据处理对象。具体来说，数据派发部分设计需要考虑以下要求：

（1）根据需要创建波形数据的处理对象。

（2）按照波形数据通道信息，匹配波形数据的处理对象。

数据派发为系统后续的计算处理提供数据及台网台站参数信息，考虑到地震预警的时效性要求，数据派发的设计应充分考虑系统的处理性能，具体设计如图3所示。

2.3  通道处理

部分负责对数据派发部分传递过来的连续波形数据进行仿真变换等预处理，并为后续的综合处理提供预处理后的提炼信息。在这个部分数据从时间上连续不断的波形数据转变为处理后的离散波形特征信息，如P波到时、S波到时等。因此这个部分是系统计算负荷比较大的地方，往往会成为系统的性能瓶颈所在，在设计中要注意采用合适的技术手段来保障系统处理的性能效率。

在实际的应用中，数字地震台网存在着多种地震计类型，如速度型地震计、加速度型地震计以及位移型地震计等。不同区域的台网情况并不完全一样，为了使地震预警系统具有较好的适应性，需要能在配置信息中指定台网中各个台站通道的数据处理策略，从而达到较高的灵活性和较强的可用性。

为了能在运行时激活创建通道对应的波形数据处理对象，需要这些波形数据处理对象遵循统一规范的规约，对波形数据处理算法进行调用接口、输入数据、输出数据等方面的归一化。在实际设计中，可以采用命令（Command）模式+数据容器的方式来解决此类问题，从而以较小的代价轻松地增加对波形数据的预处理，避免大而复杂的代码块，通过技术处理，达到形式上的统一，从软件的角度以一致的方式处理波形数据的前期处理，从功能的依赖转化为消息的依赖，从直接的依赖转化为间接的依赖。具体来说，通道处理部分设计需要考虑以下要求：

（1）实现对波形数据的仿真、处理的逻辑简化。

（2）实现对波形数据处理的标准规范。

（3）实现对波形数据不同处理的关联解耦。

通道处理的设计应支持事件源的管理和通知功能，能够接收MiniSeed格式的波形数据，支持对波形数据的并发处理。通道处理是整个地震预警系统计算量最大的环节，随着地震台站的不断增加，通道处理的计算压力也越来越大，我们以不同的通道处理器来处理不同类型的地震波形数据，设计了统一的通道处理器接口IChannelProcesser。

部分设计代码为：

public interface IChannelProcesser {

public String getVirtualType（）;

public synchronized String execute（

MiniSeedminiseed）;

public void setEarthquakeCenter（

EarthquakeCentereqInfo）;

public void doSomething（

IDataContainer container）;

public void register（IDoSomething observer）;

public void unregister（IDoSomething

observer）;

……

}

同时还设计了通道包装器，对通道处理器对象进行集合管理且与外围环境进行交互，根据配置文档和到来波形数据自动创建对应的通道处理器对象（对每个通道集只创建一次），并把波形数据分发给通道处理器对象，作为门面对象，负责与波形派发器及综合处理器打交道。

通道包装器的设计代码为：

public class ChannelsWrapper {

public synchronized String execute（

MiniSeedminiseed）;

public void setEarthquakeCenter（

EarthquakeCentereqInfo）;

public void doSomething（

IDataContainer container）;

public void setGeneralProcesser（

GeneralProcessergeneralProcesser）;

}

2.4  综合处理

部分接收从通道处理部分传递过来的预处理后的离散波形特征信息，根据业务功能和规则的要求，对这些信息进行集成综合判定，从而给出对地震事件的处理结果。

在综合处理部分，地震预警要完成地震事件判定、地震定位、震级估算、预警目标的烈度预测、可靠性判定等多种不同的处理工作。因此必须通过抽象封装来提取不同业务应用综合处理部分的共性信息，借助于命令模式+数据容器+工作流等技术手段来实现综合处理的归一化，从而允许根据业务功能的需要通过配置信息在运行时实现动态综合处理。具体来说，综合处理部分设计需要考虑以下要求：

（1）实现综合处理步骤的标准规范。

（2）实现综合处理步骤的关联解耦。

（3）实现综合处理步骤的动态组合。

综合处理的设计可根据配置信息构建实际的综合处理器，管理与通道包装器的外部关联，管理对综合处理事件感兴趣的观察者，接收通道处理器触发的事件，并调用实际综合处理器对应的处理方法，总体设计如图4所示。

综合处理的主要功能类为GeneralProcesser，部分設计代码为：

public RealGeneralor_OneSecond（StationLocation[]

vstationLocations， double[] vxylimit，

CityInformation[] cityInfors，StringeewResultPath，

String[] vgeneralCommands）{

……

this.generalCommands=generalLayers（vgeneralCommands）;

}

private IGeneralCommand[] generalLayers（

String[] generalCommands）{

if（generalCommands==null || generalCommands.length==0）

return null;

IGeneralCommand[] results=

new IGeneralCommand[generalCommands.length];

for（inti=0;i<generalCommands.length;i++）{

results[i]=（IGeneralCommand）ClassFactory.getInstance（

generalCommands[i]）;

}

return results;

}

2.5  控制网关

部分实现数据在后台处理计算与前台应用展现之间的网络传递。它从综合处理部分接收地震事件的处理结果，经由网络通过TCP/IP协议发送给前端的信息发布、实时监控等应用。借助于控制网关，可以简化地震预警应用在信息网络传送方面的工作，使得这些应用的数据发送都建立在一个共同的基础上，一方面减少了这些应用的代码编写工作量，另一方面通过功能复用也使得代码的质量更有保障。

控制网关主要包括服务端、客户端两个模块。前者负责对需要传送的数据进行打包封装处理，将地震应用所产出的数据对象转换为网络上传输的二进制字节流，并发送给对应的客户端;而后者则是完成相反的动作，将服务端通过网络发送过来的二进制字节流转换为地震应用所能理解的数据对象，供后续的发布展现等操作，实现地震预警由服务端向客户端的信息发布。具体来说，控制网关的设计需要考虑以下要求：

（1）实现地震预警处理结果的网络传递。

（2）为其他应用获取处理结果提供规范标准的接口。

（3）为地震预警的分布式处理提供支持。

控制网关的设计以ISocketEvent为接口，服务端与客户端分别以ConnectionServer和ConnectionClient实现，总体设计如图5所示。

2.6  外围应用

包括实时监控、人机交互、地震事件结果二次加工等工作。借助于控制网关实现了外围应用与后台计算处理的物理剥离，使得地震预警系统具有较好的演化能力和扩展性。在前文所述的各项措施的支持下，外围应用具有以下特性：

（1）实现业务处理与界面逻辑的分离。

（2）为处理结果的后续应用提供统一的调度机制。

（3）支持任务实现的语言多样性。

地震预警的外围应用与核心处理系统剥离，例如，预警客户端界面可通过控制网关实现与核心系统的连接，客户端界面如图6所示。

3  结  论

借助于软件架构的支持，地震预警系统可以针对不同的应用，通过配置信息来控制组合对应的通道处理器序列及综合处理器序列来实现所需的功能，借此构建一套容易定制、易扩展，具有较强适应能力的分布式地震预警应用系统。

参考文献：

[1] 马强.地震预警技术研究及应用 [D].中国地震局工程力学研究所，2008.

[2] 马强.强震观测数据实时处理方法的研究 [D].中国地震局工程力学研究所，2002.

[3] 张红才.地震预警系统关键技术研究 [D].中国地震局工程力学研究所，2013.

[4] 周施文，李水龙，于伟恒，等.“智能+”地震监测预警技术平台设计 [J].华南地震，2021，41（2）：76-82.

[5] 张盼盼.高性能地震预警信息分发系统研究与开发 [J].现代信息科技，2020，4（19）：116-120+125.

作者简介：周跃勇（1975—），男，汉族，福建连城人，工程师，硕士研究生，研究方向：地震预警与烈度速报软件架构设计与研发。