适用于综合监控系统的过程数据库冗余框架

戴宏斌

（国电南自轨道交通工程有限公司，210032，南京∥工程师）

适用于综合监控系统的过程数据库冗余框架

戴宏斌

（国电南自轨道交通工程有限公司，210032，南京∥工程师）

过程数据库作为轨道交通综合监控系统的实时数据中枢，其可靠性对整个综合监控系统的持续稳定运行至关重要。冗余是保障可靠性的有效技术。提出了一种适用于综合监控系统的过程数据库分布式冗余框架。该框架针对综合监控系统中实时数据相关的各种特征，在冗余过程数据库的分布、同步和故障容错等方面分别采用了适合的策略，从而更有效地实现了过程数据库的冗余，保障其可靠性，为综合监控系统持续可靠运行奠定基础。

地铁；综合监控系统；过程数据库；冗余；同步；故障容错

Author'saddressNanjing SAC Rail Transit Engineering Co.，Ltd，210032，Nanjing，China

在地铁自动化监控领域，综合监控系统正获得越来越广泛的应用。综合监控系统以集成和互联的方式将多个专业统一于一致的框架之中［1］。通过实时获取地铁运营现场的各专业信息数据，集中进行一致的处理，并及时完成合理的控制，保障地铁正常、安全的运营。

综合监控系统的实时数据核心是过程数据库［2］，又简称为过程库，集中统一存放了采集自地铁运营各专业的最新数据的实时镜像。为了实时监控地铁的运营状况，综合监控系统通过采集或I/O模块从设备或子系统获得最新的现场状态数据并实时更新过程库中的相关数据；HMI（人机界面）模块从过程库获取实时数据以人性化的方式展现；告警模块依据过程库中实时状态数据触发报警；而操作员根据实际情况，通过过程库即时发出指令进行实时控制。过程库作为综合监控系统的实时数据中枢为其它模块提供一致的实时数据访问服务。

由于地铁运营涉及大规模人身安全，因此综合监控系统具有严格的可靠性要求，而作为实时数据核心的过程库，是整个系统赖以可靠运行的基础，其可靠性需求非常高。冗余是保障可靠性的有效技术。文献［3］中探讨了综合监控系统整个冗余体系的各个方面，例如在中央综合监控系统或者车站综合监控系统的局域网中，通常不只运行1台服务器，而是同时运行2台互为热备的冗余服务器，并为多个专业配置若干台工作站。同样，冗余也是保障过程库可靠性的有效技术。因此，通常在局域网中的热备冗余服务器上会同时运行相同的过程库，以实现过程库的冗余。这意味着综合监控系统中的过程库采用了分布式冗余框架。由于过程库用于提供实时数据访问服务，因此，分布式冗余框架中的所有过程库必须通过实时通信保持数据实时一致，这样才能保证从任一过程库访问的实时数据数值都是实时一致的，这称为同步［4］，反之称为失步。

本文提出一种适用于地铁综合监控系统的过程库分布式冗余框架，该框架针对地铁综合监控系统数据规模庞大、监控数据存在内在语义关联、工作站以实时数据查询为主、分专业设立等特征，在冗余过程库的分布、同步和故障容错［5］等方面分别采用了各种适合的策略，从而更有效地实现了综合监控系统中过程库的冗余，保障了过程库的可靠性。

1 实时数据访问类型

综合监控系统的过程库中保存了地铁运营现场各专业信息的最新数据，并且不断实时更新以保证及时反映现场的当前状况，从而作为实时数据中枢为其它模块提供实时数据访问服务。综合监控系统中对过程库的实时数据访问总体可以分为2类：

一类是查询访问，从过程库中获取实时数据的最新数值，以满足应用需求。常见的如HMI模块从过程库中查询列车的最新位置数据，在列车运行图示上动态显示；告警模块从过程库中查询车站当前的温、湿度以及二氧化碳浓度数据，并在异常时报警；趋势模块周期性从过程库中查询运行时电流、电压等数据，并以曲线形式展示，等等。查询访问不会改变过程库中实时数据的数值。

另一类实时数据访问是更新访问，依据应用需求，更新过程库中实时数据的数值。典型的如：采集或I/O模块从设备或子系统获得运营现场的最新状态数据后会对过程库中的相关数据进行实时更新，并同时更新其获得时间；而操作员做出的控制指示（如通、断电遥控，空调模式切换等），常常也首先写入过程库，并经由过程库知会控制模块执行。更新访问会改变过程库中实时数据的数值。

