AETA 数据采集系统的设计与实现

杨兴文 雍珊珊 王新安 周康生 金秀如

AETA 数据采集系统的设计与实现

杨兴文 雍珊珊†王新安 周康生 金秀如

北京大学深圳研究生院地震监测预测技术研究中心, 深圳 518055; †通信作者, E-mail: yongshanshan@pku.edu.cn

设计并实现一种适用于多分量监测系统 AETA 的数据采集系统。该采集系统包括探头数据采集软件、数据处理终端软件和服务器端的应用程序, 其中数据处理终端软件为系统的核心, 负责接收探头采集的数据, 并将其稳定、可靠地传输至服务器端。该采集系统具有自动升级和在线执行命令的功能, 可以实现设备的远程运维和维护。测试结果表明, AETA 数据采集系统能够在网速低至 10KB 的情况下稳定地运行, 并能在一分钟内及时地响应远程命令, 具有很好的稳定性和实时交互性, 适用于地震监测系统设备的跨区域和高密度布设。

地震监测; 数据采集; 数据处理终端; 高稳定性; 实时交互

地震监测预测指利用传感设备来探测与地震相关的前兆信号的变化, 通过分析前兆信号, 找出其与地震事件的关系, 从而预测地震的发生[1–5]。为了采集地震前兆信号, 学者们提出一些地震数据采集系统的设计。Gao 等[6]采用 LoRa 远程无线通信技术, 设计一种分布式三分量地震数据采集系统。朱倩钰[7]采用动态电源管理和动态频率调节等技术, 对自主研发的 GEIWSR 地震数据采集系统进行软件层面的优化, 降低了系统的功耗。王京京等[8]设计一种高精度地震数据采集单元, 具有功耗低、成本低等特点。以上研究集中在硬件的低功耗优化以及数据的采集、传输方式等方面。为了形成较密集的前兆台网, 使得多台站的前兆信号异常可以相互验证, 地震监测设备往往都是跨区域、高密度地布设。大量的地震数据在网络环境不稳定的情况下难以可靠、稳定地传输, 并且需要随时查看和维护设备, 耗时耗力。

为了解决这些问题, 北京大学深圳研究生院地震监测预测技术研究中心采用实验室自制的传感探头以及终端设备, 设计了多分量监测系统 AETA (Acoustic and Electromagnetic Testing All in one system)。本文在前人研究的基础上, 研发一款支持无网络环境且具有远程实时交互功能的地震监测数据采集系统, 在发送模块采用线程池的优化方案, 并采用新型 SD 卡持久化存储的目录结构, 使得系统不仅能够在网速低至 10KB 的情况下保持稳定的网络连接和数据传输, 并能在无网络环境下及时保存数据。此外, 本文还设计了自动升级和远程执行命令的功能, 通过在通信协议中加入相关命令的参数字段和探头, 并在终端加入命令查询的函数, 使得系统能够在一分钟内响应远程下达的命令。测试结果表明, 该系统在不同的应用场景下都具有良好的实时交互性。

1 多分量地震监测系统 AETA

多分量地震监测预测系统 AETA 由地声传感探头、电磁传感探头、数据处理终端以及监测数据云平台和数据分析系统组成, 如图1所示。

传感探头感知来自地下的电磁扰动和地声信号, 数据处理终端实时采集数据, 并通过互联网(有线或无线)将数据传输到云平台进行特征提取、持久化存储和异常分析等。截至目前, AETA 系统的布设范围已覆盖河北省、四川省、云南省、西藏自治区、广东省和台湾省等地区, 其中在四川省的布设密度最大, 数量达 100 余套, 基本上覆盖四川省全境重点区域[9–14]。由于AETA 系统跨区域布设, 数量大, 所以需满足不同地区的数据采集和传输需求, 尽可能避免设备卡死和丢失数据等情况, 能够及时远程地发现并解决设备故障。

2 AETA 数据采集系统设计

2.1 总体框架

AETA 数据采集系统的总体框架主要包括探头数据采集软件、数据处理终端软件和服务器端的应用程序 3 个部分, 如图 2 所示。探头数据采集软件主要负责采集高采样率的地震监测数据, 并且具有自动升级和执行终端下发的命令等功能; 数据处理终端软件是 AETA 系统的关键中间节点, 不仅负责准确、稳定地传输地震监测数据, 还具有自动升级、实时监控和远程与服务器交互等功能; 服务器端的应用程序主要负责数据接收和存储功能。

