基于MySQL 的空管设备集中监控系统数据库设计

闫继正，张 雷，张海涛

（1.中国电子科技集团公司第四十七研究所，沈阳 110000；2.中国人民解放军 95979 部队，新泰 271207）

1 引 言

智慧机场是目前机场建设和发展的趋势。我国机场一般都存在多种相似、相关且互相独立的系统，彼此数据无法共享，为了打破这种信息孤岛的现状，空管设备集中监控系统应运而生。它是利用系统集成技术、异构数据采集技术、数据库技术等进行开发的，将民航机场机房中各个独立的子系统数据采集出来并进行集中处理，从而实现数据存储、数据回查、数据分析等功能，并为后续的数据融合和数据挖掘提供支持。数据库作为系统中存储与查询数据的中枢，其设计合理与否直接影响系统运行的效果。根据项目需求进行数据库分析和设计，能够最大限度利用数据库的资源，实现最优最快处理数据的目的［1］。

2 数据库设计需求与选择

2.1 数据库设计需求

空管设备监控系统整体流程如图1 所示。根据被采集设备的不同，采集单元对被采集设备是一对一或一对多的情况。采集单元对设备发送采集命令，将采集到的数据传输到Web 服务器；Web 服务器将数据存储到数据库中，使查询历史数据成为可能。Web 应用程序通过向Web 服务器请求数据，进行数据展示。结合应用情景，对数据库的设计应包含如下几方面的基本考量：

图1 空管设备集中监控系统整体流程图

1）数据库存储条目数量

空管设备监控系统需要采集空管设备和为保障其工作而配备的各种动力环境保障设备的实时数据。以某民航机场机房为例，一个机房可能存在一到两台空管设备以及为保障其工作环境所需要的空调、温湿度计、UPS、电量计等动力环境保障设备，每台空管设备需要实时监控的数据参数从几十项到几百项不等。根据用户需求的不同，可以对这些参数进行裁剪，只监控部分重要参数。全部动力环境保障设备参数共约一百项，一个民航机场存在多个这样的机房，一个机场所有设备需要采集的数据在一千项到两千项左右，历史数据需要保存一年。由于每次仅需存储发生变化的参数，而所有被采集设备有一半的参数为状态量，基本不变，另外大部分参数也很少变化，因而数据存储数量不是特别巨大。

2）数据库存储频率

空管设备监控系统采集的空管设备参数的更新频率均为秒级，动力环境保障设备对于秒级以下的数据更新没有意义，因而对于数据库存储的数据不会太频繁，实际使用过程中，每10 s、20 s 或更久存储一次数据库即可。

2）数据库工作时间

空管设备监控系统需要长期工作，在工作过程中，数据库需要高可靠性，不能因为数据库的宕机而造成巨大损失。

4）数据库连接实例

空管设备监控系统提供一个连接实例供中心机房使用，提供几个连接实例供程序调用，所用连接实例数较少。

5）数据库占用资源

空管设备监控系统是以计算机为处理核心的系统，兼容Windows、Linux 操作系统，在使用数据库时，数据库需要尽可能少地占用资源。

2.2 数据库选择

综合来看，空管设备监控系统所需数据库体量中等，同一时间存取数据量中等，存取时间间隔足够，需要稳定运行。在满足这些需求的同时，为进一步应对商业化需求，数据库选择要能够尽可能缩短开发周期，减少开发成本，简单易用，最好为开源。

结合以上数据库需求，系统选取以高效、简洁、可靠性高著称的免费开源MySQL 数据库进行开发设计，MySQL 数据库支持标准化SQL 查询语言，能够实现高速存储数据，同时支持线程池，能够在充分利用硬件资源的情况下，应对大量的并发请求［2-4］。

3 数据库设计

结合项目需求分析与空管设备监控系统布置进行系统总体功能设计，系统功能模块示意图如图2所示。

图2 空管设备集中监控系统功能模块示意图

3.1 E-R 图

根据系统功能需要，对所有必要信息进行分类整理，建立机场、台站、设备、参数、数据、人员的ER 图，如图2 所示。

图3 系统各实体E-R 图

根据各E-R 图与两两实体之间的关系，整理可得系统总的E-R 图如图4 所示。

图4 系统整体E-R 图

3.2 数据库表设计

根据E-R 图的理论设计，结合机场实际情况与使用便利性进行分析，建立系统数据库。系统包括的数据库表及详细用途如下：

（1） 机场地区信息表

用于存储机场所在的地区信息，实现区分各地区机场的目的。包括地区编码和地区名称。设计结构要求如表1 所示。

表1 机场地区信息表格式

（2） 机场台站信息表

用于存储同一机场不同台站的基本信息，实现区分同一机场各台站的目的。包括地区编码、台站编码和台站名称。设计结构要求如表2 所示。