2 过程库冗余框架

为保障综合监控系统中过程库的可靠性，通常在热备双冗余服务器上同时运行相同的过程库，以实现过程库的冗余。工作站则有2种方式，一种是工作站上不运行过程库，而所有实时数据访问，都通过通信由服务器上的过程库提供远程实时数据访问服务；另一种是在工作站上运行本地过程库。

由于工作站主要用于提供界面和操作员交互，因此其上的多数模块如HMI、告警界面、趋势等模块都需要频繁访问过程库以获得最新状态数值，并刷新以将运营状况实时展现给操作员。这些主要都依靠查询访问。只有必要时，如操作员做出适当的控制操作时，会涉及更新访问。可见，工作站的实时数据访问中，绝大多数为查询访问。因而本研究中的过程库冗余框架采用了第二种方式，即在工作站上运行本地过程库，这样可以直接对这些查询访问提供本地服务，而不需籍由通信提供远程服务。这一方面避免了由此带来的繁重网络通信负载，更重要的是，由于完全没有通信时延，本地提供查询访问服务的实时性能明显优于远程服务，可以更及时地向操作员显示当前状况。当然，代价是工作站的过程库也必须和服务器的过程库保持实时同步。

在本文的过程库冗余框架中，主、备服务器和工作站上均运行过程库，并且通过通信保持实时同步。为了便于描述，分别将主、备服务器和工作站上的过程库称为主过程库、备过程库和客户过程库，依次用Ra，Rs和Rc表示。图1是过程库分布式冗余框架的示意图。

图1 过程库分布式冗余框架示意图

3 冗余过程库同步

综合监控系统的过程库中保存了所有地铁运营现场的当前状态实时数据，这里将其称为过程库的当前状态，用Si，i=1，2，3，…表示。冗余框架中的所有过程库必须始终维持实时同步。由于查询访问不修改过程库的实时数据，因此不会导致过程库状态变更，仅在本地过程库执行就可以完成。这里主要考虑当更新访问修改了过程库中的数据时，冗余框架中原来同步的分布式过程库如何维持同步。

3.1 主过程库的更新访问

假设冗余框架中所有过程库中实时数据均为运营现场的最新数据，过程库已经同步，状态均为Si，如果主服务器上的数据采集模块获得了新的数据，会提请更新访问请求D，以更新过程库中的相关数据到最新。为了维持所有过程库同步，首先由主过程库执行访问请求D，将自身的相关数据更新，从而主过程库的状态从Si变更为Si+1；然后将同步信息M=＜Ra，i+1，D＞通过通信分发给备过程库和客户过程库（其中Ra表示角色为主过程库，i+1为主过程库最新状态编号，D为更新访问请求），备过程库和客户过程库在接收到同步信息后，通过执行更新访问请求D也从状态Si变更到Si+1，从而维持和主过程库同步。图2是该策略的示意图。

图2 主过程库的更新访问请求同步策略

3.2 备过程库的更新访问

备服务器上的更新访问请求是否可以采用和主服务器类似的模式，先由本地过程库，即备过程库执行，然后分发给主过程库和客户过程库执行以维持同步呢？这在综合监控系统中是不可以的。因为这样做可能造成冗余框架中各过程库中数据的更新顺序不一致。由于综合监控系统中的数据存在内在语义关联，因此这是不允许的。举一个示意性的例子，供电装置的电流突变数据在主服务器产生一个更新访问请求，而对应的保护装置的跳闸信号在随后时刻在备服务器产生一个更新访问请求，如果主、备过程库都采取先本地执行而后分发的策略，那么由于通信时延的存在，两个更新请求在本地过程库执行完成后分发到对方执行时，对方更新请求的本地执行已经在此之前完成。因此，虽然最终主、备过程库中数据状态是一致的，但是主过程库反映的信息是电流突变导致之后的跳闸，而备过程库反映的情况正好相反，是跳闸后出现电流突变，对于电调操作员而言这是不同类型的故障，需要采用不同的应对措施，而责任认定也不一样。