2.2 关键技术

2.2.1 通信协议

目前, 大多数地震监测系统的通信协议都基于地震数据制定, 而 AETA 软件不仅需要稳定、可靠地传输地震数据, 还需要满足实时命令的交互, 所以在 AETA 的数据通信协议中需要同时满足数据和命令的传输。

数据处理终端位于 AETA 系统软件的中间环节, 既要与探头进行数据交互, 又要与服务器应用服务程序通信。数据处理终端与传感探头之间通过TCP/IP 协议通信, 与服务器之间通过 HTTP 协议通信。数据处理终端和服务器需要识别数据来源、数据类型、数据产生的时间和数据长度等信息, 据此确定数据在传输过程中没有出现差错。因此, 通信协议包括探头与终端之间、终端与服务器之间的传输协议。

传感探头与终端建立 TCP 连接后, 直接向终端发送数据。由于探头的数据发送速率较快, 因此数据发送后, 探头在应用层无须等待终端对数据的确认回复即可继续发送下一条数据。除发送从 ADC 采集的电磁和地声传感数据外, 传感探头还需要定时地向终端发送自身运行状态(如探头软件版本号和状态发送间隔等)。终端也可以向探头下发控制命令(如复位等), 因此探头还需要接收来自终端的控制信息。探头与终端之间的数据协议如图 3所示。

图 3 中, Precode 为前导码, 位于数据包的开始位置, 尽量与数据包的其他部分相异; Head 为包头, 包含设备编号等信息以及自身的校验信息; MSG 为消息, 分为数据和命令两种, 前者来源于传感探头采集到的各种数据, 后者可以让探头接受来自终端的命令; CRC16_Check 是一种数据校验方式, 当数据在探头与终端之间传输时, 可以通过多重校验来保证数据的准确性, 也可以通过消息类型来判断当前消息是数据还是命令, 以便进行不同的操作。

数据处理终端与服务器之间, 采用 HTTP 协议进行通信, 终端向服务器发送 http 请求, 以 POST 的方式传输数据和参数, 大量的数据(如日志和原始数据)以文件的形式上传。终端与服务器之间的交互流程包括身份认证、数据上传、时间同步、异常报警、参数配置、状态上报、日志上报以及命令查询等。其中, 数据上传和命令查询可以实现终端向服务器传输数据以及服务器向终端下达命令。由于http 请求是无状态的短连接, 为了保证终端能够一次登陆后多次上传数据, 我们还引入 http 的 session机制。

2.2.2 自动升级

AETA 监测系统布设范围遍及全国, 如果能在现场进行设备升级, 会大大提高设备的维护成本。AETA 数据采集系统通过探头中的引导程序和终端的升级程序, 能够实现数据采集探头和数据处理终端的远程自动升级。

探头引导程序升级的过程是基于探头与终端之间的 TFTP 通信, 上电时刻, 引导程序率先运行, 然后初始化其自身需要的相关外部设备(如时钟、串口和 W5300 网络芯片)。W5300 是一款用于网络模块传输的芯片, 其内核含有 PPPOE 协议、ARP 协议、IP 协议和 ICMP 协议等, 能够有效地解决数据的网络传输问题。然后, 对地面终端的 Linux TFTP服务器发起固件升级请求, 下载版本信息文件, 判断是否需要进行固件升级。如需要, 则进行固件升级, 如不需要, 则执行探头的数据采集程序。

终端的升级程序完成对文件(包括升级程序自身)的升级。升级程序只在终端启动时执行, 执行完成后, 升级程序自动结束。在服务器上, 每一个终端都对应一个升级文件夹, 里面存放升级信息描述文件和升级文件压缩包。升级信息描述文件中包含终端 ID 号、自身的版本号、升级文件压缩包名、脚本文件名以及服务器计算出的升级文件压缩包的 CRC 校验值; 升级文件压缩包包含要升级的文件清单、升级文件和脚本文件。终端升级程序的升级过程是, 首先从服务器下载升级信息描述文件, 判断是否需要进行升级。如果需要升级, 则下载升级文件压缩包到一个临时目录, 校验成功后解压该文件, 然后找到压缩包中的脚本文件, 给脚本文件添加可执行权限后, 执行脚本文件。后续的所有工作(如将文件放到指定的目录下或执行其他操作)均由脚本文件完成。脚本文件完成所需工作后, 重启终端。升级过程中产生的日志用 txt 格式保存, 然后通过 FTP 上传至服务器中该终端 ID 对应的升级目录下。

