RT21－ISCS综合监控系统中实时历史数据库的设计与实现

刘佳宝 梁 奕 陈天浩

（国电南瑞科技股份有限公司，210061，南京∥第一作者，工程师）

RT21－ISCS综合监控系统是针对轨道交通和工业控制领域特点，集先进的计算机技术、网络通信技术和自动控制技术于一体的大容量、多专业、高性能的计算机软件系统。它是第一套应用广泛的国产轨道交通综合监控软件，目前已成功中标北京地铁9号线、北京房山线、重庆轨道交通3号线、广州珠江新城APM（旅客自动输送系统）等的综合监控系统和南京地铁2号线综合信息系统。

对于综合监控系统而言，历史数据的存储以及方便、快速的检索具有重要意义。然而，轨道交通的现场设备多种多样，每天将产生大量数据（如南京地铁2号线RT21－ISCS系统每天产生500万～1 000万条采样数据），普通的关系型数据库如ORACLE根本无法满足存储和检索的效率要求。国外一些成熟的实时历史数据库如PI，INSQL价格昂贵，可以处理的点数少。而轨道交通综合监控系统具有海量信息，如北京房山线全线预期约有50万点，因此，必须针对轨道交通综合监控的特点，设计开发自己的实时历史数据库来处理海量的采样信息。

1 跨平台和C/S结构的设计

RT21－ISCS综合监控系统整体上都要求是跨平台的，支持所有主流的操作系统。因此，其实时历史数据库软件FVDB（Full View Data Base）的设计必须满足跨平台要求。这就要求在具体的开发中采用跨平台的开发语言以及跨平台的第三方库，保证的平台无关性。

为满足RT21－ISCS综合监控系统的分布式架构及实际工程的需要，FVDB必须是C/S（客户端/服务器）的结构设计。C/S结构提供了充分的开放性和灵活性。如图1，由于采用了双机热备份的方式（控制中心需要保存全线各个车站的数据），每个车站的数据提交程序fvdb＿commit＿server至少要同步四台FVDB服务器（本车站的主、备FVDB服务器和控制中心的主、备FVDB服务器）。

2 FVDB核心模块的设计

FVDB的核心模块主要包括点管理、实时数据管理、历史数据管理等三个模块。

图1 RT21－ISCS综合监控系统中采样数据的存储同步过程

2.1 点管理模块

“点”（记为point）是对不同数据流唯一性的表示，如电压电流值、开关状态、温度计示数等。任何可测量的设备属性都可以被定义成“point”。点类型主要包括数字量和模拟量。在轨道交通综合监控系统中，数字量变化频率较低，模拟量变化频率较高，因此，其历史数据大部分为模拟量。

在FVDB中，点用一个18位的字符串来唯一标识，称之为点标签。单点信息一般包括点标签、类型、单位、描述、死区值、是否保存历史数据、B＋树根结点等。其中，点标签是唯一标识一组点信息的关键字。所有点信息的集合构成了一张点表，全部放到内存中。点管理主要指对点表的维护，包括点的增加或删除、点信息的修改、点的快速查找等。

点是数据管理的基本单位，对数据的各种操作都是以点为单位进行的。因而，快速的点查询对提高系统性能具有重要意义。FVDB采用HASH表的索引方式进行点查询，可快速查找到指定点信息。

2.2 实时数据的管理

实时数据是点在最近某一时刻的瞬时值，是与时间有关的数据。每一个实时数据记录上都有一个时间戳，记录实时数据的采样时间。一条实时数据记录包括点标签、时间戳、状态、数值等四个组成部分。

根据轨道交通监控系统中数字量多、模拟量少，以及数字量变化慢、模拟量变化快的特点，为更好地将实时数据转化为历史数据，本文设计了双缓存的方法。具体如下：