因此，这在综合监控系统系统中是不能接受的。为了避免该情况，这里采用了这样一种策略：备过程库将得到的更新访问请求通过通信转发给主过程库执行，然后执行结果通过通信返回。备过程库其实是充当了一个“二传手”的角色将请求传递给了主过程库，本身并没有本地执行，直到主过程库执行后将同步信息分发给备过程库和客户过程库时，备过程库才执行以维持同步。这就迫使所有更新访问请求必须首先在主过程库顺序执行而后依次分发，从而确保冗余框架中各过程库内的数据更新顺序是一致的。图3是该同步策略的示意图。

图3 备过程库的更新访问请求同步策略

这样做不会显著增加通信压力，因为主过程库向备过程库分发同步信息的通信量主要在主过程库到备过程库的方向，而备过程库传递更新访问请求的通信量基本集中在相反方向。由于综合监控系统中的通信通道一般是全双工的，因此这样并不会造成明显的通信压力增加。这种策略的一个优点是备过程库通过通信透明传递了更新访问请求，从而使得备服务器上的实时数据访问就像在主服务器上一样，因而可以将访问过程库的模块相对均匀地分布于主、备服务器运行。对于综合监控这种功能复杂的大规模系统，这样可以有效地均衡负载。

客户过程库的更新访问请求的处理策略和备过程库一致。

3.3 冗余过程库的工作流程

过程库持续提供实时数据访问服务是综合监控系统稳定运行的基础。为了实现服务器上过程库的冗余，每一台服务器上的过程库开始运行时首先通过通信检测是否已经有主过程库在运行，如果没有则自身作为主过程库运行；如果已经存在，则作为备过程库运行。此时首先通过通信获取主过程库的所有状态数据从而实现和主过程库同步，然后在持续执行主过程库分发的同步信息以维持同步的同时，为本地的各种实时数据访问提供服务。如前所述，查询访问在本地执行，而更新访问透明传递给主过程库。图4是备过程库的运行流程图。

客户过程库的运行流程与备过程库类似。但需要注意的是，客户过程库不仅与主过程库存在通信，还与备过程库存在通信，但备过程库仅定时向客户过程库分发角色信息Rs以维持通信，不分发自身执行过的更新访问以免客户过程库重复执行。这会使得其中实时数据重复更新，从而导致综合监控系统的工作站出现重复报警或者供电功率重复累加等错误。

图4 备过程库的运行流程

4 冗余过程库的故障容错

冗余过程库的故障容错是综合监控系统冗余体系的关键之一。作为实时数据中枢的过程库一旦无法提供实时数据访问服务，整个系统将陷入瘫痪。因此，采用冗余的方式，在主、备服务器上同时运行主、备过程库并保持同步，当其中之一失效后，另一过程库仍然能够提供实时数据访问服务，从而实现故障容错。由于在冗余框架中，客户过程库保持与主过程库同步，备过程库失效对冗余框架的影响不大。这里主要讨论主过程库的故障容错。

当主过程库失效后，备过程库将迅速接管，作为主过程库继续提供实时数据服务，而客户过程库要实现并维持和新主过程库的同步。由于综合监控系统结构复杂，故障多样。因此，当原主过程库失效时，其最后的同步信息，可能已经分发给了备过程库和所有的客户过程库，也可能只分发给了其中的一部分，或者根本没来及分发。因此客户过程库和原备过程库，即新主过程库可能是同步的，也可能是失步的。为了保证同步，必须通过通信获取新主过程库的所有状态数据重新实现同步。然而，由于综合监控系统包含诸多专业，其过程库的数据规模很大，获取过程库中全部状态数据会导致很大的通信量，而容错过程中多个客户过程库同时获取全部状态数据对通信网络将带来短时繁重网络负载冲击。

为此，这里采用了这样一种策略：如果主过程库由于主服务器宕机等原因失效，那么备过程库将升格为主过程库，在角色变更后，新的主过程库将首先通过通信将角色变更信息M0=＜Ra，is，D0＞发送给所有的客户过程库（其中Ra表示角色变更为主过程库，is为新主过程库的初始状态，也就是原备过程库的最终状态编号，D0是填充的无效更新访问请求）。然后，新主过程库将提供实时数据访问服务，对于更新访问请求，将在执行完成后分发同步信息。通过分发角色变更信息M0，原备过程库通知客户过程库自己转换为主过程库运行，初始状态为is；客户过程库在接收到后，将is与自己在原主过程库失效后的当前状态编号ic比较，如果一致，表示在故障容错过程中，客户过程库和原备过程库并未失步，因此可以直接继续运行，维持和新主过程库同步即可。否则，客户过程库和原备过程库失步，只能通过通信从新主过程库获取全部当前状态数据，重新实现同步，然后维持同步。这样，最终原备过程库作为新主过程库运行，而所有客户过程库实现并维持和新主过程库同步，实现故障容错。