结合探头引导程序和终端应用程序升级的流程, 可以在服务器中同时准备好探头和终端的新版软件程序。这样, 设备重启后就可以完成探头和终端的同时升级。这种升级流程实现了现场自动升级的功能, 可以大大减少设备维护成本。

2.2.3 实时监控

在一个软件系统中, 软件或硬件的微小波动可能引起系统的运行故障, 此时, 系统能否自动恢复运行是衡量一个系统容错性的重要指标。

如图 2 所示, AETA 数据采集系统终端的监控程序是整个终端最先开始启动的进程。终端电源接通后, 内嵌于核心板中的 Linux 操作系统开始启动。系统启动后, 按照提前部署好的启动脚本, 启动监控程序, 使得该进程在系统启动后能够自动运行。

监控进程启动后, 创建一段共享内存, 进行自身的初始化, 与系统时间同步, 查询系统进程表中是否存在升级程序和数据处理程序的进程 ID。若两者的进程 ID 号不存在, 说明这两个进程没有启动或已崩溃, 监控程序会启动这两个进程。升级进程在确定软件不需要更新, 或在更新完终端软件后, 进程会自动释放, 因此不需要向共享内存中写入心跳信息(即系统时间)受监控进程的监控, 即只在开机后运行一次。若系统中存在这两个进程的 ID 号, 监控进程会周期性地从共享内存区中读取数据处理进程写入的心跳信息。如果前后两次从共享内存区读取的系统时间不变, 说明数据处理进程卡死或崩溃, 监控进程会将其终止, 然后重新拉起该进程。若相邻两次读取的系统时间有变化, 则说明数据处理进程正在运行。

数据处理进程在运行后, 会专门分配一个线程,定时地向共享内存中写入系统时间, 写入的时间间隔需小于监控进程读取共享内存的时间间隔。此外, 终端的监控程序以及探头的升级程序和数据采集程序都由硬件“看门狗”进行监控, 如果程序卡死或奔溃, 则硬件“看门狗”会对整个系统进行复位。

除监控功能外, 监控程序还负责定时地在服务器进行时间同步操作, 保证设备的时间与服务器同步。

2.2.4 数据采集和命令交互

AETA 数据采集系统的探头引导程序运行完成后, 会自动执行探头的数据采集程序。探头接受参数配置和命令都由该程序实现。图 4 展示数据采集程序的主函数执行流程, 主要包括传感数据的采集和发送、日志及状态的生成与发送以命令的接收与处理 3 个任务。其中, 数据采集和命令的接收与处理分别通过 ADC 中断和 W5300 中断来实现, 日志则在软件运行过程中根据事件生成。

整个数据采集程序主函数在数据发送和命令执行两个函数之间循环执行, 两个函数通过标志位来判断是否执行某项操作, 标志位在中断函数中进行修改。当 ADC 中断被触发, 则程序进入 ADC 中断函数处执行, 读取 ADC 数据(2 字节)存入当前缓冲区。缓冲区采用双缓冲设计, 当前缓冲区写满后切换至另一个缓冲区, 并置发送标志位。当中断函数执行完毕退出时, 程序切换至中断被触发时刻的状态, 继续执行, 数据发送函数检测到发送数据标志位后, 即开始执行发送任务。W5300 中断只需将网络接收标志位置 1 即可。除发送传感数据外, 数据发送函数时还需要发送温度和状态信息; 命令执行函数目前只需解析并执行命令, 但保留执行其他任务的可拓展性。

在数据处理终端中, 数据处理程序的流程如图5 所示。探头与终端之间采用 TCP/IP 传输层协议进行通信, 监听线程为程序的主线程, 在指定端口持续地监听是否有探头请求连接。一旦探头向监听端口发起连接请求, 监听线程会创建一系列的线程来服务于此连接, 包括接收线程、解包线程以及滤波线程。

接收线程、接收流缓冲和解包线程以及解包线程、解包流缓冲和滤波线程之间, 构成典型的生产者–消费者模型, 接收线程和解包线程通过条件变量和互斥锁进行互斥与同步, 解包线程一旦发现接收流缓冲中没有足够的数据解包, 则自身会挂起, 等待条件变量的变化。接收线程每次接收到数据向接收流缓冲存放后, 通过条件变量唤醒解包线程进行解包。同样, 解包线程在解完一个包后, 将数据存入解包流缓冲, 待解包流缓冲中存够 1 秒的数据量后, 通过条件变量唤醒滤波线程, 对数据进行滤波。这种模型的优化能够极大地降低主进程对系统 CPU 的占用率, 提高设备的可靠性。