（1）为每个点设立一个相对较大的缓存（如100条记录的缓存），记为cache＿1。数据库服务端接收到实时数据后，并不直接存入B＋树，而是根据点名直接写入该点对应的cache＿1中；当cache＿1存储的记录数达到最大限度后，统一打包存入B＋树（如图2所示）。这种以点为单位的批量存储，极大地减少了B＋树的写入次数，降低了B＋树的高度，提高了写入和查询的速度，并且在得到点的一组数据后，也能进行有效的数据压缩处理。在点数特别多（如50万点）的情况下，可事先开辟一定大小的缓存区max＿cahche1s。当该缓冲区全部被占满后，在调入新的点的cache＿1时，采用最近最久未使用的置换算法把那些久未使用的点调出内存。由于数字量变化慢、模拟量变化快，故模拟量更频繁地访问cache＿1。但轨道交通监控系统中数字量占绝对比例而模拟量相对较少，因此在系统允许的情况下，把 max＿cahche1大小设为接近模拟量点数×sizeof（cache＿1），即可具有较好的命中率。

（2）根据内存大小，为每个点设立一个相对较小的缓存，记为cache＿2，保证所有点的cache＿2都能放到内存中。实时数据过来后首先存入相应点的cache＿2缓存中，当cache＿2存储的记录数达到上限后，再写入cache＿1（见图2）。设置缓存cache＿2的目的同样是为了提高速度。由于数字量多但变化慢（一天可能只有几条数据），这个较小的缓存对数字量而言足够应付很久。通过cache＿2批量处理，极大地减少了访问cache＿1的次数，也就减少了程序访问磁盘的次数，提高了写入速度。

图2 FVDB的数据流

综上所述，所谓双缓存技术，即为每个点分别设立一个相对较大和较小的记录存储缓冲。小缓冲始终在内存；而大缓冲可以在内外存间调入调出，采用最近最久未使用的置换算法。这种缓存技术的使用，极大地提高了数据库处理历史数据的性能，进而可以支持更多的点数。

2.3 历史数据的管理

当实时数据的存在超过一定期限后，即被认为是历史数据，存放在磁盘中，如图3所示。

图3 实时和历史数据的关系

保存历史数据具有重要的实际意义。通过分析过程历史数据，不仅可以优化企业生产，也为故障分析提供了有力的工具。FVDB能够保存所有点的历史数据，而且可以保存3年以上。

2.3.1 采用B＋树索引结构

FVDB采用B＋树来组织文件数据。这是因为在工作集有序的情况下，B＋树具有较好效率，而FVDB存储的历史数据由实时数据产生，所以处理的基本都是时序数据。

当点的一组实时数据过期后就需要存储它在B＋树中。每个点都拥有一棵以时间为索引的B＋树，B＋树的叶结点就是一组历史数据的压缩包。

2.3.2 历史数据的压缩方法

为了能够在有限存储空间中保存长期的历史数据，FVDB采用了Huffman压缩算法（如图4），分别对数值、时间戳、状态进行压缩，从而大大减少历史数据存储占用的磁盘空间。当需要查询某个点的一段历史数据时，先把满足条件的压缩包按时间顺序依次读到内存，然后在内存中解压缩，还原成原始数据，返回给查询用户。

图4 压缩算法的应用

3 结语

本文根据轨道交通综合监控的特点设计了实时历史数据库FVDB，它具有数据保存时间长、存储和检索快速的特点。FVDB已经在南京地铁2号线的RT21－ISCS综合监控系统中应用，验证了本文设计的可行性。

［1］刘孟觉.RT21－ISCS综合监控数据模型功能设计［C］∥2008江苏省电机工程学会自动化及计算机应用专业委员会学术年会论文集.南京：江苏省电机工程学会自动化及计算机应用专业委员会，2008：587.

［2］刘云生，卢炎生，王道忠.实时数据库系统（RTDBS）及其特征［J］.华中理工大学学报，1994，31（6）：66.

［3］钱笑宇，张彦武.工业实时数据库的研究和设计［J］.计算机工程，2005，31（1）：98.

［4］朱健，王盛明，卢秉亮.基于实时数据库的实时数据处理研究［J］.微处理机，2010，31（1）：83.