表2 机场台站信息表格式

（2） 台站设备信息表

用于存储同一台站不同设备的基本信息，实现区分同一台站各设备及配置通信的目的。包括台站编码、设备编码、设备本地编码、设备名称、通信方式、配置信息、端口状态。设计结构要求如表2 所示。

表3 台站设备信息表格式

（4） 设备本地表

用于实现设备编号与被采集设备实际信息实现一一对应的目的。包括设备本地编码、设备本地名称、设备所属分类、设备所属子分类、设备供应商、设备型号。设计结构要求如表4 所示。

表4 设备本地表格式

（5） 设备参数表

用于读取和识别每台设备所需要采集和记录数据的参数信息。包括设备本地编码、参数编码、参数类型、参数中文名、参数英文名、参数单位、参数精度、参数Warning 和Alarm 的上下限、参数组别、参数含义、备注。设计结构要求如表5 所示。

表5 设备参数表格式

（6） 历史数据表

用于存储每台设备所需要采集的数据历史值，方便进行备份和历史回查。包括数据序号、采集时间、设备编码、参数编码、数值。设计结构要求如表6所示。

表6 历史数据表格式

（7） 实时数据表

用于存储每台设备所需要采集的数据的实时值，随着采集数据的变化而不断更新，实现随时查看被采集设备最新状态的目的。包括数据序号、采集时间、设备编码、参数编码、数值。设计结构要求如表7 所示。

表7 实时数据表格式

（8） 告警信息表

用于存储每台设备所需采集的数据发生的告警记录，便于分析和查看。包括数据序号、采集时间、设备编码、参数编码、数值、告警级别。设计结构要求如表8 所示。

表8 告警信息表格式

（9） 人员表

用于存储机场运维人员的信息。包括机场编码、人员编码、姓名、性别。设计结构要求如表9 所示。

表9 人员表格式

（10） 事件表

用于存储设备触发的事件（开关机、切换机、告警、维护等）、人员处置的事件（消除告警、维修、遥控、生成报表、巡检等）、系统事件（断线、损坏、故障等）。包括序号、设备编码、发生时间、事件内容。设计结构要求如表10 所示。

表10 事件表格式

由于使用MySQL 自带调试窗口进行数据库建立过于繁琐，在建立和使用数据库的过程中使用Navicat 软件进行数据库的建立和管理。依据数据库的各表的设计和实际存储内容，在建立数据库时，各表按表1～10 的结构进行建立。其中，历史数据表按照表6 的结构创建后，由采集程序自动为每个台站建立一张表，根据采集时间，每月分出一张表［5-6］。

4 效果验证

为验证该空管设备集中监控系统数据库的实用性，在数据库设计完成后，进行了模拟拷机实验。实验环境参照一般支线机场的机房进行配置，分为11个台站，包含5 台不同种类型号的空管设备（1 台GP、1 台LOC、1 台VOR、2 台DME），11 套与各个台站配套的动力环境监控设备（每套包括2 台空调、1 台UPS、1 台电力表、1 个温湿度计、2 个水浸传感器、1个烟雾传感器、1 个门磁传感器、1 个红外传感器）。

实验中所有设备的数据均由自行开发的数据模拟软件生成，模拟数据参照设备实际运行参数范围，进行小范围随机变化，输出数据至空管设备集中监控系统，空管设备的监控参数条目按照最大条目进行模拟，所有设备数据总量在一千条以上。系统实际工作时数据存储间隔为10s 或更长。

为更好地检验数据库工作能力，模拟拷机实验时将存储间隔设置为1 s，运行一天后，各台站历史表的数据量最多约为100 万条（包括空管设备下滑、航向的台站）和20 万条（仅有动环设备的台站）左右。模拟拷机实验共进行26 天，中间自然时间跨月，历史表进行了分表。实验结束后，每个台站有两张表，数据总量约为2500 万条（包括空管设备的台站）和1000 万条（仅有动环设备的台站）左右，数据量约为所有设备满参数实际工作一年的总量［7-8］。

由于在数十倍于实际工作环境的条件下进行实验，造成单张表数据量达千万以上，在系统软件进行历史数据回查时会有延迟；当实验进行至2～4 天时，数据库中单表的数据量已经远超过了实际工作时单表的最大数据量，此时系统软件进行数据回查操作时，数据库响应良好。经过模拟拷机实验，数据库仍然工作良好，证明此数据库设计方案可行。

5 结 束 语

空管设备集中监控系统在进行数据库需求分析后，选择了高效、简洁、体量较小的MySQL 数据库。在进行E-R 分析后，结合实际情况设计并建立了切实可行的数据库。设计完成后进行了模拟拷机实验，验证了数据库的性能。该数据库系统在设计并研制完成后，已经用于多家机场的集中监控领域，取得了良好的效果。