发送线程与服务器应用服务之间基于 HTTP 协议通信, 采用线程池技术对发送模块进行优化, 可以将每一个 HTTP 请求的超时时间设为一个较长的合理值。设计要求是每分钟发送实时数据, 在上一分钟的数据还未发送完, 下一分钟的数据就已经到来的情况下, 可以从线程池中唤醒一个空闲线程来处理新的数据, 而上一分钟的数据则继续发送, 两者互不影响。在系统启动时创建一定数量的线程, 初始状态为空闲状态。当有新的任务加入任务队列时, 则从线程池中取一个空闲的线程来处理该任务。此时该线程转化为忙碌线程, 任务处理完成后, 该忙碌线程又自动挂起, 处于空闲状态。线程的唤醒采用条件变量和互斥锁来实现。采用线程池技术来设计发送模块, 既可以减小线程创建和销毁带来的开销, 又能够延长 HTTP 请求的超时时间, 使得数据能够在网络不稳定的情况下稳定地传输。

终端的远程命令交互功能是通过向服务器发送线程查询命令来实现。终端运行过程中, 每隔一定的时间会向服务器请求命令, 在接收到终端的命令查询请求后, 服务器会查询是否有运维人员给该终端下的命令, 若有, 则读取命令, 并将其作为终端请求的响应参数发送给终端, 终端通过制定的通信协议解析服务器应用程序的响应参数而得到命令信息, 并根据命令类型执行相应的操作, 整个流程保证在一分钟内执行成功。

2.2.5 弱网络环境处理

AETA 系统监测站点大多部署在地震频发的地域, 其中很多地方由于地理位置的原因, 网络条件不稳定, 经常出现网速较慢甚至断网等情况。因此, AETA 数据采集系统需要考虑在弱网络环境下数据的传输问题。

AETA 数据处理终端预留了 SD 卡接口, AETA的每一台终端均配备一张 32GB 容量的 SD 卡, 可以存储一个标准台站 3 个月以上的数据。因此, 在弱网络环境下, 数据无法在超时的时间内传输到服务器应用服务的情况下, 数据处理进程可以将数据存储在 SD 卡中, 并在网络稳定时取出 SD 卡内的数据, 发送至服务器。如图 5 所示, 发送线程在发送完一分钟实时数据后, 如果下一分钟数据还没有到来, 就可以从 SD 卡取出数据发送出去。

图 6 为 SD 卡持久化存储的目录结构设计, 按天创建数据文件夹, 文件夹内的文件名从 001 开始命名, 每小时加 1, 每天最多 24, 每个小时内的数据写入同一个文件。每一个文件都有对应的 index文件, 记录每条数据的地址、长度和读取标志, 用来描述数据文件中数据的读取位置以及是否已读等信息。

3 系统测试

首先对 AETA 软件进行自动升级测试。在服务器准备两个版本的软件(包括探头引导程度和终端应用程序), 使设备在这两个版本之间反复进行升级。测试结果表明, 在长达 100 次的升级测试中, 设备全部升级成功。

然后, 进行监控功能的测试。通过 linux 命令,手动结束数据处理进程, 监控进程检测到心跳信息停止后, 成功地重新启动该进程。用同样的方式, 手动结束监控进程, 发现硬件“看门狗”也成功地重启监控进程。为了模拟数据处理进程卡死的情况, 在主函数中添加延时函数, 延时 60 秒, 观察进程的变化。结果表明, 处于模拟卡死情况下的数据处理进程被成功地重启。

再次, 进行命令交互的测试。如表 1 所示, 在服务器远程对终端下达以下命令, 每条命令都执行10 次以上。结果表明, 所有命令都在一分钟内执行成功。标志“1”表示终端命令, 标志“2”表示探头命令。

最后, 进行弱网络环境的模拟测试。如表 2 所示, 在网速低于 10KB 的情况下, SD 卡的使用率(每天)为 0.53%, 这时数据会存入 SD 卡, 等待网络状况良好时进行发送; 在网速高于 10KB 时, 数据稳定地传输至服务器, SD 卡的使用率为零。

表1 命令交互测试结果

表2 不同网速情况下的SD卡使用率

4 结束语