这一策略通过状态编号判断在故障容错过程中客户过程库和新主过程库是否失步，可以避免没有失步的客户过程库也通过获取全部状态数据来重新实现同步而产生的不必要的通信负载和时间开销，从而尽可能降低该过程中客户过程库同时获取全部状态数据对综合监控系统的通信网络带来的短时网络负载冲击。

5 客户过程库的优化

在过程库冗余框架中，主、备过程库中保存了所有专业的实时数据以实现冗余。但是对于客户过程库，并非所有实时数据都会被访问。这是由于安全和隔离的要求，工作站常按专业划分，如电调工作站、环调工作站等。对于某专业的工作站，其操作员仅有权限操作本专业的数据。例如电调操作员只能在电调工作站查看供电信息，实行电调专业的控制，无权操作环调等其它专业的数据；同样环调操作员只能在环调工作站进行环调专业的监控工作，无权访问电调等其它专业的数据。这样可以避免综合监控系统的不同专业间由于误操作而造成事故。可见，某专业工作站的过程库中仅该专业的实时数据是被使用的。

因此，对于各专业的工作站，其上的客户过程库中仅保存与本专业相关的实时数据，并在主过程库向客户过程库分发与更新访问请求时仅分发与该专业相关的更新访问请求，从而显著降低各专业工作站的客户过程库的存储空间和同步通信开销。

6 结语

本文提出一种适用于地铁综合监控系统的过程数据库冗余框架设计方案，不仅在主、备服务器上同步运行主、备过程库以实现冗余，还在工作站上同步运行客户过程库以提高实时数据查询访问的实时性能。通过为主、备过程库的更新访问请求分别设计合理的同步策略，确保更新访问在冗余框架中的所有过程库中以相同顺序执行。在故障容错过程中，依据过程库状态编号辨别客户过程库和新主过程库间的同、失步状况，尽可能降低客户过程库同时获取全部状态数据产生的网络负载冲击。通过在各专业工作站的客户过程库中仅保存与本专业相关的实时数据，显著降低其存储空间和同步通信开销。通过在过程库的分布、同步以及故障容错等方面分别采用适合的策略，实现了综合监控系统中过程库的冗余，从而保障了过程库的可靠性，有助于更有效地保障综合监控系统的整体可靠性。

［1］ 玉君，戴孙放.综合监控系统在城市轨道交通工程中的应用［J］.城市轨道交通研究，2010（9）：1.

［2］ 周东红，袁泉，陈洪如，等.地铁综合监控自动化系统中关键技术的解决方案［J］.城市轨道交通研究，2006（8）：50.

［3］ 赵春艳.轨道交通综合监控系统冗余解决方法［J］.机电信息，2012（3）：111.

［4］ 杨佳，何丕雁.分布式实时数据库系统数据同步通信研究［J］.广东通信技术，2008（4）：73.

［5］ 徐劲松，陈抒凡.城轨交通综合监控系统的冗余设计［J］.现代城市轨道交通，2008（5）：29.

［6］ 刘佳宝，梁奕，陈天浩.RT21-ISCS综合监控系统中实时历史数据库的设计与实现［J］.城市轨道交通研究，2012（1）：59.

A Redundancy Framework of Process Databases Suitable for ISCS

Dai Hongbin

The process databases are the core of the ISCS real-time data in metro，their reliability is of great importance to ensure the continuously stable operation of ISCS，while redundancy is an effective technology to guarantee the operational reliability.In this paper，a framework of distributed redundant process databases suitable for ISCS is presented.Considering the characteristics of different aspects related to real-time data in ISCS，this framework adopts several suitable strategies in the distribution，synchronization and fault tolerance of the process databases in ISCS，thus it could effectively realizes the redundancy of the process databases and guarantee their reliability.This framework plays a solid foundation for the reliability of the whole ISCS.

metro；integrated supervision and control system（ISCS）；process database；redundancy；synchronization；fault tolerance

TP 392：U 29-39

2013-07-15）