本文设计并实现了应用于多分量地震监测系统AETA 的数据采集系统。该系统已经稳定地运行近一年时间, 能够稳定地采集和传输来自全国 10 个以上省份的数据, 为 AETA 系统提供了丰富的地震监测数据。此外, AETA 系统支持远程自动升级和命令交互, 可以实时获取设备的运行状态, 并进行远程运维, 极大地降低了设备维护成本。在未来的设计工作中, 随着设备布设数目的增多, 可以考虑分布式系统的架构, 平衡多台服务器之间的压力。

[1] Andrén M, Stockmann G, Skelton A, et al. Coupling between mineral reactions and chemical changes in groundwater before and after earthquakes in Iceland // AGU Fall Meeting. San Francisco, 2015: 2315–2337

[2] Brodsky E E, Thorne L. Geophysics recognizing foreshocks from the 1 April 2014 Chile earthquake. Science, 2014, 344: 700–702

[3] Green H W, Chen W P, Brudzinski M R. Seismic evidence of negligible water carried below 400-km depth in subducting lithosphere. Nature, 2010, 467: 828–831

[4] Garcia A M, Aguilar A N P. Affordable instrument design for seismic monitoring, early warning systems and control actions to risk mitigation // 13th APCA International Conference on Control and Soft Com-puting (CONTROLO). Ponta Delgada, 2018: 143–147

[5] Pierleoni P, Marzorati S, Ladina C, et al. Performance evaluation of a low-cost sensing unit for seismic applications: field testing during seismic events of 2016–2017 in central Italy. IEEE Sensors Journal, 2018, 18(16): 6644–6659

[6] Gao P, Li Z, Li F, et al. Design of distributed three component seismic data acquisition system based on LoRa wireless communication technology // 37th Chinese Control Conference (CCC). Wuhan, 2018: 10285–10288

[7] 朱倩钰. 单通道无缆地震数据采集系统低功耗研究与实现[D]. 长春: 吉林大学, 2017

[8] 王京京, 罗维炳, 李宁, 等. 一种高精度地震数据采集单元的系统设计与实现. 地球物理学进展, 2017, 32(4): 1828–1837

[9] 林科, 王新安, 张兴, 等. 一种适用于大地震临震预测的地声监测系统. 华南地震, 2013, 33(4): 54–62

[10] 王新安, 雍珊珊, 黄继攀, 等. 基于 AETA 监测数据的地震预测研究. 北京大学学报(自然科学版), 2019, 55(2): 209–214

[11] 金秀如, 雍珊珊, 王新安, 等. 地震监测系统 AETA 的数据处理设计与实现. 计算机技术与发展, 2018, 28(1): 45–50

[12] 雍珊珊, 王新安, 庞瑞涛, 等. 多分量地震监测系统 AETA 的感应式磁传感器磁棒研制. 北京大学学报(自然科学版), 2018, 54(3): 495–501

[13] 刘晨光, 王新安, 雍珊珊, 等. AETA 多分量地震监测系统的数据存储与安全系统. 计算机技术与发展, 2018(12): 1–7

[14] 王新安, 雍珊珊, 徐伯星, 等. 多分量地震监测系统 AETA 的研究与实现. 北京大学学报 (自然科学版), 2018, 54(3): 487–494

Design and Implementation of Data Acquisition System for AETA

YANG Xingwen, YONG Shanshan†, WANG Xin’an, ZHOU Kangsheng, JINXiuru

Earthquake Monitoring and Prediction Technology Research Center, Peking University Shenzhen Graduate School, Shenzhen 518055; † Corresponding author, E-mail: yongshanshan@pku.edu.cn

This paper designs and implements a data acquisition system for AETA (Acoustic and Electromagnetic Testing All in one system). The data acquisition system is mainly divided into three parts: probe data acquisition software, data processing terminal software and server application. The data processing terminal software is the core, which is responsible for receiving the data collected from the probe and transmitting it stably and reliably to the server. The proposed system also has the function of automatic upgrade and online execution of commands, which can realize remote operation and maintenance of the device. Tests show that the AETA data acquisition system can run stably with network speed as low as 10 KB, and can respond to remote commands in a minute. It has good stability and real-time interactivity, and is suitable for cross-region and high-density layout of seismic monitoring system equipment.

seismic monitoring; data acquisition; data processing terminal; high stability; real-time interactivity

10.13209/j.0479-8023.2020.052

深圳市科技计划项目(JCYJ20180503182125190, KJYY20170721151955849)资助

2019–07–26;

2019–10–28